From dholmes at openjdk.org  Mon Sep  2 04:06:28 2024
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 2 Sep 2024 04:06:28 GMT
Subject: RFR: 8337563: NMT: rename MEMFLAGS to MemFlag
In-Reply-To: <XT8-0JId5lEtWVsceJGTY7lDet5gWNONy1A9rUigZ0g=.be0db307-977f-4bad-900c-1f21ee5257ab@github.com>
References: <XT8-0JId5lEtWVsceJGTY7lDet5gWNONy1A9rUigZ0g=.be0db307-977f-4bad-900c-1f21ee5257ab@github.com>
Message-ID: <PU7tsErJTBIdq1FpdOu7xHuDsib2DjA95i9YzUkoq-Y=.a016b1ee-02ff-4504-a313-6fd9fc09ee97@github.com>

On Wed, 7 Aug 2024 17:13:06 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

> Please review this cleanup, where we rename `MEMFLAGS` to `MemType`.
> 
> `MEMFLAGS` implies that we can use more than one at the same time, but those are exclusive values, so `MemType` is much more suitable name.
> 
> There is a bunch of other related cleanup that we can do, but I will leave for follow up issues such as [NMT: rename NMTUtil::flag to NMTUtil::type](https://bugs.openjdk.org/browse/JDK-8337836)

FWIW as I recall the suggestion to include NMT in the name in some form was to make it clear that these kinds of parameter, which appear all over the place, are needed because of NMT and are not inherently part of whatever API they appear in. Whether that happens via a namespace, a nested enum, or a simple prefix, I don't really care except to say that anything that can then result in dropping the NMT in the source code (e.g. via a using directive) completely defeats the purpose of having it in the first place. So if there is no good answer here than I guess we just drop NMT from the name.

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

PR Comment: https://git.openjdk.org/jdk/pull/20497#issuecomment-2323770639

From gziemski at openjdk.org  Tue Sep  3 17:05:19 2024
From: gziemski at openjdk.org (Gerard Ziemski)
Date: Tue, 3 Sep 2024 17:05:19 GMT
Subject: RFR: 8337563: NMT: rename MEMFLAGS to MemFlag
In-Reply-To: <PU7tsErJTBIdq1FpdOu7xHuDsib2DjA95i9YzUkoq-Y=.a016b1ee-02ff-4504-a313-6fd9fc09ee97@github.com>
References: <XT8-0JId5lEtWVsceJGTY7lDet5gWNONy1A9rUigZ0g=.be0db307-977f-4bad-900c-1f21ee5257ab@github.com>
 <PU7tsErJTBIdq1FpdOu7xHuDsib2DjA95i9YzUkoq-Y=.a016b1ee-02ff-4504-a313-6fd9fc09ee97@github.com>
Message-ID: <5TUXq3-MyXcwxS30Wf2DQKXzADQY-W5sSipZTW4P7zg=.3824be94-4d6b-4e2a-a5ea-a5f25d71afb7@github.com>

On Mon, 2 Sep 2024 04:03:28 GMT, David Holmes <dholmes at openjdk.org> wrote:

> FWIW as I recall the suggestion to include NMT in the name in some form was to make it clear that these kinds of parameter, which appear all over the place, are needed because of NMT and are not inherently part of whatever API they appear in. Whether that happens via a namespace, a nested enum, or a simple prefix, I don't really care except to say that anything that can then result in dropping the NMT in the source code (e.g. via a using directive) completely defeats the purpose of having it in the first place. So if there is no good answer here than I guess we just drop NMT from the name.

Kim and Stefan said that any consideration of using namespace would require additional discussion. And almost everyone dislikes adding the `NMT_` prefix.

I feel like we achieved (imperfect) agreement that allows us to proceed with a cleanup using `MemTag` as the new type name to replace `MEMFLAGS`, which I hope everyone agrees is an improvement.

I am almost done with that name change and I see it as a significant improvement worthwhile of this effort, with anything else that can be handled in followups, however, if you feel strongly that we should discuss the full topic right now, before proceeding, please let it be known here.

Personally I just wanted to cleanup `MEMFLAGS` and related `flag(s)` names that we used in very inconsistent matter.

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

PR Comment: https://git.openjdk.org/jdk/pull/20497#issuecomment-2327019788

From wkemper at openjdk.org  Tue Sep  3 17:57:59 2024
From: wkemper at openjdk.org (William Kemper)
Date: Tue, 3 Sep 2024 17:57:59 GMT
Subject: RFR: 8339346: GenShen: Remove even more stale TODOs
Message-ID: <UZWSGjHVuR0-Zj2Xp-6duVmLajqQZR6WCnLkV0qbD-A=.952c0f01-400c-4ff5-acc4-4e9c9b7f186b@github.com>

Some of these have been done, some of these will not be done, some have been moved into our ticketing system, some of them are done in this PR.

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

Commit messages:
 - oop arguments do not need to be const
 - Checkpoint
 - Rename `object_starts` to `_object_starts`
 - Remove unused methods and fields
 - Merge remote-tracking branch 'shenandoah/master' into fix-stale-todos
 - Implement TODO to use an API for excluding free regions
 - Remove or rephrase confusing TODO items
 - Remove out-dated TODOs
 - Remove invalid TODO and vestige of IU mode
 - No, we must use a mask to test for a set bit
 - ... and 2 more: https://git.openjdk.org/shenandoah/compare/c7cfc7fa...c3a0301c

Changes: https://git.openjdk.org/shenandoah/pull/491/files
  Webrev: https://webrevs.openjdk.org/?repo=shenandoah&pr=491&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8339346
  Stats: 205 lines in 18 files changed: 0 ins; 176 del; 29 mod
  Patch: https://git.openjdk.org/shenandoah/pull/491.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah.git pull/491/head:pull/491

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

From duke at openjdk.org  Tue Sep  3 22:26:07 2024
From: duke at openjdk.org (Satyen Subramaniam)
Date: Tue, 3 Sep 2024 22:26:07 GMT
Subject: RFR: 8339197: GenShen: Adding Generation and Evacuation
 Information JFR Logging [v5]
In-Reply-To: <BEJelx66YJmCPpWF74x7zX3l-Y9Xu4I4F5qRQptKbQU=.9b86ad21-794f-4fc6-911e-814b517db7a6@github.com>
References: <BEJelx66YJmCPpWF74x7zX3l-Y9Xu4I4F5qRQptKbQU=.9b86ad21-794f-4fc6-911e-814b517db7a6@github.com>
Message-ID: <s1VvdhSdppb-1E8bBJf8u1ZW76JJby0S3cRJaFINAqU=.a24cc237-91a8-427b-a7c2-7c9ce4ebbe3b@github.com>

> Adding `ShenandoahEvacInfo` event and modifying existing logging for Concurrent Reset and Final Roots events to include generation for Generational Shenandoah GC.

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

  Adding additional logging, removing 'static'

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

Changes:
  - all: https://git.openjdk.org/shenandoah/pull/489/files
  - new: https://git.openjdk.org/shenandoah/pull/489/files/1fc6ef01..f087964e

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

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

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

From ysr at openjdk.org  Tue Sep  3 23:19:49 2024
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Tue, 3 Sep 2024 23:19:49 GMT
Subject: RFR: 8339346: GenShen: Remove even more stale TODOs
In-Reply-To: <UZWSGjHVuR0-Zj2Xp-6duVmLajqQZR6WCnLkV0qbD-A=.952c0f01-400c-4ff5-acc4-4e9c9b7f186b@github.com>
References: <UZWSGjHVuR0-Zj2Xp-6duVmLajqQZR6WCnLkV0qbD-A=.952c0f01-400c-4ff5-acc4-4e9c9b7f186b@github.com>
Message-ID: <QYA4K7sFd_zXPdhd0yfeHRGU7KvTJs4MZQORRfDoLvk=.eb701788-9992-4e5e-8b50-7eccd5f5ea3f@github.com>

On Fri, 30 Aug 2024 21:22:59 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Some of these have been done, some of these will not be done, some have been moved into our ticketing system, some of them are done in this PR.

Left a couple of minor comments.

LGTM otherwise; thanks for the cleanup!

src/hotspot/share/gc/shenandoah/shenandoahMarkingContext.hpp line 73:

> 71: 
> 72:   inline bool allocated_after_mark_start(oop obj) const;
> 73:   inline bool allocated_after_mark_start(const HeapWord* addr) const;

Any reason to remove the arg const-ness? Seems to hold and gives you a sense of the methods not modifying the args. Do we gain anything from removing the arg-constness? (I do see the "TODO" comment, but I'd erro towards removing the TODO comment and leaving the arg const-ness in place.

src/hotspot/share/gc/shenandoah/shenandoahMarkingContext.inline.hpp line 1:

> 1: /*

See comment re arg-constness above in .hpp.

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

> 783:   void mark_range_as_dirty(size_t card_index, size_t num_cards);
> 784:   void mark_card_as_clean(size_t card_index);
> 785:   void mark_range_as_clean(size_t card_index, size_t num_cards);

Are these being removed because the "card_index" arg versions are never used, only the "heapword*" arg versions?

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

Marked as reviewed by ysr (Committer).

PR Review: https://git.openjdk.org/shenandoah/pull/491#pullrequestreview-2278613461
PR Review Comment: https://git.openjdk.org/shenandoah/pull/491#discussion_r1742765318
PR Review Comment: https://git.openjdk.org/shenandoah/pull/491#discussion_r1742766344
PR Review Comment: https://git.openjdk.org/shenandoah/pull/491#discussion_r1742801892

From ysr at openjdk.org  Tue Sep  3 23:19:49 2024
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Tue, 3 Sep 2024 23:19:49 GMT
Subject: RFR: 8339346: GenShen: Remove even more stale TODOs
In-Reply-To: <QYA4K7sFd_zXPdhd0yfeHRGU7KvTJs4MZQORRfDoLvk=.eb701788-9992-4e5e-8b50-7eccd5f5ea3f@github.com>
References: <UZWSGjHVuR0-Zj2Xp-6duVmLajqQZR6WCnLkV0qbD-A=.952c0f01-400c-4ff5-acc4-4e9c9b7f186b@github.com>
 <QYA4K7sFd_zXPdhd0yfeHRGU7KvTJs4MZQORRfDoLvk=.eb701788-9992-4e5e-8b50-7eccd5f5ea3f@github.com>
Message-ID: <nwwq7mt78vnq-zGWelaFrCQUd1ry1MU27CxyTA5Wals=.01636eee-e587-482b-be8c-b2eb80dedcc6@github.com>

On Tue, 3 Sep 2024 23:14:50 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

>> Some of these have been done, some of these will not be done, some have been moved into our ticketing system, some of them are done in this PR.
>
> src/hotspot/share/gc/shenandoah/shenandoahScanRemembered.hpp line 785:
> 
>> 783:   void mark_range_as_dirty(size_t card_index, size_t num_cards);
>> 784:   void mark_card_as_clean(size_t card_index);
>> 785:   void mark_range_as_clean(size_t card_index, size_t num_cards);
> 
> Are these being removed because the "card_index" arg versions are never used, only the "heapword*" arg versions?

Can the "TODO:" at line 748 (old line 761) also be removed, or is there a good reason to keep it for now?

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

PR Review Comment: https://git.openjdk.org/shenandoah/pull/491#discussion_r1742802422

From wkemper at openjdk.org  Wed Sep  4 00:02:38 2024
From: wkemper at openjdk.org (William Kemper)
Date: Wed, 4 Sep 2024 00:02:38 GMT
Subject: RFR: 8339346: GenShen: Remove even more stale TODOs
In-Reply-To: <nwwq7mt78vnq-zGWelaFrCQUd1ry1MU27CxyTA5Wals=.01636eee-e587-482b-be8c-b2eb80dedcc6@github.com>
References: <UZWSGjHVuR0-Zj2Xp-6duVmLajqQZR6WCnLkV0qbD-A=.952c0f01-400c-4ff5-acc4-4e9c9b7f186b@github.com>
 <QYA4K7sFd_zXPdhd0yfeHRGU7KvTJs4MZQORRfDoLvk=.eb701788-9992-4e5e-8b50-7eccd5f5ea3f@github.com>
 <nwwq7mt78vnq-zGWelaFrCQUd1ry1MU27CxyTA5Wals=.01636eee-e587-482b-be8c-b2eb80dedcc6@github.com>
Message-ID: <9lqXPW0b-7dYQm8o2MawublExP7aIBWpQivpEhgaLM4=.0455dcb3-39a9-454b-bef1-c1db6c872021@github.com>

On Tue, 3 Sep 2024 23:15:53 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

>> src/hotspot/share/gc/shenandoah/shenandoahScanRemembered.hpp line 785:
>> 
>>> 783:   void mark_range_as_dirty(size_t card_index, size_t num_cards);
>>> 784:   void mark_card_as_clean(size_t card_index);
>>> 785:   void mark_range_as_clean(size_t card_index, size_t num_cards);
>> 
>> Are these being removed because the "card_index" arg versions are never used, only the "heapword*" arg versions?
>
> Can the "TODO:" at line 748 (old line 761) also be removed, or is there a good reason to keep it for now?

Yes, these aren't used. I'm removing that TODO in the next batch after I remove the last of the unused methods.

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

PR Review Comment: https://git.openjdk.org/shenandoah/pull/491#discussion_r1742825809

From kdnilsen at openjdk.org  Wed Sep  4 00:12:39 2024
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Wed, 4 Sep 2024 00:12:39 GMT
Subject: RFR: 8339346: GenShen: Remove even more stale TODOs
In-Reply-To: <UZWSGjHVuR0-Zj2Xp-6duVmLajqQZR6WCnLkV0qbD-A=.952c0f01-400c-4ff5-acc4-4e9c9b7f186b@github.com>
References: <UZWSGjHVuR0-Zj2Xp-6duVmLajqQZR6WCnLkV0qbD-A=.952c0f01-400c-4ff5-acc4-4e9c9b7f186b@github.com>
Message-ID: <JIWT4U9IIY7D8DHc9xSeglRdSqNzmEU4ECoBF8RP_Ok=.c11e806b-41b7-46a2-8210-94a697f7487f@github.com>

On Fri, 30 Aug 2024 21:22:59 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Some of these have been done, some of these will not be done, some have been moved into our ticketing system, some of them are done in this PR.

Marked as reviewed by kdnilsen (Committer).

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

PR Review: https://git.openjdk.org/shenandoah/pull/491#pullrequestreview-2278706623

From kdnilsen at openjdk.org  Wed Sep  4 00:12:39 2024
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Wed, 4 Sep 2024 00:12:39 GMT
Subject: RFR: 8339346: GenShen: Remove even more stale TODOs
In-Reply-To: <QYA4K7sFd_zXPdhd0yfeHRGU7KvTJs4MZQORRfDoLvk=.eb701788-9992-4e5e-8b50-7eccd5f5ea3f@github.com>
References: <UZWSGjHVuR0-Zj2Xp-6duVmLajqQZR6WCnLkV0qbD-A=.952c0f01-400c-4ff5-acc4-4e9c9b7f186b@github.com>
 <QYA4K7sFd_zXPdhd0yfeHRGU7KvTJs4MZQORRfDoLvk=.eb701788-9992-4e5e-8b50-7eccd5f5ea3f@github.com>
Message-ID: <I6d5b1RggKnKcp7vSWBgLWSylo36u8kfmV4FWGt23go=.a5e3ce88-cf8d-4726-8701-a275033f027e@github.com>

On Tue, 3 Sep 2024 22:14:13 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

>> Some of these have been done, some of these will not be done, some have been moved into our ticketing system, some of them are done in this PR.
>
> src/hotspot/share/gc/shenandoah/shenandoahMarkingContext.hpp line 73:
> 
>> 71: 
>> 72:   inline bool allocated_after_mark_start(oop obj) const;
>> 73:   inline bool allocated_after_mark_start(const HeapWord* addr) const;
> 
> Any reason to remove the arg const-ness? Seems to hold and gives you a sense of the methods not modifying the args. Do we gain anything from removing the arg-constness? (I do see the "TODO" comment, but I'd erro towards removing the TODO comment and leaving the arg const-ness in place.

Agree with Ramki here, unless there's a reason we prefer non-const args.

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

PR Review Comment: https://git.openjdk.org/shenandoah/pull/491#discussion_r1742828964

From wkemper at openjdk.org  Wed Sep  4 00:21:43 2024
From: wkemper at openjdk.org (William Kemper)
Date: Wed, 4 Sep 2024 00:21:43 GMT
Subject: RFR: 8339346: GenShen: Remove even more stale TODOs
In-Reply-To: <I6d5b1RggKnKcp7vSWBgLWSylo36u8kfmV4FWGt23go=.a5e3ce88-cf8d-4726-8701-a275033f027e@github.com>
References: <UZWSGjHVuR0-Zj2Xp-6duVmLajqQZR6WCnLkV0qbD-A=.952c0f01-400c-4ff5-acc4-4e9c9b7f186b@github.com>
 <QYA4K7sFd_zXPdhd0yfeHRGU7KvTJs4MZQORRfDoLvk=.eb701788-9992-4e5e-8b50-7eccd5f5ea3f@github.com>
 <I6d5b1RggKnKcp7vSWBgLWSylo36u8kfmV4FWGt23go=.a5e3ce88-cf8d-4726-8701-a275033f027e@github.com>
Message-ID: <LS2NujeglqDZcDwRkBBRJzVVyfMycyBc0rIGOJm1BNw=.a9549cd1-2e72-4f1c-8b17-161d519fef4c@github.com>

On Wed, 4 Sep 2024 00:06:19 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> src/hotspot/share/gc/shenandoah/shenandoahMarkingContext.hpp line 73:
>> 
>>> 71: 
>>> 72:   inline bool allocated_after_mark_start(oop obj) const;
>>> 73:   inline bool allocated_after_mark_start(const HeapWord* addr) const;
>> 
>> Any reason to remove the arg const-ness? Seems to hold and gives you a sense of the methods not modifying the args. Do we gain anything from removing the arg-constness? (I do see the "TODO" comment, but I'd erro towards removing the TODO comment and leaving the arg const-ness in place.
>
> Agree with Ramki here, unless there's a reason we prefer non-const args.

I believe it is confusing because `oop` is a `typedef` for a pointer `oopDesc*`. So, the `const` here applies to the typedef and not to the underlying type (that is, we could still call non-const methods on `oop` inside the function, but we cannot change what `oop` points to). Also, these `const` modifiers are not present upstream.

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

PR Review Comment: https://git.openjdk.org/shenandoah/pull/491#discussion_r1742835181

From kdnilsen at openjdk.org  Wed Sep  4 00:25:35 2024
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Wed, 4 Sep 2024 00:25:35 GMT
Subject: RFR: 8339346: GenShen: Remove even more stale TODOs
In-Reply-To: <LS2NujeglqDZcDwRkBBRJzVVyfMycyBc0rIGOJm1BNw=.a9549cd1-2e72-4f1c-8b17-161d519fef4c@github.com>
References: <UZWSGjHVuR0-Zj2Xp-6duVmLajqQZR6WCnLkV0qbD-A=.952c0f01-400c-4ff5-acc4-4e9c9b7f186b@github.com>
 <QYA4K7sFd_zXPdhd0yfeHRGU7KvTJs4MZQORRfDoLvk=.eb701788-9992-4e5e-8b50-7eccd5f5ea3f@github.com>
 <I6d5b1RggKnKcp7vSWBgLWSylo36u8kfmV4FWGt23go=.a5e3ce88-cf8d-4726-8701-a275033f027e@github.com>
 <LS2NujeglqDZcDwRkBBRJzVVyfMycyBc0rIGOJm1BNw=.a9549cd1-2e72-4f1c-8b17-161d519fef4c@github.com>
Message-ID: <BxfXSMCXp04q05G10mBQhi3F-GprfoIn-92lPaNmr9s=.a9bb32a0-0ae8-434c-a203-784ad1a38d11@github.com>

On Wed, 4 Sep 2024 00:18:30 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> Agree with Ramki here, unless there's a reason we prefer non-const args.
>
> I believe it is confusing because `oop` is a `typedef` for a pointer `oopDesc*`. So, the `const` here applies to the typedef and not to the underlying type (that is, we could still call non-const methods on `oop` inside the function, but we cannot change what `oop` points to). Also, these `const` modifiers are not present upstream.

ok.

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

PR Review Comment: https://git.openjdk.org/shenandoah/pull/491#discussion_r1742837116

From wkemper at openjdk.org  Wed Sep  4 00:28:41 2024
From: wkemper at openjdk.org (William Kemper)
Date: Wed, 4 Sep 2024 00:28:41 GMT
Subject: RFR: 8339346: GenShen: Remove even more stale TODOs
In-Reply-To: <UZWSGjHVuR0-Zj2Xp-6duVmLajqQZR6WCnLkV0qbD-A=.952c0f01-400c-4ff5-acc4-4e9c9b7f186b@github.com>
References: <UZWSGjHVuR0-Zj2Xp-6duVmLajqQZR6WCnLkV0qbD-A=.952c0f01-400c-4ff5-acc4-4e9c9b7f186b@github.com>
Message-ID: <f-9HbGfP2It07mZfZS-zHF9vabFJhhWvy8H9PNexa5o=.4c8e7045-0b52-4109-94be-adc7ab5d1f9e@github.com>

On Fri, 30 Aug 2024 21:22:59 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Some of these have been done, some of these will not be done, some have been moved into our ticketing system, some of them are done in this PR.

The `const` is confusing because it doesn't make `oop` const.

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

PR Comment: https://git.openjdk.org/shenandoah/pull/491#issuecomment-2327679108

From wkemper at openjdk.org  Wed Sep  4 14:42:44 2024
From: wkemper at openjdk.org (William Kemper)
Date: Wed, 4 Sep 2024 14:42:44 GMT
Subject: Integrated: 8339346: GenShen: Remove even more stale TODOs
In-Reply-To: <UZWSGjHVuR0-Zj2Xp-6duVmLajqQZR6WCnLkV0qbD-A=.952c0f01-400c-4ff5-acc4-4e9c9b7f186b@github.com>
References: <UZWSGjHVuR0-Zj2Xp-6duVmLajqQZR6WCnLkV0qbD-A=.952c0f01-400c-4ff5-acc4-4e9c9b7f186b@github.com>
Message-ID: <w4rJcV9HYCGg1EGPknngtCSgmzicrDxF1QdBiX_71x8=.10588a79-5709-4038-a3c4-d0ad1e40e37d@github.com>

On Fri, 30 Aug 2024 21:22:59 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Some of these have been done, some of these will not be done, some have been moved into our ticketing system, some of them are done in this PR.

This pull request has now been integrated.

Changeset: dea5a915
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.org/shenandoah/commit/dea5a915a4cb54ba5df59e19a63d3f552d7f69e4
Stats:     205 lines in 18 files changed: 0 ins; 176 del; 29 mod

8339346: GenShen: Remove even more stale TODOs

Reviewed-by: ysr, kdnilsen

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

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

From kdnilsen at openjdk.org  Wed Sep  4 15:25:44 2024
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Wed, 4 Sep 2024 15:25:44 GMT
Subject: RFR: 8339197: GenShen: Adding Generation and Evacuation
 Information JFR Logging [v5]
In-Reply-To: <s1VvdhSdppb-1E8bBJf8u1ZW76JJby0S3cRJaFINAqU=.a24cc237-91a8-427b-a7c2-7c9ce4ebbe3b@github.com>
References: <BEJelx66YJmCPpWF74x7zX3l-Y9Xu4I4F5qRQptKbQU=.9b86ad21-794f-4fc6-911e-814b517db7a6@github.com>
 <s1VvdhSdppb-1E8bBJf8u1ZW76JJby0S3cRJaFINAqU=.a24cc237-91a8-427b-a7c2-7c9ce4ebbe3b@github.com>
Message-ID: <CPO-NtaIDO1XsaAXFLcW45naOjwpeNDxoIPm1nhAGHw=.38de327c-6fd7-43b4-8282-778f2d2d23e1@github.com>

On Tue, 3 Sep 2024 22:26:07 GMT, Satyen Subramaniam <duke at openjdk.org> wrote:

>> Adding `ShenandoahEvacInfo` event and modifying existing logging for Concurrent Reset and Final Roots events to include generation for Generational Shenandoah GC.
>
> Satyen Subramaniam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adding additional logging, removing 'static'

src/hotspot/share/gc/shenandoah/shenandoahConcurrentGC.cpp line 428:

> 426:   ShenandoahHeap* const heap = ShenandoahHeap::heap();
> 427:   const char* msg = conc_weak_refs_event_message();
> 428:   ShenandoahConcurrentPhase gc_phase(msg, ShenandoahPhaseTimings::conc_weak_refs);

Looks good.  With the "static" qualifier, the initialization statement only executes the first time through the function.

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

PR Review Comment: https://git.openjdk.org/shenandoah/pull/489#discussion_r1744000005

From ysr at openjdk.org  Wed Sep  4 15:36:03 2024
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Wed, 4 Sep 2024 15:36:03 GMT
Subject: RFR: 8339346: GenShen: Remove even more stale TODOs
In-Reply-To: <BxfXSMCXp04q05G10mBQhi3F-GprfoIn-92lPaNmr9s=.a9bb32a0-0ae8-434c-a203-784ad1a38d11@github.com>
References: <UZWSGjHVuR0-Zj2Xp-6duVmLajqQZR6WCnLkV0qbD-A=.952c0f01-400c-4ff5-acc4-4e9c9b7f186b@github.com>
 <QYA4K7sFd_zXPdhd0yfeHRGU7KvTJs4MZQORRfDoLvk=.eb701788-9992-4e5e-8b50-7eccd5f5ea3f@github.com>
 <I6d5b1RggKnKcp7vSWBgLWSylo36u8kfmV4FWGt23go=.a5e3ce88-cf8d-4726-8701-a275033f027e@github.com>
 <LS2NujeglqDZcDwRkBBRJzVVyfMycyBc0rIGOJm1BNw=.a9549cd1-2e72-4f1c-8b17-161d519fef4c@github.com>
 <BxfXSMCXp04q05G10mBQhi3F-GprfoIn-92lPaNmr9s=.a9bb32a0-0ae8-434c-a203-784ad1a38d11@github.com>
Message-ID: <ZPH8FhrzSy1-dHWR6O2uLxwqO7jCFbKrhuuGEIrDnrU=.11ee9bb6-bce1-434a-8a62-39a737903c01@github.com>

On Wed, 4 Sep 2024 00:22:33 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> I believe it is confusing because `oop` is a `typedef` for a pointer `oopDesc*`. So, the `const` here applies to the typedef and not to the underlying type (that is, we could still call non-const methods on `oop` inside the function, but we cannot change what `oop` points to). Also, these `const` modifiers are not present upstream.
>
> ok.

Good point, so what one wanted here was `oop const obj` ... :-) But that might cause other changes, and not a big deal here, since it's fewer diffs wrt upstream, as you state.

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

PR Review Comment: https://git.openjdk.org/shenandoah/pull/491#discussion_r1744017345

From duke at openjdk.org  Wed Sep  4 16:03:48 2024
From: duke at openjdk.org (duke)
Date: Wed, 4 Sep 2024 16:03:48 GMT
Subject: RFR: 8339197: GenShen: Adding Generation and Evacuation
 Information JFR Logging [v5]
In-Reply-To: <s1VvdhSdppb-1E8bBJf8u1ZW76JJby0S3cRJaFINAqU=.a24cc237-91a8-427b-a7c2-7c9ce4ebbe3b@github.com>
References: <BEJelx66YJmCPpWF74x7zX3l-Y9Xu4I4F5qRQptKbQU=.9b86ad21-794f-4fc6-911e-814b517db7a6@github.com>
 <s1VvdhSdppb-1E8bBJf8u1ZW76JJby0S3cRJaFINAqU=.a24cc237-91a8-427b-a7c2-7c9ce4ebbe3b@github.com>
Message-ID: <exDNclS-nbSgx9xhztBSCpG7QZu0XK143sz4Sn-5rjc=.a7e2c7f9-32e0-4c5c-aa12-7ed085342b65@github.com>

On Tue, 3 Sep 2024 22:26:07 GMT, Satyen Subramaniam <duke at openjdk.org> wrote:

>> Adding `ShenandoahEvacInfo` event and modifying existing logging for Concurrent Reset and Final Roots events to include generation for Generational Shenandoah GC.
>
> Satyen Subramaniam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adding additional logging, removing 'static'

@satyenme 
Your change (at version f087964e38a7f1e2eb959c5eb8fa83f8d6800aef) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/shenandoah/pull/489#issuecomment-2329453749

From duke at openjdk.org  Wed Sep  4 17:43:43 2024
From: duke at openjdk.org (Satyen Subramaniam)
Date: Wed, 4 Sep 2024 17:43:43 GMT
Subject: Integrated: 8339197: GenShen: Adding Generation and Evacuation
 Information JFR Logging
In-Reply-To: <BEJelx66YJmCPpWF74x7zX3l-Y9Xu4I4F5qRQptKbQU=.9b86ad21-794f-4fc6-911e-814b517db7a6@github.com>
References: <BEJelx66YJmCPpWF74x7zX3l-Y9Xu4I4F5qRQptKbQU=.9b86ad21-794f-4fc6-911e-814b517db7a6@github.com>
Message-ID: <UxuyP7gewsI1zUSBcDzmOchGtImgbUk3vbLiTvBEAqo=.73044c0c-8845-4f41-955c-0c889131aabe@github.com>

On Wed, 28 Aug 2024 22:43:28 GMT, Satyen Subramaniam <duke at openjdk.org> wrote:

> Adding `ShenandoahEvacInfo` event and modifying existing logging for Concurrent Reset and Final Roots events to include generation for Generational Shenandoah GC.

This pull request has now been integrated.

Changeset: 662d146d
Author:    Satyen Subramaniam <satyenme at amazon.com>
Committer: Kelvin Nilsen <kdnilsen at openjdk.org>
URL:       https://git.openjdk.org/shenandoah/commit/662d146d52dd77d13cfe705a4a4959c5fb2fb5a1
Stats:     323 lines in 10 files changed: 312 ins; 5 del; 6 mod

8339197: GenShen: Adding Generation and Evacuation Information JFR Logging

Reviewed-by: kdnilsen, wkemper, ysr

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

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

From gziemski at openjdk.org  Wed Sep  4 21:17:28 2024
From: gziemski at openjdk.org (Gerard Ziemski)
Date: Wed, 4 Sep 2024 21:17:28 GMT
Subject: RFR: 8337563: NMT: rename MEMFLAGS to MemFlag [v2]
In-Reply-To: <XT8-0JId5lEtWVsceJGTY7lDet5gWNONy1A9rUigZ0g=.be0db307-977f-4bad-900c-1f21ee5257ab@github.com>
References: <XT8-0JId5lEtWVsceJGTY7lDet5gWNONy1A9rUigZ0g=.be0db307-977f-4bad-900c-1f21ee5257ab@github.com>
Message-ID: <tANrlOIzA7klJV-SVrxpvsLDTmwcRXdwTLXwY-y1aF0=.e565e7c1-a563-44d2-9665-43336d6a5936@github.com>

> Please review this cleanup, where we rename `MEMFLAGS` to `MemType`.
> 
> `MEMFLAGS` implies that we can use more than one at the same time, but those are exclusive values, so `MemType` is much more suitable name.
> 
> There is a bunch of other related cleanup that we can do, but I will leave for follow up issues such as [NMT: rename NMTUtil::flag to NMTUtil::type](https://bugs.openjdk.org/browse/JDK-8337836)

Gerard Ziemski has updated the pull request incrementally with 308 additional commits since the last revision:

 - undo MEMFLAGS to MemType
 - 8339233: Test javax/swing/JButton/SwingButtonResizeTestWithOpenGL.java#id failed: Button renderings are different after window resize
   
   Reviewed-by: honkar
 - 8338924: C1: assert(0 <= i && i < _len) failed: illegal index 5 for length 5
   
   Co-authored-by: Dean Long <dlong at openjdk.org>
   Reviewed-by: kvn, thartmann
 - 8339492: StackMapDecoder::writeFrames makes lots of allocations
   
   Reviewed-by: liach, redestad, jwaters, asotona
 - 8332901: Select{Current,New}ItemTest.java for Choice don't open popup on macOS
   
   Move SelectCurrentItemTest.java to java/awt/Choice/SelectItem/.
   Move SelectNewItemTest.java to java/awt/Choice/SelectItem/.
   Use latches to control test flow instead of delays.
   Encapsulate the common logic in SelectCurrentItemTest.
   Provide overridable checkXXX() methods to modify conditions.
   Provide an overridable method which defines where to click
   in the choice popup to select an item.
   
   Reviewed-by: honkar, prr, dnguyen
 - 8339148: Make os::Linux::active_processor_count() public
   
   Reviewed-by: dholmes, jwaters
 - 8339112: Move JVM Klass flags out of AccessFlags
   
   Reviewed-by: matsaave, cjplummer, dlong, thartmann, yzheng
 - 8336860: x86: Change integer src operand for CMoveL of 0 and 1 to long
   
   Reviewed-by: epeter, chagedorn, shade, qamai, jbhateja
 - 8325679: Optimize ArrayList subList sort
   
   Reviewed-by: liach
 - 8339131: Remove rarely-used accessor methods from Opcode
   
   Reviewed-by: asotona
 - ... and 298 more: https://git.openjdk.org/jdk/compare/9665d7f7...6d6d70e9

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20497/files
  - new: https://git.openjdk.org/jdk/pull/20497/files/9665d7f7..6d6d70e9

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

  Stats: 40412 lines in 1372 files changed: 23818 ins; 9766 del; 6828 mod
  Patch: https://git.openjdk.org/jdk/pull/20497.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20497/head:pull/20497

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

From gziemski at openjdk.org  Wed Sep  4 21:17:38 2024
From: gziemski at openjdk.org (Gerard Ziemski)
Date: Wed, 4 Sep 2024 21:17:38 GMT
Subject: RFR: 8337563: NMT: rename MEMFLAGS to MemFlag
In-Reply-To: <XT8-0JId5lEtWVsceJGTY7lDet5gWNONy1A9rUigZ0g=.be0db307-977f-4bad-900c-1f21ee5257ab@github.com>
References: <XT8-0JId5lEtWVsceJGTY7lDet5gWNONy1A9rUigZ0g=.be0db307-977f-4bad-900c-1f21ee5257ab@github.com>
Message-ID: <DFEP_ZpB_W0WBwpYrolGUf_0hMuAzBzoWX1tNr9j-y0=.d7691290-93ec-4ea6-934c-a4e2769a9899@github.com>

On Wed, 7 Aug 2024 17:13:06 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

> Please review this cleanup, where we rename `MEMFLAGS` to `MemType`.
> 
> `MEMFLAGS` implies that we can use more than one at the same time, but those are exclusive values, so `MemType` is much more suitable name.
> 
> There is a bunch of other related cleanup that we can do, but I will leave for follow up issues such as [NMT: rename NMTUtil::flag to NMTUtil::type](https://bugs.openjdk.org/browse/JDK-8337836)

I tried undoing my MEMFLAGS to MemType change in preparations for MEMFLAGS to MemTag rename (which I have working), but that caused massive rebase, so I will close this PR and move it to a clean branch if  no-one objects?

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

PR Comment: https://git.openjdk.org/jdk/pull/20497#issuecomment-2330132485

From coleenp at openjdk.org  Wed Sep  4 22:22:56 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 4 Sep 2024 22:22:56 GMT
Subject: RFR: 8337563: NMT: rename MEMFLAGS to MemFlag [v2]
In-Reply-To: <tANrlOIzA7klJV-SVrxpvsLDTmwcRXdwTLXwY-y1aF0=.e565e7c1-a563-44d2-9665-43336d6a5936@github.com>
References: <XT8-0JId5lEtWVsceJGTY7lDet5gWNONy1A9rUigZ0g=.be0db307-977f-4bad-900c-1f21ee5257ab@github.com>
 <tANrlOIzA7klJV-SVrxpvsLDTmwcRXdwTLXwY-y1aF0=.e565e7c1-a563-44d2-9665-43336d6a5936@github.com>
Message-ID: <2cvG8JIT4qtVeu75lpMeQDhGOZCPieLvO8T1bu4Cs8c=.56bf10ee-4699-49cc-8349-060a3d40a159@github.com>

On Wed, 4 Sep 2024 21:17:28 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

>> Please review this cleanup, where we rename `MEMFLAGS` to `MemType`.
>> 
>> `MEMFLAGS` implies that we can use more than one at the same time, but those are exclusive values, so `MemType` is much more suitable name.
>> 
>> There is a bunch of other related cleanup that we can do, but I will leave for follow up issues such as [NMT: rename NMTUtil::flag to NMTUtil::type](https://bugs.openjdk.org/browse/JDK-8337836)
>
> Gerard Ziemski has updated the pull request incrementally with 308 additional commits since the last revision:
> 
>  - undo MEMFLAGS to MemType
>  - 8339233: Test javax/swing/JButton/SwingButtonResizeTestWithOpenGL.java#id failed: Button renderings are different after window resize
>    
>    Reviewed-by: honkar
>  - 8338924: C1: assert(0 <= i && i < _len) failed: illegal index 5 for length 5
>    
>    Co-authored-by: Dean Long <dlong at openjdk.org>
>    Reviewed-by: kvn, thartmann
>  - 8339492: StackMapDecoder::writeFrames makes lots of allocations
>    
>    Reviewed-by: liach, redestad, jwaters, asotona
>  - 8332901: Select{Current,New}ItemTest.java for Choice don't open popup on macOS
>    
>    Move SelectCurrentItemTest.java to java/awt/Choice/SelectItem/.
>    Move SelectNewItemTest.java to java/awt/Choice/SelectItem/.
>    Use latches to control test flow instead of delays.
>    Encapsulate the common logic in SelectCurrentItemTest.
>    Provide overridable checkXXX() methods to modify conditions.
>    Provide an overridable method which defines where to click
>    in the choice popup to select an item.
>    
>    Reviewed-by: honkar, prr, dnguyen
>  - 8339148: Make os::Linux::active_processor_count() public
>    
>    Reviewed-by: dholmes, jwaters
>  - 8339112: Move JVM Klass flags out of AccessFlags
>    
>    Reviewed-by: matsaave, cjplummer, dlong, thartmann, yzheng
>  - 8336860: x86: Change integer src operand for CMoveL of 0 and 1 to long
>    
>    Reviewed-by: epeter, chagedorn, shade, qamai, jbhateja
>  - 8325679: Optimize ArrayList subList sort
>    
>    Reviewed-by: liach
>  - 8339131: Remove rarely-used accessor methods from Opcode
>    
>    Reviewed-by: asotona
>  - ... and 298 more: https://git.openjdk.org/jdk/compare/9665d7f7...6d6d70e9

Yes, I think this PR is not right.

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

PR Comment: https://git.openjdk.org/jdk/pull/20497#issuecomment-2330253062

From wkemper at openjdk.org  Thu Sep  5 14:23:26 2024
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 5 Sep 2024 14:23:26 GMT
Subject: RFR: Merge openjdk/jdk21u-dev:master
Message-ID: <XqL63Q51AUzRMyWi1Vq4nM46ja1jITkf2TCHXvy9L7A=.81efa703-afc0-46ff-97d8-1fc4bd8efada@github.com>

Merges tag jdk-21.0.5+6

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

Commit messages:
 - 8338139: {ClassLoading,Memory}MXBean::isVerbose methods are inconsistent with their setVerbose methods

The merge commit only contains trivial merges, so no merge-specific webrevs have been generated.

Changes: https://git.openjdk.org/shenandoah-jdk21u/pull/76/files
  Stats: 204 lines in 6 files changed: 198 ins; 2 del; 4 mod
  Patch: https://git.openjdk.org/shenandoah-jdk21u/pull/76.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah-jdk21u.git pull/76/head:pull/76

PR: https://git.openjdk.org/shenandoah-jdk21u/pull/76

From gziemski at openjdk.org  Thu Sep  5 15:26:12 2024
From: gziemski at openjdk.org (Gerard Ziemski)
Date: Thu, 5 Sep 2024 15:26:12 GMT
Subject: RFR: 8337563: NMT: rename MEMFLAGS to MemFlag [v2]
In-Reply-To: <tANrlOIzA7klJV-SVrxpvsLDTmwcRXdwTLXwY-y1aF0=.e565e7c1-a563-44d2-9665-43336d6a5936@github.com>
References: <XT8-0JId5lEtWVsceJGTY7lDet5gWNONy1A9rUigZ0g=.be0db307-977f-4bad-900c-1f21ee5257ab@github.com>
 <tANrlOIzA7klJV-SVrxpvsLDTmwcRXdwTLXwY-y1aF0=.e565e7c1-a563-44d2-9665-43336d6a5936@github.com>
Message-ID: <A1338NHIs_wB6fp4_EogFwCg-BrnHabYB6eoF81sCxA=.d0983fbb-e140-41ad-b218-b4d4c7ff64f1@github.com>

On Wed, 4 Sep 2024 21:17:28 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

>> Please review this cleanup, where we rename `MEMFLAGS` to `MemType`.
>> 
>> `MEMFLAGS` implies that we can use more than one at the same time, but those are exclusive values, so `MemType` is much more suitable name.
>> 
>> There is a bunch of other related cleanup that we can do, but I will leave for follow up issues such as [NMT: rename NMTUtil::flag to NMTUtil::type](https://bugs.openjdk.org/browse/JDK-8337836)
>
> Gerard Ziemski has updated the pull request incrementally with 308 additional commits since the last revision:
> 
>  - undo MEMFLAGS to MemType
>  - 8339233: Test javax/swing/JButton/SwingButtonResizeTestWithOpenGL.java#id failed: Button renderings are different after window resize
>    
>    Reviewed-by: honkar
>  - 8338924: C1: assert(0 <= i && i < _len) failed: illegal index 5 for length 5
>    
>    Co-authored-by: Dean Long <dlong at openjdk.org>
>    Reviewed-by: kvn, thartmann
>  - 8339492: StackMapDecoder::writeFrames makes lots of allocations
>    
>    Reviewed-by: liach, redestad, jwaters, asotona
>  - 8332901: Select{Current,New}ItemTest.java for Choice don't open popup on macOS
>    
>    Move SelectCurrentItemTest.java to java/awt/Choice/SelectItem/.
>    Move SelectNewItemTest.java to java/awt/Choice/SelectItem/.
>    Use latches to control test flow instead of delays.
>    Encapsulate the common logic in SelectCurrentItemTest.
>    Provide overridable checkXXX() methods to modify conditions.
>    Provide an overridable method which defines where to click
>    in the choice popup to select an item.
>    
>    Reviewed-by: honkar, prr, dnguyen
>  - 8339148: Make os::Linux::active_processor_count() public
>    
>    Reviewed-by: dholmes, jwaters
>  - 8339112: Move JVM Klass flags out of AccessFlags
>    
>    Reviewed-by: matsaave, cjplummer, dlong, thartmann, yzheng
>  - 8336860: x86: Change integer src operand for CMoveL of 0 and 1 to long
>    
>    Reviewed-by: epeter, chagedorn, shade, qamai, jbhateja
>  - 8325679: Optimize ArrayList subList sort
>    
>    Reviewed-by: liach
>  - 8339131: Remove rarely-used accessor methods from Opcode
>    
>    Reviewed-by: asotona
>  - ... and 298 more: https://git.openjdk.org/jdk/compare/9665d7f7...6d6d70e9

Closing this PR and will move to a new one shortly.

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

PR Comment: https://git.openjdk.org/jdk/pull/20497#issuecomment-2332003251

From gziemski at openjdk.org  Thu Sep  5 15:26:13 2024
From: gziemski at openjdk.org (Gerard Ziemski)
Date: Thu, 5 Sep 2024 15:26:13 GMT
Subject: Withdrawn: 8337563: NMT: rename MEMFLAGS to MemFlag
In-Reply-To: <XT8-0JId5lEtWVsceJGTY7lDet5gWNONy1A9rUigZ0g=.be0db307-977f-4bad-900c-1f21ee5257ab@github.com>
References: <XT8-0JId5lEtWVsceJGTY7lDet5gWNONy1A9rUigZ0g=.be0db307-977f-4bad-900c-1f21ee5257ab@github.com>
Message-ID: <09pdopRRxilGVUe0ELoTG8gMe2rOac9igIl3k_eM0BM=.7fc0ff0c-f7f1-4278-851c-183aa4048dd6@github.com>

On Wed, 7 Aug 2024 17:13:06 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

> Please review this cleanup, where we rename `MEMFLAGS` to `MemType`.
> 
> `MEMFLAGS` implies that we can use more than one at the same time, but those are exclusive values, so `MemType` is much more suitable name.
> 
> There is a bunch of other related cleanup that we can do, but I will leave for follow up issues such as [NMT: rename NMTUtil::flag to NMTUtil::type](https://bugs.openjdk.org/browse/JDK-8337836)

This pull request has been closed without being integrated.

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

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

From gziemski at openjdk.org  Thu Sep  5 16:14:09 2024
From: gziemski at openjdk.org (Gerard Ziemski)
Date: Thu, 5 Sep 2024 16:14:09 GMT
Subject: RFR: 8337563: NMT: rename MEMFLAGS to MemFlag [v2]
In-Reply-To: <tANrlOIzA7klJV-SVrxpvsLDTmwcRXdwTLXwY-y1aF0=.e565e7c1-a563-44d2-9665-43336d6a5936@github.com>
References: <XT8-0JId5lEtWVsceJGTY7lDet5gWNONy1A9rUigZ0g=.be0db307-977f-4bad-900c-1f21ee5257ab@github.com>
 <tANrlOIzA7klJV-SVrxpvsLDTmwcRXdwTLXwY-y1aF0=.e565e7c1-a563-44d2-9665-43336d6a5936@github.com>
Message-ID: <D5TwfTOIcZ05F0NonVVd4jfZwwstC9TArm_nZ36PFMY=.c2ebad95-f89c-442a-b21a-8e49ed780035@github.com>

On Wed, 4 Sep 2024 21:17:28 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

>> Please review this cleanup, where we rename `MEMFLAGS` to `MemType`.
>> 
>> `MEMFLAGS` implies that we can use more than one at the same time, but those are exclusive values, so `MemType` is much more suitable name.
>> 
>> There is a bunch of other related cleanup that we can do, but I will leave for follow up issues such as [NMT: rename NMTUtil::flag to NMTUtil::type](https://bugs.openjdk.org/browse/JDK-8337836)
>
> Gerard Ziemski has updated the pull request incrementally with 308 additional commits since the last revision:
> 
>  - undo MEMFLAGS to MemType
>  - 8339233: Test javax/swing/JButton/SwingButtonResizeTestWithOpenGL.java#id failed: Button renderings are different after window resize
>    
>    Reviewed-by: honkar
>  - 8338924: C1: assert(0 <= i && i < _len) failed: illegal index 5 for length 5
>    
>    Co-authored-by: Dean Long <dlong at openjdk.org>
>    Reviewed-by: kvn, thartmann
>  - 8339492: StackMapDecoder::writeFrames makes lots of allocations
>    
>    Reviewed-by: liach, redestad, jwaters, asotona
>  - 8332901: Select{Current,New}ItemTest.java for Choice don't open popup on macOS
>    
>    Move SelectCurrentItemTest.java to java/awt/Choice/SelectItem/.
>    Move SelectNewItemTest.java to java/awt/Choice/SelectItem/.
>    Use latches to control test flow instead of delays.
>    Encapsulate the common logic in SelectCurrentItemTest.
>    Provide overridable checkXXX() methods to modify conditions.
>    Provide an overridable method which defines where to click
>    in the choice popup to select an item.
>    
>    Reviewed-by: honkar, prr, dnguyen
>  - 8339148: Make os::Linux::active_processor_count() public
>    
>    Reviewed-by: dholmes, jwaters
>  - 8339112: Move JVM Klass flags out of AccessFlags
>    
>    Reviewed-by: matsaave, cjplummer, dlong, thartmann, yzheng
>  - 8336860: x86: Change integer src operand for CMoveL of 0 and 1 to long
>    
>    Reviewed-by: epeter, chagedorn, shade, qamai, jbhateja
>  - 8325679: Optimize ArrayList subList sort
>    
>    Reviewed-by: liach
>  - 8339131: Remove rarely-used accessor methods from Opcode
>    
>    Reviewed-by: asotona
>  - ... and 298 more: https://git.openjdk.org/jdk/compare/9665d7f7...6d6d70e9

The PR has been moved to https://github.com/openjdk/jdk/pull/20872

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

PR Comment: https://git.openjdk.org/jdk/pull/20497#issuecomment-2332134475

From kdnilsen at openjdk.org  Fri Sep  6 00:02:36 2024
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Fri, 6 Sep 2024 00:02:36 GMT
Subject: RFR: 8339611: GenShen: Simplify
 ShenandoahOldHeuristics::trigger_collection_if_fragmented
Message-ID: <q3WvOqHO5pxBtaFlO2Ep4ZibIB1nyEPyQ-1to21TqS4=.31ba4e8d-2096-4bb4-aad5-902839638ac9@github.com>

Replace iterative solution with a single mathematical computation, and adjust old-gen defragmentation efforts to be a bit less aggressive.

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

Commit messages:
 - Fix whitespace
 - Simplify implementation of trigger_collection_if_fragmented()
 - Merge branch 'openjdk:master' into master
 - Merge branch 'openjdk:master' into master
 - Merge branch 'openjdk:master' into master
 - Merge branch 'openjdk:master' into master
 - Merge branch 'openjdk:master' into master
 - Merge branch 'openjdk:master' into master
 - Merge branch 'openjdk:master' into master
 - Merge branch 'openjdk:master' into master
 - ... and 14 more: https://git.openjdk.org/shenandoah/compare/662d146d...56479d90

Changes: https://git.openjdk.org/shenandoah/pull/492/files
  Webrev: https://webrevs.openjdk.org/?repo=shenandoah&pr=492&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8339611
  Stats: 34 lines in 1 file changed: 4 ins; 10 del; 20 mod
  Patch: https://git.openjdk.org/shenandoah/pull/492.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah.git pull/492/head:pull/492

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

From stuefe at openjdk.org  Fri Sep  6 11:59:06 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 6 Sep 2024 11:59:06 GMT
Subject: RFR: 8337563: NMT: rename MEMFLAGS to MemFlag [v2]
In-Reply-To: <tANrlOIzA7klJV-SVrxpvsLDTmwcRXdwTLXwY-y1aF0=.e565e7c1-a563-44d2-9665-43336d6a5936@github.com>
References: <XT8-0JId5lEtWVsceJGTY7lDet5gWNONy1A9rUigZ0g=.be0db307-977f-4bad-900c-1f21ee5257ab@github.com>
 <tANrlOIzA7klJV-SVrxpvsLDTmwcRXdwTLXwY-y1aF0=.e565e7c1-a563-44d2-9665-43336d6a5936@github.com>
Message-ID: <BYr33lSh5QNIgm8-GuRGM3WukKG0f70zkJkucITuaec=.827e76bb-3144-4b8f-8629-c4707bc7276d@github.com>

On Wed, 4 Sep 2024 21:17:28 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

>> Please review this cleanup, where we rename `MEMFLAGS` to `MemType`.
>> 
>> `MEMFLAGS` implies that we can use more than one at the same time, but those are exclusive values, so `MemType` is much more suitable name.
>> 
>> There is a bunch of other related cleanup that we can do, but I will leave for follow up issues such as [NMT: rename NMTUtil::flag to NMTUtil::type](https://bugs.openjdk.org/browse/JDK-8337836)
>
> Gerard Ziemski has updated the pull request incrementally with 308 additional commits since the last revision:
> 
>  - undo MEMFLAGS to MemType
>  - 8339233: Test javax/swing/JButton/SwingButtonResizeTestWithOpenGL.java#id failed: Button renderings are different after window resize
>    
>    Reviewed-by: honkar
>  - 8338924: C1: assert(0 <= i && i < _len) failed: illegal index 5 for length 5
>    
>    Co-authored-by: Dean Long <dlong at openjdk.org>
>    Reviewed-by: kvn, thartmann
>  - 8339492: StackMapDecoder::writeFrames makes lots of allocations
>    
>    Reviewed-by: liach, redestad, jwaters, asotona
>  - 8332901: Select{Current,New}ItemTest.java for Choice don't open popup on macOS
>    
>    Move SelectCurrentItemTest.java to java/awt/Choice/SelectItem/.
>    Move SelectNewItemTest.java to java/awt/Choice/SelectItem/.
>    Use latches to control test flow instead of delays.
>    Encapsulate the common logic in SelectCurrentItemTest.
>    Provide overridable checkXXX() methods to modify conditions.
>    Provide an overridable method which defines where to click
>    in the choice popup to select an item.
>    
>    Reviewed-by: honkar, prr, dnguyen
>  - 8339148: Make os::Linux::active_processor_count() public
>    
>    Reviewed-by: dholmes, jwaters
>  - 8339112: Move JVM Klass flags out of AccessFlags
>    
>    Reviewed-by: matsaave, cjplummer, dlong, thartmann, yzheng
>  - 8336860: x86: Change integer src operand for CMoveL of 0 and 1 to long
>    
>    Reviewed-by: epeter, chagedorn, shade, qamai, jbhateja
>  - 8325679: Optimize ArrayList subList sort
>    
>    Reviewed-by: liach
>  - 8339131: Remove rarely-used accessor methods from Opcode
>    
>    Reviewed-by: asotona
>  - ... and 298 more: https://git.openjdk.org/jdk/compare/9665d7f7...6d6d70e9

I am not excited about the final result, and I pity the poor backport maintainers, but it is also not a hill I'd die on.

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

PR Comment: https://git.openjdk.org/jdk/pull/20497#issuecomment-2333894316

From kdnilsen at openjdk.org  Fri Sep  6 13:39:31 2024
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Fri, 6 Sep 2024 13:39:31 GMT
Subject: RFR: 8339611: GenShen: Simplify
 ShenandoahOldHeuristics::trigger_collection_if_fragmented [v2]
In-Reply-To: <q3WvOqHO5pxBtaFlO2Ep4ZibIB1nyEPyQ-1to21TqS4=.31ba4e8d-2096-4bb4-aad5-902839638ac9@github.com>
References: <q3WvOqHO5pxBtaFlO2Ep4ZibIB1nyEPyQ-1to21TqS4=.31ba4e8d-2096-4bb4-aad5-902839638ac9@github.com>
Message-ID: <W7N9GokysT1WyvUOKQ8B51b5x1IBLLUa-AyyOygX9Lo=.9900c18c-2f03-4349-b98a-bc25c4edae80@github.com>

> Replace iterative solution with a single mathematical computation, and adjust old-gen defragmentation efforts to be a bit less aggressive.

Kelvin Nilsen has updated the pull request incrementally with three additional commits since the last revision:

 - Be less aggressive about triggering old defragmentation
 - Revert "Be even less aggressive in triggering for old fragmentatino"
   
   This reverts commit 8edad5b29b40774073a2a9dc464217341a3e6220.
 - Be even less aggressive in triggering for old fragmentatino

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

Changes:
  - all: https://git.openjdk.org/shenandoah/pull/492/files
  - new: https://git.openjdk.org/shenandoah/pull/492/files/56479d90..76bab3ad

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

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

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

From wkemper at openjdk.org  Fri Sep  6 14:18:52 2024
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 6 Sep 2024 14:18:52 GMT
Subject: RFR: Merge openjdk/jdk:master
Message-ID: <hS4FmVLXJUDz0GxkTfuhAkgzNl3JshEwg5RrnZFplrE=.afc12e77-8ea1-4f6b-80b6-24e8cce28ba2@github.com>

Merges tag jdk-24+14

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

Commit messages:
 - 8332461: ubsan : dependencies.cpp:906:3: runtime error: load of value 4294967295, which is not a valid value for type 'DepType'
 - 8339316: Test runtime/exceptionMsgs/NoClassDefFoundError/NoClassDefFoundErrorTest.java fails after  JDK-8338257
 - 8338937: Optimize the string concatenation of ClassDesc
 - 8338530: CDS warning Skipping java/lang/invoke/BoundMethodHandle$Species_LLLL
 - 8339233: Test javax/swing/JButton/SwingButtonResizeTestWithOpenGL.java#id failed: Button renderings are different after window resize
 - 8338924: C1: assert(0 <= i && i < _len) failed: illegal index 5 for length 5
 - 8339492: StackMapDecoder::writeFrames makes lots of allocations
 - 8332901: Select{Current,New}ItemTest.java for Choice don't open popup on macOS
 - 8339148: Make os::Linux::active_processor_count() public
 - 8339112: Move JVM Klass flags out of AccessFlags
 - ... and 202 more: https://git.openjdk.org/shenandoah/compare/4c344335...28de44da

The webrev contains the conflicts with master:
 - merge conflicts: https://webrevs.openjdk.org/?repo=shenandoah&pr=494&range=00.conflicts

Changes: https://git.openjdk.org/shenandoah/pull/494/files
  Stats: 30870 lines in 994 files changed: 20084 ins; 5721 del; 5065 mod
  Patch: https://git.openjdk.org/shenandoah/pull/494.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah.git pull/494/head:pull/494

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

From gziemski at openjdk.org  Fri Sep  6 18:12:47 2024
From: gziemski at openjdk.org (Gerard Ziemski)
Date: Fri, 6 Sep 2024 18:12:47 GMT
Subject: RFR: 8337563: NMT: rename MEMFLAGS to MemFlag [v2]
In-Reply-To: <tANrlOIzA7klJV-SVrxpvsLDTmwcRXdwTLXwY-y1aF0=.e565e7c1-a563-44d2-9665-43336d6a5936@github.com>
References: <XT8-0JId5lEtWVsceJGTY7lDet5gWNONy1A9rUigZ0g=.be0db307-977f-4bad-900c-1f21ee5257ab@github.com>
 <tANrlOIzA7klJV-SVrxpvsLDTmwcRXdwTLXwY-y1aF0=.e565e7c1-a563-44d2-9665-43336d6a5936@github.com>
Message-ID: <4ANlXGlTJl_PFzySR2lf0kQdvoawEpFJEEp7T5B5ZY8=.6b69de16-6403-474b-9376-1bd4a8a50d14@github.com>

On Wed, 4 Sep 2024 21:17:28 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

>> Please review this cleanup, where we rename `MEMFLAGS` to `MemType`.
>> 
>> `MEMFLAGS` implies that we can use more than one at the same time, but those are exclusive values, so `MemType` is much more suitable name.
>> 
>> There is a bunch of other related cleanup that we can do, but I will leave for follow up issues such as [NMT: rename NMTUtil::flag to NMTUtil::type](https://bugs.openjdk.org/browse/JDK-8337836)
>
> Gerard Ziemski has updated the pull request incrementally with 308 additional commits since the last revision:
> 
>  - undo MEMFLAGS to MemType
>  - 8339233: Test javax/swing/JButton/SwingButtonResizeTestWithOpenGL.java#id failed: Button renderings are different after window resize
>    
>    Reviewed-by: honkar
>  - 8338924: C1: assert(0 <= i && i < _len) failed: illegal index 5 for length 5
>    
>    Co-authored-by: Dean Long <dlong at openjdk.org>
>    Reviewed-by: kvn, thartmann
>  - 8339492: StackMapDecoder::writeFrames makes lots of allocations
>    
>    Reviewed-by: liach, redestad, jwaters, asotona
>  - 8332901: Select{Current,New}ItemTest.java for Choice don't open popup on macOS
>    
>    Move SelectCurrentItemTest.java to java/awt/Choice/SelectItem/.
>    Move SelectNewItemTest.java to java/awt/Choice/SelectItem/.
>    Use latches to control test flow instead of delays.
>    Encapsulate the common logic in SelectCurrentItemTest.
>    Provide overridable checkXXX() methods to modify conditions.
>    Provide an overridable method which defines where to click
>    in the choice popup to select an item.
>    
>    Reviewed-by: honkar, prr, dnguyen
>  - 8339148: Make os::Linux::active_processor_count() public
>    
>    Reviewed-by: dholmes, jwaters
>  - 8339112: Move JVM Klass flags out of AccessFlags
>    
>    Reviewed-by: matsaave, cjplummer, dlong, thartmann, yzheng
>  - 8336860: x86: Change integer src operand for CMoveL of 0 and 1 to long
>    
>    Reviewed-by: epeter, chagedorn, shade, qamai, jbhateja
>  - 8325679: Optimize ArrayList subList sort
>    
>    Reviewed-by: liach
>  - 8339131: Remove rarely-used accessor methods from Opcode
>    
>    Reviewed-by: asotona
>  - ... and 298 more: https://git.openjdk.org/jdk/compare/9665d7f7...6d6d70e9

I'm not as excited about it as I was when started working on it.

Will get https://github.com/openjdk/jdk/pull/20872 ready, then will give it final thought.

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

PR Comment: https://git.openjdk.org/jdk/pull/20497#issuecomment-2334578610

From kdnilsen at openjdk.org  Fri Sep  6 19:17:36 2024
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Fri, 6 Sep 2024 19:17:36 GMT
Subject: RFR: 8339611: GenShen: Simplify
 ShenandoahOldHeuristics::trigger_collection_if_fragmented [v2]
In-Reply-To: <W7N9GokysT1WyvUOKQ8B51b5x1IBLLUa-AyyOygX9Lo=.9900c18c-2f03-4349-b98a-bc25c4edae80@github.com>
References: <q3WvOqHO5pxBtaFlO2Ep4ZibIB1nyEPyQ-1to21TqS4=.31ba4e8d-2096-4bb4-aad5-902839638ac9@github.com>
 <W7N9GokysT1WyvUOKQ8B51b5x1IBLLUa-AyyOygX9Lo=.9900c18c-2f03-4349-b98a-bc25c4edae80@github.com>
Message-ID: <XQ5AhvXa2kCDgnEDk86hDsmMgUgpYEPOJGV2y6y9wZI=.43375872-35c0-465f-91b8-79feb38c294d@github.com>

On Fri, 6 Sep 2024 13:39:31 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> Replace iterative solution with a single mathematical computation, and adjust old-gen defragmentation efforts to be a bit less aggressive.
>
> Kelvin Nilsen has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Be less aggressive about triggering old defragmentation
>  - Revert "Be even less aggressive in triggering for old fragmentatino"
>    
>    This reverts commit 8edad5b29b40774073a2a9dc464217341a3e6220.
>  - Be even less aggressive in triggering for old fragmentatino

src/hotspot/share/gc/shenandoah/heuristics/shenandoahOldHeuristics.cpp line 570:

> 568:     if ((old_span_percent >= 0.50) && (old_density / old_span_percent_squared < 0.75)) {
> 569:       // We trigger old defragmentation, for example, if:
> 570:       //  old_span_percent is 100% and old_density is below 75.0%, or

Note that old_span_percent may be greater than 100%.  Can add comment:
  old_span_percent is 110% and old_density is below 90.8%, or
  
At higher existing utilization, there is less benefit to defragmenting, because there are diminishing returns for the larger efforts.  We're just copying nearly full regions around...

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

PR Review Comment: https://git.openjdk.org/shenandoah/pull/492#discussion_r1747606924

From kdnilsen at openjdk.org  Fri Sep  6 19:42:30 2024
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Fri, 6 Sep 2024 19:42:30 GMT
Subject: RFR: 8339611: GenShen: Simplify
 ShenandoahOldHeuristics::trigger_collection_if_fragmented [v2]
In-Reply-To: <XQ5AhvXa2kCDgnEDk86hDsmMgUgpYEPOJGV2y6y9wZI=.43375872-35c0-465f-91b8-79feb38c294d@github.com>
References: <q3WvOqHO5pxBtaFlO2Ep4ZibIB1nyEPyQ-1to21TqS4=.31ba4e8d-2096-4bb4-aad5-902839638ac9@github.com>
 <W7N9GokysT1WyvUOKQ8B51b5x1IBLLUa-AyyOygX9Lo=.9900c18c-2f03-4349-b98a-bc25c4edae80@github.com>
 <XQ5AhvXa2kCDgnEDk86hDsmMgUgpYEPOJGV2y6y9wZI=.43375872-35c0-465f-91b8-79feb38c294d@github.com>
Message-ID: <lgR4zrz_vkkgYitJPu9oVkqBYjUd0-bvjbXPExgz3ow=.8951ffbf-3775-4156-a500-aa820ab62f6a@github.com>

On Fri, 6 Sep 2024 19:14:49 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> Kelvin Nilsen has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - Be less aggressive about triggering old defragmentation
>>  - Revert "Be even less aggressive in triggering for old fragmentatino"
>>    
>>    This reverts commit 8edad5b29b40774073a2a9dc464217341a3e6220.
>>  - Be even less aggressive in triggering for old fragmentatino
>
> src/hotspot/share/gc/shenandoah/heuristics/shenandoahOldHeuristics.cpp line 570:
> 
>> 568:     if ((old_span_percent >= 0.50) && (old_density / old_span_percent_squared < 0.75)) {
>> 569:       // We trigger old defragmentation, for example, if:
>> 570:       //  old_span_percent is 100% and old_density is below 75.0%, or
> 
> Note that old_span_percent may be greater than 100%.  Can add comment:
>   old_span_percent is 110% and old_density is below 90.8%, or
>   
> At higher existing utilization, there is less benefit to defragmenting, because there are diminishing returns for the larger efforts.  We're just copying nearly full regions around...

But if we are at 110% old_span_percent, we have violated our intended Humongous Reserves, so I'm thinking we should try to squeeze that last 10% out of old so we don't have to STW on the next humongous allocation request...

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

PR Review Comment: https://git.openjdk.org/shenandoah/pull/492#discussion_r1747631843

From wkemper at openjdk.org  Fri Sep  6 19:54:04 2024
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 6 Sep 2024 19:54:04 GMT
Subject: RFR: 8339695: GenShen: Concurrent reset performance has regressed
Message-ID: <z64_ZOf3eSRw-WFEqNDNDWhqBiVQ_tubeKXVQHaZKTc=.55ebcfb8-4e18-4c46-a8f9-5ae318938156@github.com>

A misguided optimization inadvertently increased the time to perform the concurrent reset phase of the GC cycle. This "optimization" has been reverted and the time for the phase has returned to normal.

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

Commit messages:
 - Use region iterator for resetting bitmaps
 - Decouple mark bitmap reset from capturing TAMS closure

Changes: https://git.openjdk.org/shenandoah/pull/495/files
  Webrev: https://webrevs.openjdk.org/?repo=shenandoah&pr=495&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8339695
  Stats: 30 lines in 1 file changed: 10 ins; 10 del; 10 mod
  Patch: https://git.openjdk.org/shenandoah/pull/495.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah.git pull/495/head:pull/495

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

From gziemski at openjdk.org  Fri Sep  6 20:35:29 2024
From: gziemski at openjdk.org (Gerard Ziemski)
Date: Fri, 6 Sep 2024 20:35:29 GMT
Subject: RFR: 8337563: NMT: rename MEMFLAGS to MemTag
Message-ID: <aQDgRwE-H5U0lz8wooLBAQZsuDnB5zZzjMhheIu3y9Y=.0bae7ae4-062e-47de-b7c3-4fedc5d7e20a@github.com>

Please review this cleanup, where we rename `MEMFLAGS` to `MemTag`.

`MEMFLAGS` implies that we can use more than one at the same time, but those are exclusive values, so `MemTag` is a more suitable name.

This fix also includes a cleanup of all the related parameter names and local variable names.

Testing is pending...

Note: there is more history in old closed PRs [https://github.com/openjdk/jdk/pull/20497](https://github.com/openjdk/jdk/pull/20497) and [https://github.com/openjdk/jdk/pull/20472](https://github.com/openjdk/jdk/pull/20472)

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

Commit messages:
 - missed renames on Windows
 - fix test failure
 - fix incorrect rename
 - mssing renames
 - missed _mem_type --> _mem_tags
 - missed MemFlagBitmap --> MemTagBitmap
 - missed tag --> mem_tag
 - missed type --> tag
 - missed type --> tag
 - missed flag_is_valid --> tag_is_valid
 - ... and 1 more: https://git.openjdk.org/jdk/compare/4ffcf894...983bb6e2

Changes: https://git.openjdk.org/jdk/pull/20872/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20872&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8337563
  Stats: 1259 lines in 108 files changed: 142 ins; 138 del; 979 mod
  Patch: https://git.openjdk.org/jdk/pull/20872.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20872/head:pull/20872

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

From gziemski at openjdk.org  Fri Sep  6 21:01:04 2024
From: gziemski at openjdk.org (Gerard Ziemski)
Date: Fri, 6 Sep 2024 21:01:04 GMT
Subject: RFR: 8337563: NMT: rename MEMFLAGS to MemTag
In-Reply-To: <aQDgRwE-H5U0lz8wooLBAQZsuDnB5zZzjMhheIu3y9Y=.0bae7ae4-062e-47de-b7c3-4fedc5d7e20a@github.com>
References: <aQDgRwE-H5U0lz8wooLBAQZsuDnB5zZzjMhheIu3y9Y=.0bae7ae4-062e-47de-b7c3-4fedc5d7e20a@github.com>
Message-ID: <L0yJ6zkBkAeE1GoqVPaOuuNB43vDcTIH6LKZzflR-oE=.e1de249b-5f0f-4e0e-a046-239c906dbefc@github.com>

On Thu, 5 Sep 2024 16:10:05 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

> Please review this cleanup, where we rename `MEMFLAGS` to `MemTag`.
> 
> `MEMFLAGS` implies that we can use more than one at the same time, but those are exclusive values, so `MemTag` is a more suitable name.
> 
> This fix also includes a cleanup of all the related parameter names and local variable names.
> 
> Testing is pending...
> 
> Note: there is more history in old closed PRs [https://github.com/openjdk/jdk/pull/20497](https://github.com/openjdk/jdk/pull/20497) and [https://github.com/openjdk/jdk/pull/20472](https://github.com/openjdk/jdk/pull/20472)

@dholmes-ora @tstuefe @coleenp @stefank @kimbarrett @jdksjolen @afshin-zafari

MEMFLAGS rename task has been moved here.

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

PR Comment: https://git.openjdk.org/jdk/pull/20872#issuecomment-2334800974

From wkemper at openjdk.org  Fri Sep  6 21:31:34 2024
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 6 Sep 2024 21:31:34 GMT
Subject: RFR: 8339611: GenShen: Simplify
 ShenandoahOldHeuristics::trigger_collection_if_fragmented [v2]
In-Reply-To: <lgR4zrz_vkkgYitJPu9oVkqBYjUd0-bvjbXPExgz3ow=.8951ffbf-3775-4156-a500-aa820ab62f6a@github.com>
References: <q3WvOqHO5pxBtaFlO2Ep4ZibIB1nyEPyQ-1to21TqS4=.31ba4e8d-2096-4bb4-aad5-902839638ac9@github.com>
 <W7N9GokysT1WyvUOKQ8B51b5x1IBLLUa-AyyOygX9Lo=.9900c18c-2f03-4349-b98a-bc25c4edae80@github.com>
 <XQ5AhvXa2kCDgnEDk86hDsmMgUgpYEPOJGV2y6y9wZI=.43375872-35c0-465f-91b8-79feb38c294d@github.com>
 <lgR4zrz_vkkgYitJPu9oVkqBYjUd0-bvjbXPExgz3ow=.8951ffbf-3775-4156-a500-aa820ab62f6a@github.com>
Message-ID: <-r69A9Nvfd00Yb1xudacPV-eEDJGhaGj-CXw88ZfGH8=.76e8a84c-0c26-4965-bdd5-fcdff0e400ae@github.com>

On Fri, 6 Sep 2024 19:39:44 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> src/hotspot/share/gc/shenandoah/heuristics/shenandoahOldHeuristics.cpp line 570:
>> 
>>> 568:     if ((old_span_percent >= 0.50) && (old_density / old_span_percent_squared < 0.75)) {
>>> 569:       // We trigger old defragmentation, for example, if:
>>> 570:       //  old_span_percent is 100% and old_density is below 75.0%, or
>> 
>> Note that old_span_percent may be greater than 100%.  Can add comment:
>>   old_span_percent is 110% and old_density is below 90.8%, or
>>   
>> At higher existing utilization, there is less benefit to defragmenting, because there are diminishing returns for the larger efforts.  We're just copying nearly full regions around...
>
> But if we are at 110% old_span_percent, we have violated our intended Humongous Reserves, so I'm thinking we should try to squeeze that last 10% out of old so we don't have to STW on the next humongous allocation request...

I have a few broader questions:
* why is `allowed_old_gen_span` defined in terms of humongous reserve?
* why do we want to square `old_span_percent` and divide it into `old_density`? The comments suggest we ought to be comparing `old_density` directly?

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

PR Review Comment: https://git.openjdk.org/shenandoah/pull/492#discussion_r1747737832

From fyang at openjdk.org  Sat Sep  7 00:47:41 2024
From: fyang at openjdk.org (Fei Yang)
Date: Sat, 7 Sep 2024 00:47:41 GMT
Subject: RFR: 8339643: Port JEP 404 to RISC-V
Message-ID: <J3I-KZdj2aYAEN7cFFDkuZEpp6WBM7AFaikL14CDdWM=.5f1201e3-3ca2-426e-b6ce-a4bd9aa9a879@github.com>

The riscv64 implementation of [JDK-8337511](https://bugs.openjdk.org/browse/JDK-8337511) Implement JEP-404: Generational Shenandoah (Experimental)

Testing
- [x] Gtest (release & fastdebug)
- [x] hotspot_gc_shenandoah (release & fastdebug)

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

Commit messages:
 - JDK-8339643: Port JEP 404 to RISC-V

Changes: https://git.openjdk.org/shenandoah/pull/493/files
  Webrev: https://webrevs.openjdk.org/?repo=shenandoah&pr=493&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8339643
  Stats: 90 lines in 4 files changed: 79 ins; 4 del; 7 mod
  Patch: https://git.openjdk.org/shenandoah/pull/493.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah.git pull/493/head:pull/493

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

From kbarrett at openjdk.org  Sat Sep  7 05:45:07 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Sat, 7 Sep 2024 05:45:07 GMT
Subject: RFR: 8337563: NMT: rename MEMFLAGS to MemTag
In-Reply-To: <aQDgRwE-H5U0lz8wooLBAQZsuDnB5zZzjMhheIu3y9Y=.0bae7ae4-062e-47de-b7c3-4fedc5d7e20a@github.com>
References: <aQDgRwE-H5U0lz8wooLBAQZsuDnB5zZzjMhheIu3y9Y=.0bae7ae4-062e-47de-b7c3-4fedc5d7e20a@github.com>
Message-ID: <1OaddXS4qsgvGkMJXBt8kZRa7J6vQVZH1tdQ22hpGeo=.06168001-0cde-423b-bebb-24bb45d1c155@github.com>

On Thu, 5 Sep 2024 16:10:05 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

> Please review this cleanup, where we rename `MEMFLAGS` to `MemTag`.
> 
> `MEMFLAGS` implies that we can use more than one at the same time, but those are exclusive values, so `MemTag` is a more suitable name.
> 
> This fix also includes a cleanup of all the related parameter names and local variable names.
> 
> Testing is pending...
> 
> Note: there is more history in old closed PRs [https://github.com/openjdk/jdk/pull/20497](https://github.com/openjdk/jdk/pull/20497) and [https://github.com/openjdk/jdk/pull/20472](https://github.com/openjdk/jdk/pull/20472)

I started commenting on `MEMFLAGS F` => `MemType F` template parameters
that needed the parameter name updated, but stopped after a while.  There's a
bunch more, that should be easy enough to find.

I found this very hard to review, esp. after spotting some outright mistakes that
forced me to look much more carefully at all the changes.  I'd have really preferred
seeing this broken up into smaller chunks that weren't quite so soporific.

src/hotspot/share/gc/shared/taskqueue.hpp line 119:

> 117: // TaskQueueSuper collects functionality common to all GenericTaskQueue instances.
> 118: 
> 119: template <unsigned int N, MemTag F>

MemTag parameter name should probably be changed here and elsewhere in taskqueue code.
Suggest `mem_tag`.

src/hotspot/share/runtime/lightweightSynchronizer.cpp line 63:

> 61:     static void* allocate_node(void* context, size_t size, Value const& value) {
> 62:       ObjectMonitorTable::inc_items_count();
> 63:       return AllocateHeap(size, MemTag::mtObjectMonitor);

pre-existing: Why the scope here and below?

src/hotspot/share/runtime/os.hpp line 918:

> 916:   static ssize_t recv(int fd, char* buf, size_t nBytes, uint type);
> 917:   static ssize_t send(int fd, char* buf, size_t nBytes, uint type);
> 918:   static ssize_t raw_send(int fd, char* buf, size_t nBytes, uint type);

This set of changes is wrong.  These aren't MEMFLAGS flags.
(I hope there aren't any more like this.  This sort of thing would be easy to miss in a change this
large.  If I were making this change I'd have broken it up into several smaller pieces.)

src/hotspot/share/utilities/chunkedList.hpp line 31:

> 29: #include "utilities/debug.hpp"
> 30: 
> 31: template <class T, MemTag F> class ChunkedList : public CHeapObj<F> {

Parameter name should be updated.  Suggest `mem_tag`.

src/hotspot/share/utilities/concurrentHashTable.hpp line 43:

> 41: class Mutex;
> 42: 
> 43: template <typename CONFIG, MemTag F>

Parameter name should be updated throughout ConcurrentHashTable. Suggest mem_tag.

src/hotspot/share/utilities/growableArray.hpp line 803:

> 801: 
> 802: // Leaner GrowableArray for CHeap backed data arrays, with compile-time decided MemTag.
> 803: template <typename E, MemTag F>

Another parameter needing update, but shouldn't (can't?) be called `mem_tag` because of the
function parameter name for allocate().

src/hotspot/share/utilities/linkedlist.hpp line 368:

> 366: template <class E, int (*FUNC)(const E&, const E&),
> 367:   AnyObj::allocation_type T = AnyObj::C_HEAP,
> 368:   MemTag F = mtNMT, AllocFailType alloc_failmode = AllocFailStrategy::RETURN_NULL>

Another parameter name needing update.

src/hotspot/share/utilities/objectBitSet.hpp line 42:

> 40:  * during the lifetime of the ObjectBitSet. The underlying memory is allocated from C-Heap.
> 41:  */
> 42: template<MemTag F>

More parameter names needing update.

src/hotspot/share/utilities/resizeableResourceHash.hpp line 33:

> 31:     typename K, typename V,
> 32:     AnyObj::allocation_type ALLOC_TYPE,
> 33:     MemTag MEM_TYPE>

I think s/MEM_TYPE/mem_type/, but other non-type template parameters here are also
all-uppercase, so I guess better to leave it for now and look at it later.

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

Changes requested by kbarrett (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20872#pullrequestreview-2287424615
PR Review Comment: https://git.openjdk.org/jdk/pull/20872#discussion_r1747939080
PR Review Comment: https://git.openjdk.org/jdk/pull/20872#discussion_r1747945078
PR Review Comment: https://git.openjdk.org/jdk/pull/20872#discussion_r1747946449
PR Review Comment: https://git.openjdk.org/jdk/pull/20872#discussion_r1747947967
PR Review Comment: https://git.openjdk.org/jdk/pull/20872#discussion_r1747948639
PR Review Comment: https://git.openjdk.org/jdk/pull/20872#discussion_r1747950081
PR Review Comment: https://git.openjdk.org/jdk/pull/20872#discussion_r1747950278
PR Review Comment: https://git.openjdk.org/jdk/pull/20872#discussion_r1747950612
PR Review Comment: https://git.openjdk.org/jdk/pull/20872#discussion_r1747951327

From dholmes at openjdk.org  Mon Sep  9 00:08:05 2024
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 9 Sep 2024 00:08:05 GMT
Subject: RFR: 8337563: NMT: rename MEMFLAGS to MemTag
In-Reply-To: <1OaddXS4qsgvGkMJXBt8kZRa7J6vQVZH1tdQ22hpGeo=.06168001-0cde-423b-bebb-24bb45d1c155@github.com>
References: <aQDgRwE-H5U0lz8wooLBAQZsuDnB5zZzjMhheIu3y9Y=.0bae7ae4-062e-47de-b7c3-4fedc5d7e20a@github.com>
 <1OaddXS4qsgvGkMJXBt8kZRa7J6vQVZH1tdQ22hpGeo=.06168001-0cde-423b-bebb-24bb45d1c155@github.com>
Message-ID: <z-ebUn0e3FWOsn5bMXNP_Ethi6TubjIEaEEToPYB6Oc=.3c624821-7889-4eab-988e-65e3a44e38e8@github.com>

On Sat, 7 Sep 2024 05:11:25 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Please review this cleanup, where we rename `MEMFLAGS` to `MemTag`.
>> 
>> `MEMFLAGS` implies that we can use more than one at the same time, but those are exclusive values, so `MemTag` is a more suitable name.
>> 
>> This fix also includes a cleanup of all the related parameter names and local variable names.
>> 
>> Testing is pending...
>> 
>> Note: there is more history in old closed PRs [https://github.com/openjdk/jdk/pull/20497](https://github.com/openjdk/jdk/pull/20497) and [https://github.com/openjdk/jdk/pull/20472](https://github.com/openjdk/jdk/pull/20472)
>
> src/hotspot/share/gc/shared/taskqueue.hpp line 119:
> 
>> 117: // TaskQueueSuper collects functionality common to all GenericTaskQueue instances.
>> 118: 
>> 119: template <unsigned int N, MemTag F>
> 
> MemTag parameter name should probably be changed here and elsewhere in taskqueue code.
> Suggest `mem_tag`.

I was going to suggest just MT which is more in keeping with the short/terse names given to type parameters.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20872#discussion_r1749405959

From dholmes at openjdk.org  Mon Sep  9 03:14:07 2024
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 9 Sep 2024 03:14:07 GMT
Subject: RFR: 8337563: NMT: rename MEMFLAGS to MemTag
In-Reply-To: <aQDgRwE-H5U0lz8wooLBAQZsuDnB5zZzjMhheIu3y9Y=.0bae7ae4-062e-47de-b7c3-4fedc5d7e20a@github.com>
References: <aQDgRwE-H5U0lz8wooLBAQZsuDnB5zZzjMhheIu3y9Y=.0bae7ae4-062e-47de-b7c3-4fedc5d7e20a@github.com>
Message-ID: <AbadCvaQQypFx0toL07whop8G9fI4f6oJHbF0S_0ROQ=.49a23938-5229-419d-a412-6283b585793e@github.com>

On Thu, 5 Sep 2024 16:10:05 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

> Please review this cleanup, where we rename `MEMFLAGS` to `MemTag`.
> 
> `MEMFLAGS` implies that we can use more than one at the same time, but those are exclusive values, so `MemTag` is a more suitable name.
> 
> This fix also includes a cleanup of all the related parameter names and local variable names.
> 
> Testing is pending...
> 
> Note: there is more history in old closed PRs [https://github.com/openjdk/jdk/pull/20497](https://github.com/openjdk/jdk/pull/20497) and [https://github.com/openjdk/jdk/pull/20472](https://github.com/openjdk/jdk/pull/20472)

The bulk of this seems fine but as Kim points out the `F` template parameter really needs changing too.

There are also some other questionable changes that I've flagged below.

Thanks

src/hotspot/share/nmt/memMapPrinter.cpp line 70:

> 68:   //end
> 69: 
> 70: static const char* get_shortname_for_nmt_flag(MemTag mem_tag) {

Shouldn't this be renamed to `get_shortname_for_nmt_tag`?

src/hotspot/share/nmt/memReporter.cpp line 852:

> 850:       } else if (early_site->mem_tag() != current_site->mem_tag()) {
> 851:         // This site was originally allocated with one type, then released,
> 852:         // then re-allocated at the same site (as far as we can tell) with a different type.

s/type/tag/

src/hotspot/share/nmt/memTracker.hpp line 83:

> 81:     if (enabled()) {
> 82:       return MallocTracker::record_malloc(mem_base, size, mem_tag, stack);
> 83:       return MallocTracker::record_malloc(mem_base, size, mem_tag, stack);

Did this even compile? !
Suggestion:

      return MallocTracker::record_malloc(mem_base, size, mem_tag, stack);

src/hotspot/share/nmt/memoryFileTracker.cpp line 51:

> 49:   for (int i = 0; i < mt_number_of_tags; i++) {
> 50:     VirtualMemory* summary = file->_summary.by_type(NMTUtil::index_to_tag(i));
> 51:     summary->reserve_memory(diff.type[i].commit);

Why is this `type` not `tag`?

src/hotspot/share/nmt/memoryFileTracker.cpp line 109:

> 107:     tty->print_cr("Expected start out to have same type as end in, but was: %s, %s",
> 108:                   VMATree::statetype_to_string(broken_start->val().out.state()),
> 109:                   VMATree::statetype_to_string(broken_end->val().in.state()));

Not seeing what this rename has to do with current changes. ???

src/hotspot/share/nmt/virtualMemoryTracker.cpp line 400:

> 398: 
> 399:       // Print some more details. Don't use UL here to avoid circularities.
> 400:       tty->print_cr("Error: existing region: [" INTPTR_FORMAT "-" INTPTR_FORMAT "), type %u.\n"

Again why `type` instead of `tag`?

src/hotspot/share/nmt/virtualMemoryTracker.cpp line 560:

> 558: // Given an existing memory mapping registered with NMT, split the mapping in
> 559: //  two. The newly created two mappings will be registered under the call
> 560: //  stack and the memory types of the original section.

types -> tags

src/hotspot/share/nmt/vmatree.cpp line 86:

> 84:         // If the state is not matching then we have different operations, such as:
> 85:         // reserve [x1, A); ... commit [A, x2); or
> 86:         // reserve [x1, A), type1; ... reserve [A, x2), type2; or

Why type not tag?

src/hotspot/share/nmt/vmatree.hpp line 91:

> 89:   private:
> 90:     // Store the state and mem_tag as two bytes
> 91:     uint8_t info[2];

I'm unclear about terminology here: type -> state ?

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

Changes requested by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20872#pullrequestreview-2288637165
PR Review Comment: https://git.openjdk.org/jdk/pull/20872#discussion_r1749408498
PR Review Comment: https://git.openjdk.org/jdk/pull/20872#discussion_r1749409032
PR Review Comment: https://git.openjdk.org/jdk/pull/20872#discussion_r1749409609
PR Review Comment: https://git.openjdk.org/jdk/pull/20872#discussion_r1749410180
PR Review Comment: https://git.openjdk.org/jdk/pull/20872#discussion_r1749410493
PR Review Comment: https://git.openjdk.org/jdk/pull/20872#discussion_r1749411164
PR Review Comment: https://git.openjdk.org/jdk/pull/20872#discussion_r1749411446
PR Review Comment: https://git.openjdk.org/jdk/pull/20872#discussion_r1749411720
PR Review Comment: https://git.openjdk.org/jdk/pull/20872#discussion_r1749412298

From rkennke at openjdk.org  Mon Sep  9 10:29:55 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Mon, 9 Sep 2024 10:29:55 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v7]
In-Reply-To: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
Message-ID: <okQKnqlC8qh08kXMl6p_Vbr1RFA1VVgFRUtc4wRysM0=.1e9da30a-5e40-46e9-bd15-edccea4af792@github.com>

> This is the main body of the JEP 450: Compact Object Headers (Experimental).
> 
> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing.
> 
> Main changes:
>  - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers.
>  - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded.
>  - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops).
>  - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all).
>  - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16).
>  - Arrays will now store their length at offset 8.
>  - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _coh variants of CDS archiv...

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

 - Fix compiler/c2/irTests/TestPadding.java for +COH
 - Simplify arrayOopDesc::length_offset_in_bytes and oopDesc::base_offset_in_bytes
 - Nit in header_size
 - GC code tweaks
 - Fix runtime/cds/appcds/loaderConstraints/DynamicLoaderConstraintsTest.java
 - Fix jdk/tools/jlink/plugins/CDSPluginTest.java
 - Cleanup markWord bits and comments
 - x86_64: Fix loadNKlassCompactHeaders
 - aarch64: Fix loadNKlassCompactHeaders
 - Use FLAG_SET_ERGO when turning off UseCompactObjectHeaders
 - ... and 16 more: https://git.openjdk.org/jdk/compare/b45fe174...49126383

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

Changes: https://git.openjdk.org/jdk/pull/20677/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20677&range=06
  Stats: 4465 lines in 189 files changed: 3175 ins; 678 del; 612 mod
  Patch: https://git.openjdk.org/jdk/pull/20677.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20677/head:pull/20677

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

From rkennke at openjdk.org  Mon Sep  9 11:55:52 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Mon, 9 Sep 2024 11:55:52 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v8]
In-Reply-To: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
Message-ID: <J0g0PSye768dhN3JoXFsZ6FivocNBLPmHNtRUCOmLTw=.5756c64a-4763-4727-9637-ba3fe7b9b17d@github.com>

> This is the main body of the JEP 450: Compact Object Headers (Experimental).
> 
> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing.
> 
> Main changes:
>  - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers.
>  - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded.
>  - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops).
>  - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all).
>  - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16).
>  - Arrays will now store their length at offset 8.
>  - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _coh variants of CDS archiv...

Roman Kennke has updated the pull request incrementally with two additional commits since the last revision:

 - Try to avoid lea in loadNklass (aarch64)
 - Fix release build error

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20677/files
  - new: https://git.openjdk.org/jdk/pull/20677/files/49126383..70f492d3

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

  Stats: 24 lines in 5 files changed: 12 ins; 1 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/20677.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20677/head:pull/20677

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

From tschatzl at openjdk.org  Mon Sep  9 12:40:13 2024
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Mon, 9 Sep 2024 12:40:13 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v7]
In-Reply-To: <okQKnqlC8qh08kXMl6p_Vbr1RFA1VVgFRUtc4wRysM0=.1e9da30a-5e40-46e9-bd15-edccea4af792@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <okQKnqlC8qh08kXMl6p_Vbr1RFA1VVgFRUtc4wRysM0=.1e9da30a-5e40-46e9-bd15-edccea4af792@github.com>
Message-ID: <RpKHsmiTSMtDUKWez7eTvz_lOtfODGQlZeQ4ilt6-ng=.52e0f840-e732-4f0a-b618-dade28b38957@github.com>

On Mon, 9 Sep 2024 10:29:55 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> This is the main body of the JEP 450: Compact Object Headers (Experimental).
>> 
>> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing.
>> 
>> Main changes:
>>  - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers.
>>  - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded.
>>  - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops).
>>  - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all).
>>  - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16).
>>  - Arrays will now store their length at offset 8.
>>  - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _co...
>
> Roman Kennke has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 26 commits:
> 
>  - Fix compiler/c2/irTests/TestPadding.java for +COH
>  - Simplify arrayOopDesc::length_offset_in_bytes and oopDesc::base_offset_in_bytes
>  - Nit in header_size
>  - GC code tweaks
>  - Fix runtime/cds/appcds/loaderConstraints/DynamicLoaderConstraintsTest.java
>  - Fix jdk/tools/jlink/plugins/CDSPluginTest.java
>  - Cleanup markWord bits and comments
>  - x86_64: Fix loadNKlassCompactHeaders
>  - aarch64: Fix loadNKlassCompactHeaders
>  - Use FLAG_SET_ERGO when turning off UseCompactObjectHeaders
>  - ... and 16 more: https://git.openjdk.org/jdk/compare/b45fe174...49126383

src/hotspot/share/gc/g1/g1ParScanThreadState.cpp line 481:

> 479:   Klass* klass = UseCompactObjectHeaders
> 480:       ? old_mark.klass()
> 481:       : old->klass();

To be exact "promotion" only refers to copying to an older generation, so this comment does not cover objects copied within the generation.

Suggestion:

  // NOTE: With compact headers, it is not safe to load the Klass* from old, because
  // that would access the mark-word, that might change at any time by concurrent
  // workers.
  // This mark word would refer to a forwardee, which may not yet have completed
  // copying. Therefore we must load the Klass* from the mark-word that we already
  // loaded. This is safe, because we only enter here if not yet forwarded.

src/hotspot/share/gc/parallel/mutableSpace.cpp line 225:

> 223:       // header-based forwarding during promotion. Full GC doesn't
> 224:       // use the object header for forwarding at all.
> 225:       p += obj->forwardee()->size();

Better use `!obj->is_self_forwarded()` here.

src/hotspot/share/gc/parallel/psPromotionManager.inline.hpp line 174:

> 172:   // may not yet have completed copying. Therefore we must load the Klass* from
> 173:   // the mark-word that we have already loaded. This is safe, because we have checked
> 174:   // that this is not yet forwarded in the caller.)

Same adjustment needed as for G1.

src/hotspot/share/gc/shared/c2/barrierSetC2.cpp line 711:

> 709:   // 8  - 32-bit VM
> 710:   // 12 - 64-bit VM, compressed klass
> 711:   // 16 - 64-bit VM, normal klass

The comment needs to be adapted to include the case for compact object headers.

src/hotspot/share/oops/arrayOop.hpp line 83:

> 81:   // The _length field is not declared in C++.  It is allocated after the
> 82:   // declared nonstatic fields in arrayOopDesc if not compressed, otherwise
> 83:   // it occupies the second half of the _klass field in oopDesc.

Needs update.

src/hotspot/share/oops/instanceOop.hpp line 36:

> 34: class instanceOopDesc : public oopDesc {
> 35:  public:
> 36:   // If compressed, the offset of the fields of the instance may not be aligned.

Needs fixing (or removal) wrt to compact object headers, or move to the particular case.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1750046114
PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1750056160
PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1750074607
PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1750080552
PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1750027009
PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1750116336

From tschatzl at openjdk.org  Mon Sep  9 12:40:14 2024
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Mon, 9 Sep 2024 12:40:14 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v6]
In-Reply-To: <BGmZ04yibLn_KtPyQrA3sQv5OtMonrcDy3aN0vAj8NA=.5de6cae3-3a05-4a74-a15c-aade4176bdeb@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <BGmZ04yibLn_KtPyQrA3sQv5OtMonrcDy3aN0vAj8NA=.5de6cae3-3a05-4a74-a15c-aade4176bdeb@github.com>
Message-ID: <86SISXYdKqHq5_nSqeVVNgmxplVK6QuHvOjCmiCKkzQ=.92ac6af1-9a94-4068-b625-1e331314826e@github.com>

On Thu, 22 Aug 2024 20:08:43 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> This is the main body of the JEP 450: Compact Object Headers (Experimental).
>> 
>> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing.
>> 
>> Main changes:
>>  - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers.
>>  - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded.
>>  - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops).
>>  - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all).
>>  - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16).
>>  - Arrays will now store their length at offset 8.
>>  - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _co...
>
> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix bit counts in GCForwarding

src/hotspot/share/gc/shared/collectedHeap.cpp line 232:

> 230:   }
> 231: 
> 232:   // With compact headers, we can't safely access the class, due

Suggestion:

  // With compact headers, we can't safely access the klass, due


This is the case why? Because we might not have copied the header yet? Is this method actually ever used while the forwarded object is unstable?
Given this is used for verification only afaik, we should make an effort to provide that check.

src/hotspot/share/gc/shared/gcForwarding.hpp line 34:

> 32: 
> 33: /*
> 34:  * Implements forwarding for the full-GCs of Serial, Parallel, G1 and Shenandoah in

Suggestion:

 * Implements forwarding for the Full GCs of Serial, Parallel, G1 and Shenandoah in

src/hotspot/share/gc/shared/gcForwarding.hpp line 41:

> 39:  * bits (to indicate 'forwarded' state as usual).
> 40:  */
> 41: class GCForwarding : public AllStatic {

Since this class is only used for Full GCs, it may be useful to include that information, i.e. something like `FullGCForwarding` to avoid confusion why it is not used for other GCs too.
(Unless this has been discussed and even rejected by me before).

src/hotspot/share/oops/compressedKlass.hpp line 43:

> 41: 
> 42:   // Tiny-class-pointer mode
> 43:   static int _tiny_cp; // -1, 0=true, 1=false

Suggestion:

  static int _tiny_cp; // -1 = uninitialized, 0 = true, 1 = false

In addition to that, I am not sure if introducing a new term ("tiny") for compact class header related changes (and just here) makes the code more clear; I would have expected a "_compact_" prefix. Also all other members use "k"-klass and spell out "klass pointer", so I would prefer to keep that style.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1749995275
PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1749980748
PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1749987945
PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1749969456

From tschatzl at openjdk.org  Mon Sep  9 12:40:18 2024
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Mon, 9 Sep 2024 12:40:18 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v8]
In-Reply-To: <J0g0PSye768dhN3JoXFsZ6FivocNBLPmHNtRUCOmLTw=.5756c64a-4763-4727-9637-ba3fe7b9b17d@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <J0g0PSye768dhN3JoXFsZ6FivocNBLPmHNtRUCOmLTw=.5756c64a-4763-4727-9637-ba3fe7b9b17d@github.com>
Message-ID: <6usTXIvS83aO2VzX5xu2EnXlpIJ8YbfrWS6b3EI0MhE=.0e8cc603-0cd3-4bd9-b309-55e4dd0f0cb0@github.com>

On Mon, 9 Sep 2024 11:55:52 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> This is the main body of the JEP 450: Compact Object Headers (Experimental).
>> 
>> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing.
>> 
>> Main changes:
>>  - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers.
>>  - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded.
>>  - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops).
>>  - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all).
>>  - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16).
>>  - Arrays will now store their length at offset 8.
>>  - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _co...
>
> Roman Kennke has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Try to avoid lea in loadNklass (aarch64)
>  - Fix release build error

src/hotspot/share/oops/klass.hpp line 169:

> 167:                                 // contention that may happen when a nearby object is modified.
> 168:   AccessFlags _access_flags;    // Access flags. The class/interface distinction is stored here.
> 169:                                 // Some flags created by the JVM, not in the class file itself,

Suggestion:

  markWord _prototype_header;   // Used to initialize objects' header with compact headers.


Maybe some comment why this is an instance member.

src/hotspot/share/oops/objArrayKlass.inline.hpp line 74:

> 72: void ObjArrayKlass::oop_oop_iterate(oop obj, OopClosureType* closure) {
> 73:   // In this assert, we cannot safely access the Klass* with compact headers.
> 74:   assert (UseCompactObjectHeaders || obj->is_array(), "obj must be array");

If we can't safely access the `Klass*` here, why is the call to `obj->klass()` below safe?

src/hotspot/share/oops/oop.cpp line 157:

> 155: bool oopDesc::has_klass_gap() {
> 156:   // Only has a klass gap when compressed class pointers are used.
> 157:   // Except when using compact headers.

Suggestion:

  // Only has a klass gap when compressed class pointers are used and not
  // using compact headers.

(Not sure if repeating the fairly simple disjunction below makes sense, but there has been a comment before too)

src/hotspot/share/oops/oop.cpp line 230:

> 228:   // disjunct below to fail if the two comparands are computed across such
> 229:   // a concurrent change.
> 230:   return Universe::heap()->is_stw_gc_active() && klass->is_objArray_klass() && is_forwarded() && (UseParallelGC || UseG1GC);

Is this still true after the recent changes like JDK-8311163? It might be worth waiting for.

src/hotspot/share/oops/oop.hpp line 103:

> 101:   static inline void set_klass_gap(HeapWord* mem, int z);
> 102: 
> 103:   // size of object header, aligned to platform wordSize

Suggestion:

  // Size of object header, aligned to platform wordSize

Pre-existing

src/hotspot/share/oops/oop.hpp line 108:

> 106:       return sizeof(markWord) / HeapWordSize;
> 107:     } else {
> 108:       return sizeof(oopDesc) / HeapWordSize;

Suggestion:

      return sizeof(oopDesc) / HeapWordSize;

src/hotspot/share/oops/oop.hpp line 134:

> 132:   inline Klass*   forward_safe_klass(markWord m) const;
> 133:   inline size_t   forward_safe_size();
> 134:   inline void     forward_safe_init_mark();

Given the comment these methods do not seem "safe" to me. Maybe use "raw" or something to better indicate that care must be taken to use them.

Maybe the "safe" refers to use them only in "safe" contexts, but in Hotspot code iirc we use something like "raw" or "unsafe".

src/hotspot/share/oops/oop.hpp line 295:

> 293:   // this call returns null for that thread; any other thread has the
> 294:   // value of the forwarding pointer returned and does not modify "this".
> 295:   inline oop forward_to_atomic(oop p, markWord compare, atomic_memory_order order = memory_order_conservative);

Maybe add an assert in the implementation so that it is not used for self-forwarding. Same for `forward_to`.

src/hotspot/share/oops/oop.hpp line 356:

> 354:       return mark_offset_in_bytes() + sizeof(markWord) / 2;
> 355:     } else
> 356: #endif

Maybe instead of trying to calculate some random, meaningless value just use some "random" value directly?
I am fine with the existing code, but first stating directly that "any value" works here, this additional code seems to confuse the message. (Fwiw, the method is also used during Universe initialization).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1750118470
PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1750143956
PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1750145460
PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1750150640
PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1750154114
PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1750153663
PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1750157781
PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1750159516
PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1750163768

From tschatzl at openjdk.org  Mon Sep  9 12:45:07 2024
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Mon, 9 Sep 2024 12:45:07 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v8]
In-Reply-To: <J0g0PSye768dhN3JoXFsZ6FivocNBLPmHNtRUCOmLTw=.5756c64a-4763-4727-9637-ba3fe7b9b17d@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <J0g0PSye768dhN3JoXFsZ6FivocNBLPmHNtRUCOmLTw=.5756c64a-4763-4727-9637-ba3fe7b9b17d@github.com>
Message-ID: <aebi9KrSXwlD4fPsZ791PmOsMIsJ4gVzmbtLAw3uoZA=.f3b91b1a-4e97-4ba2-b7c0-533f2f8dbfe4@github.com>

On Mon, 9 Sep 2024 11:55:52 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> This is the main body of the JEP 450: Compact Object Headers (Experimental).
>> 
>> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing.
>> 
>> Main changes:
>>  - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers.
>>  - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded.
>>  - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops).
>>  - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all).
>>  - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16).
>>  - Arrays will now store their length at offset 8.
>>  - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _co...
>
> Roman Kennke has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Try to avoid lea in loadNklass (aarch64)
>  - Fix release build error

Only looked at GC and runtime changes, only very briefly at compiler stuff.

Only looked at GC and runtime changes, only very briefly at compiler stuff.

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

Changes requested by tschatzl (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20677#pullrequestreview-2289786482
PR Review: https://git.openjdk.org/jdk/pull/20677#pullrequestreview-2289800458

From rkennke at openjdk.org  Mon Sep  9 12:52:07 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Mon, 9 Sep 2024 12:52:07 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v3]
In-Reply-To: <LwLTyRUwTUB8Kph7ngHJExHVwAdJSvimoXRsh6A2HcM=.1c03eb16-4e7a-42ac-bbe1-425f4f7fed75@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <bKtmNAMLqRlWTG9MBcosxeh2rYNK_yx_gkh_qbNKt6s=.e23c8a75-0072-4c9f-8d8e-7db14826fded@github.com>
 <ySywujYrcJzmYZtj5oflhcQZbzxPv78dm29gJ5B1fqE=.31b98908-bc0f-48af-b67a-75e7351d1b74@github.com>
 <CjcHSbAikUEXe-wpmu-p2od4z6IN-QC54DCKL5hSaZY=.85532a31-e607-447b-8cea-80e97024f994@github.com>
 <VGJOzveV1b0KxnQ_lSugtMP7boOK5TPmiYT7QXgcCoM=.780e110d-491c-4bbc-9ee7-a7db237ee9dc@github.com>
 <LwLTyRUwTUB8Kph7ngHJExHVwAdJSvimoXRsh6A2HcM=.1c03eb16-4e7a-42ac-bbe1-425f4f7fed75@github.com>
Message-ID: <GA5I5QeGCRY4m_9sFnco0CkvJ18upVlhDSA-VyiNhUw=.6cbd78f0-1064-46dc-8791-18c8c63c5e8c@github.com>

On Fri, 30 Aug 2024 18:10:44 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> FWIW, the ParallelGC does something very similar to what you propose, except that it walks bitmaps instead of paring the space to find the self-forwarded objects. It then has a check inside object_iterate to make sure that it doesn't expose the dead objects (in eden and the from space) to heap dumpers and histogram printers.
>> 
>> Because of the the code above, the SerialGC clears away the information about what objects are dead in eden and the from space, so heap dumpers and histogram printers will include these dead objects. We might want to fix that as a future RFE.
>
>> If we get a promotion failure in the young gen, we are leaving the dead objects marked as forwarded. 
> 
> True; need to do sth like `obj->init_mark();` for the non-self-forwarded case. The postcondition is that no forwarded objs in eden/from.

ParallelGC actually doesn't use bitmaps, it pushes all forwarded objs to preserved-marks-table, and uses that to find forwarded objects, which is why we can't remove the preserved-marks table in ParallelGC (IOW, after this patch, the preserved-marks-stuff in Parallel scavenger is *only* used to find forwarded objects. We might want to think about more efficient solutions for this).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1750199051

From rkennke at openjdk.org  Mon Sep  9 13:02:08 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Mon, 9 Sep 2024 13:02:08 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v5]
In-Reply-To: <3QGPH52NyrDPne5EgoGx2sx9OeGRu9K72onNNwzMr2M=.8a390b3d-2e8a-470e-8bb7-1ba975070c53@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <TzmQRM_6QAc9tdMzNYnzSPR_nENrokTzNx2q-TPuWpw=.cfcbe6f4-4397-4c31-be73-d5a456618090@github.com>
 <-G_gdaZBT2xhZFsdyEwIqiOHpbLpiL79N6NDsW8X2BY=.bc52bd8a-21c5-40e7-a921-a5f68675200f@github.com>
 <BarC_59LJpof-lBzklJ8Dm8liOxnh6jr9cbCn6-NCTI=.64c466f7-c527-44e0-9f5f-2c6928e6a436@github.com>
 <3QGPH52NyrDPne5EgoGx2sx9OeGRu9K72onNNwzMr2M=.8a390b3d-2e8a-470e-8bb7-1ba975070c53@github.com>
Message-ID: <tgYxhCcpQNFDFZ3hfWxp7RYksBd-E2ODD4FctuvjVVY=.5ab13f08-736e-47de-9340-78abbf1a2541@github.com>

On Fri, 30 Aug 2024 07:42:39 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Yes. This silent setting of UseCompactObjectHeaders ended up hiding why we got CDS failures. I would also suggest that we change this to FLAG_SET_ERGO.
>
> Seems we run all into the same thoughts :)
> 
> I added
> 
> Suggestion:
> 
>     FLAG_SET_DEFAULT(UseCompactObjectHeaders, false);
>     warning("Compact object headers require a java heap size smaller than %zu (given: %zu). "
>                  "Disabling compact object headers.", max_narrow_heap_size * HeapWordSize, max_heap_size);

That %zu is SIZE_FORMAT, right? This should probably use proper_unit_for_byte_size()/byte_size_in_proper_unit().

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1750215510

From rkennke at openjdk.org  Mon Sep  9 13:31:10 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Mon, 9 Sep 2024 13:31:10 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v5]
In-Reply-To: <-G_gdaZBT2xhZFsdyEwIqiOHpbLpiL79N6NDsW8X2BY=.bc52bd8a-21c5-40e7-a921-a5f68675200f@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <TzmQRM_6QAc9tdMzNYnzSPR_nENrokTzNx2q-TPuWpw=.cfcbe6f4-4397-4c31-be73-d5a456618090@github.com>
 <-G_gdaZBT2xhZFsdyEwIqiOHpbLpiL79N6NDsW8X2BY=.bc52bd8a-21c5-40e7-a921-a5f68675200f@github.com>
Message-ID: <dFS8lzKbVvuhVhZjOXyp-XwK8PWhXDPmyA3W04sQ0w4=.30f673b8-7cae-4414-8976-1aa2f922828b@github.com>

On Thu, 22 Aug 2024 19:50:21 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix hash shift for 32 bit builds
>
> src/hotspot/share/gc/shared/gcForwarding.hpp line 36:
> 
>> 34:  * Implements forwarding for the full-GCs of Serial, Parallel, G1 and Shenandoah in
>> 35:  * a way that preserves upper N bits of object mark-words, which contain crucial
>> 36:  * Klass* information when running with compact headers. The encoding is similar to
> 
> This doc suggests this forwarding is only for compact-header so I wonder if we can check `UseCompactObjectHeaders` directly instead of heap-size in `GCForwarding::initialize`.

Right. The original implementation was more complex and then the consensus was to not sprinkle UseCompactHeaders all over the place, but with that new/simpler implementation it makes sense to simply check the UCOH flag.

> src/hotspot/share/gc/shared/gcForwarding.hpp line 40:
> 
>> 38:  * heap-base, shifts that difference into the right place, and sets the lowest two
>> 39:  * bits (to indicate 'forwarded' state as usual).
>> 40:  */
> 
>> "can use 40 bits for forwardee encoding. That's enough for 8TB of heap."
> 
> I feel this 8T-constraint is significant and should be in the doc.

Done.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1750264571
PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1750265026

From coleenp at openjdk.org  Mon Sep  9 13:39:07 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 9 Sep 2024 13:39:07 GMT
Subject: RFR: 8337563: NMT: rename MEMFLAGS to MemTag
In-Reply-To: <aQDgRwE-H5U0lz8wooLBAQZsuDnB5zZzjMhheIu3y9Y=.0bae7ae4-062e-47de-b7c3-4fedc5d7e20a@github.com>
References: <aQDgRwE-H5U0lz8wooLBAQZsuDnB5zZzjMhheIu3y9Y=.0bae7ae4-062e-47de-b7c3-4fedc5d7e20a@github.com>
Message-ID: <OG3Zw03Z4VObU1x9alRQpzLpDrmpDFmvhDoKfn1dzrU=.336c0dbe-499a-4da2-af33-234455435a80@github.com>

On Thu, 5 Sep 2024 16:10:05 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

> Please review this cleanup, where we rename `MEMFLAGS` to `MemTag`.
> 
> `MEMFLAGS` implies that we can use more than one at the same time, but those are exclusive values, so `MemTag` is a more suitable name.
> 
> This fix also includes a cleanup of all the related parameter names and local variable names.
> 
> Testing is pending...
> 
> Note: there is more history in old closed PRs [https://github.com/openjdk/jdk/pull/20497](https://github.com/openjdk/jdk/pull/20497) and [https://github.com/openjdk/jdk/pull/20472](https://github.com/openjdk/jdk/pull/20472)

Some people wanted chunks and some people wanted it all at once.    After fixing these instances that you've pointed out, Gerard can have another pass with things that might not be noticed on this pass.

The MemTag F pattern could be changed to MemTag MT (or left for a further review, which is my preference).  The capital letter T seems like a bad choice for this.

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

PR Comment: https://git.openjdk.org/jdk/pull/20872#issuecomment-2338144129

From coleenp at openjdk.org  Mon Sep  9 13:39:09 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 9 Sep 2024 13:39:09 GMT
Subject: RFR: 8337563: NMT: rename MEMFLAGS to MemTag
In-Reply-To: <1OaddXS4qsgvGkMJXBt8kZRa7J6vQVZH1tdQ22hpGeo=.06168001-0cde-423b-bebb-24bb45d1c155@github.com>
References: <aQDgRwE-H5U0lz8wooLBAQZsuDnB5zZzjMhheIu3y9Y=.0bae7ae4-062e-47de-b7c3-4fedc5d7e20a@github.com>
 <1OaddXS4qsgvGkMJXBt8kZRa7J6vQVZH1tdQ22hpGeo=.06168001-0cde-423b-bebb-24bb45d1c155@github.com>
Message-ID: <VZJqPLLe8B9m3uxUOwgjJk4VUHSAfN_6bauoUAznAx8=.37289d82-39fe-4499-9ce8-038e6383dfe1@github.com>

On Sat, 7 Sep 2024 05:27:12 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Please review this cleanup, where we rename `MEMFLAGS` to `MemTag`.
>> 
>> `MEMFLAGS` implies that we can use more than one at the same time, but those are exclusive values, so `MemTag` is a more suitable name.
>> 
>> This fix also includes a cleanup of all the related parameter names and local variable names.
>> 
>> Testing is pending...
>> 
>> Note: there is more history in old closed PRs [https://github.com/openjdk/jdk/pull/20497](https://github.com/openjdk/jdk/pull/20497) and [https://github.com/openjdk/jdk/pull/20472](https://github.com/openjdk/jdk/pull/20472)
>
> src/hotspot/share/utilities/chunkedList.hpp line 31:
> 
>> 29: #include "utilities/debug.hpp"
>> 30: 
>> 31: template <class T, MemTag F> class ChunkedList : public CHeapObj<F> {
> 
> Parameter name should be updated.  Suggest `mem_tag`.

How about MT here or just M?  I would make this a further change though.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20872#discussion_r1750281203

From rkennke at openjdk.org  Mon Sep  9 14:11:08 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Mon, 9 Sep 2024 14:11:08 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v6]
In-Reply-To: <wVUrQQtzaYdZNPBPyiuln0Zd8C67zG2y0yX2Iik6l_I=.0be5dcf7-c48d-4bb9-9966-23530f0b8d2e@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <BGmZ04yibLn_KtPyQrA3sQv5OtMonrcDy3aN0vAj8NA=.5de6cae3-3a05-4a74-a15c-aade4176bdeb@github.com>
 <utcfd2HiwL8a7ut2UJ7tHb1P_oz5TKXA9bwGQ5G_FnE=.63fa2666-dc3f-406d-b8d2-4f960f05f05d@github.com>
 <n33g0VZINE0Qly_UoJV2zOCDkapbuqFgRyzTYor6TrE=.7acb0ac5-5bbe-4747-bf3c-20110201616c@github.com>
 <wVUrQQtzaYdZNPBPyiuln0Zd8C67zG2y0yX2Iik6l_I=.0be5dcf7-c48d-4bb9-9966-23530f0b8d2e@github.com>
Message-ID: <6I0T4rOjOTj-FZxpspatEo6j1_Num75bCAOBNxsrHI8=.097f731e-7c92-4eac-a379-c2df336cd412@github.com>

On Tue, 27 Aug 2024 07:43:07 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> @Hamlin-Li : AFAIK, porting to linux-riscv platform has NOT been started yet. To avoid duplicate work, please let me know if anyone is interested or has been working on it :-)
>
> Yes, I'm interested in it. Thanks for raising the discussion. :)

If anybody is doing it, please send me a patch, or we can do it as a follow-up PR.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1750345203

From rkennke at openjdk.org  Mon Sep  9 14:11:10 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Mon, 9 Sep 2024 14:11:10 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v6]
In-Reply-To: <utcfd2HiwL8a7ut2UJ7tHb1P_oz5TKXA9bwGQ5G_FnE=.63fa2666-dc3f-406d-b8d2-4f960f05f05d@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <BGmZ04yibLn_KtPyQrA3sQv5OtMonrcDy3aN0vAj8NA=.5de6cae3-3a05-4a74-a15c-aade4176bdeb@github.com>
 <utcfd2HiwL8a7ut2UJ7tHb1P_oz5TKXA9bwGQ5G_FnE=.63fa2666-dc3f-406d-b8d2-4f960f05f05d@github.com>
Message-ID: <O7zXQ8Jh20lyh29fRklOZcGNxDSoQiSKA3JkFLelsC4=.4c6a050f-4053-43ff-be03-4336cdaa25a2@github.com>

On Fri, 23 Aug 2024 11:38:39 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix bit counts in GCForwarding
>
> src/hotspot/share/oops/oop.inline.hpp line 94:
> 
>> 92: 
>> 93: void oopDesc::init_mark() {
>> 94:   if (UseCompactObjectHeaders) {
> 
> Seems only `set_mark(prototype_mark());` is fine for both cases?

Right. Done.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1750342555

From rkennke at openjdk.org  Mon Sep  9 14:35:08 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Mon, 9 Sep 2024 14:35:08 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v6]
In-Reply-To: <Og4I5G3w51d7zF27JawLM9pm_XpHwijYt3lJZ4hpeWQ=.fd974e82-2ce0-4ebd-b49e-108ab87690a9@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <BGmZ04yibLn_KtPyQrA3sQv5OtMonrcDy3aN0vAj8NA=.5de6cae3-3a05-4a74-a15c-aade4176bdeb@github.com>
 <Og4I5G3w51d7zF27JawLM9pm_XpHwijYt3lJZ4hpeWQ=.fd974e82-2ce0-4ebd-b49e-108ab87690a9@github.com>
Message-ID: <S-95OBPOZb6GfBEUIDtHxCB4hTFPB2uNf5YmwMerGcE=.83afc323-883e-4ae0-8d10-fe7030cddb33@github.com>

On Mon, 26 Aug 2024 21:52:58 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix bit counts in GCForwarding
>
> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/Oop.java line 169:
> 
>> 167:         } else {
>> 168:           visitor.doMetadata(klass, true);
>> 169:         }
> 
> Why is there no `visitor.doMetadata()` call for the compact object header case?

There is no dedicated klass field anymore, the Klass* is encoded in the mark, and we would need to extract it. What is the purpose of the visitors? Do they need to see the klass/compressedKlass, or is it sufficient to visit the mark-word (which we already do, but as CInt).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1750386024

From stefank at openjdk.org  Mon Sep  9 14:50:10 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Mon, 9 Sep 2024 14:50:10 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v6]
In-Reply-To: <ppEMUrlGXfCRo9oZPRt0xf_FrD3-pv5SjJh8eBoe3TU=.92c19564-443c-41d0-b047-0a9a7c6dad10@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <BGmZ04yibLn_KtPyQrA3sQv5OtMonrcDy3aN0vAj8NA=.5de6cae3-3a05-4a74-a15c-aade4176bdeb@github.com>
 <ppEMUrlGXfCRo9oZPRt0xf_FrD3-pv5SjJh8eBoe3TU=.92c19564-443c-41d0-b047-0a9a7c6dad10@github.com>
Message-ID: <4yTWbD93OXGwYYxEQo56smKa5kl_WiPPcMsXSs0eUoQ=.893f54c8-ed2b-4a7f-bf0a-36553a951f47@github.com>

On Fri, 30 Aug 2024 08:06:31 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix bit counts in GCForwarding
>
> src/hotspot/share/cds/filemap.cpp line 2507:
> 
>> 2505:   }
>> 2506: 
>> 2507:   if (compact_headers() != UseCompactObjectHeaders) {
> 
> (Commenting here, but the comment applies to code a bit above) While debugging CDS, it would have been useful to print the value of UseCompactObjectHeaders.
> 
> Could we change the code to be:
> 
>   log_info(cds)("Archive was created with UseCompressedOops = %d, UseCompressedClassPointers = %d, UseCompactObjectHeaders = %d",
>                           compressed_oops(), compressed_class_pointers(), compact_headers());

Resolved.

> src/hotspot/share/cds/filemap.cpp line 2508:
> 
>> 2506: 
>> 2507:   if (compact_headers() != UseCompactObjectHeaders) {
>> 2508:     log_info(cds)("The shared archive file's UseCompactObjectHeaders setting (%s)"
> 
> Printing on the `info` level mimics what we do when there's a mismatch for compressed classes (and oops), but I wonder if that one is intentional or if it is accidentally printing to 'info' instead of 'warning'.

@iklam informed me that some of the info levels (including this line) should be converted to warning.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1750408043
PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1750410679

From rkennke at openjdk.org  Mon Sep  9 15:04:09 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Mon, 9 Sep 2024 15:04:09 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v6]
In-Reply-To: <4yTWbD93OXGwYYxEQo56smKa5kl_WiPPcMsXSs0eUoQ=.893f54c8-ed2b-4a7f-bf0a-36553a951f47@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <BGmZ04yibLn_KtPyQrA3sQv5OtMonrcDy3aN0vAj8NA=.5de6cae3-3a05-4a74-a15c-aade4176bdeb@github.com>
 <ppEMUrlGXfCRo9oZPRt0xf_FrD3-pv5SjJh8eBoe3TU=.92c19564-443c-41d0-b047-0a9a7c6dad10@github.com>
 <4yTWbD93OXGwYYxEQo56smKa5kl_WiPPcMsXSs0eUoQ=.893f54c8-ed2b-4a7f-bf0a-36553a951f47@github.com>
Message-ID: <-2JWx3F8EdyQ0Uf-mI62ImLXgjgIy9PEydjtKHhx12Q=.4d944301-6f1c-4270-953c-ec6c86df946a@github.com>

On Mon, 9 Sep 2024 14:47:28 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> src/hotspot/share/cds/filemap.cpp line 2508:
>> 
>>> 2506: 
>>> 2507:   if (compact_headers() != UseCompactObjectHeaders) {
>>> 2508:     log_info(cds)("The shared archive file's UseCompactObjectHeaders setting (%s)"
>> 
>> Printing on the `info` level mimics what we do when there's a mismatch for compressed classes (and oops), but I wonder if that one is intentional or if it is accidentally printing to 'info' instead of 'warning'.
>
> @iklam informed me that some of the info levels (including this line) should be converted to warning.

Yeah that looks inconsistent with other places where we print a warning instead. I'll change it to warning for the UCOH check.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1750430001

From stefank at openjdk.org  Mon Sep  9 15:04:12 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Mon, 9 Sep 2024 15:04:12 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v8]
In-Reply-To: <6usTXIvS83aO2VzX5xu2EnXlpIJ8YbfrWS6b3EI0MhE=.0e8cc603-0cd3-4bd9-b309-55e4dd0f0cb0@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <J0g0PSye768dhN3JoXFsZ6FivocNBLPmHNtRUCOmLTw=.5756c64a-4763-4727-9637-ba3fe7b9b17d@github.com>
 <6usTXIvS83aO2VzX5xu2EnXlpIJ8YbfrWS6b3EI0MhE=.0e8cc603-0cd3-4bd9-b309-55e4dd0f0cb0@github.com>
Message-ID: <rhloCBhjvBZ4Cs8LLpD_UyHIBR08b8NIjXwIEQlirrs=.8a06186e-a315-4977-961c-b172e077bd9a@github.com>

On Mon, 9 Sep 2024 12:21:19 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Roman Kennke has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Try to avoid lea in loadNklass (aarch64)
>>  - Fix release build error
>
> src/hotspot/share/oops/oop.hpp line 134:
> 
>> 132:   inline Klass*   forward_safe_klass(markWord m) const;
>> 133:   inline size_t   forward_safe_size();
>> 134:   inline void     forward_safe_init_mark();
> 
> Given the comment these methods do not seem "safe" to me. Maybe use "raw" or something to better indicate that care must be taken to use them.
> 
> Maybe the "safe" refers to use them only in "safe" contexts, but in Hotspot code iirc we use something like "raw" or "unsafe".

Restating my earlier comment about this: These functions are mainly used by the GCs. In one of the patches I've cleaned away all usages except for those in Shenandoah. I would prefer to see these completely removed from the oops/ directory and let the GCs decide when and how to perform "safe" reads of these values.

> src/hotspot/share/oops/oop.hpp line 356:
> 
>> 354:       return mark_offset_in_bytes() + sizeof(markWord) / 2;
>> 355:     } else
>> 356: #endif
> 
> Maybe instead of trying to calculate some random, meaningless value just use some "random" value directly?
> I am fine with the existing code, but first stating directly that "any value" works here, this additional code seems to confuse the message. (Fwiw, the method is also used during Universe initialization).

Just to be clear, the second part of the quoted sentence is important:
> could be any value *that is not a valid field offset*

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1750428581
PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1750432186

From tschatzl at openjdk.org  Mon Sep  9 15:04:12 2024
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Mon, 9 Sep 2024 15:04:12 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v8]
In-Reply-To: <rhloCBhjvBZ4Cs8LLpD_UyHIBR08b8NIjXwIEQlirrs=.8a06186e-a315-4977-961c-b172e077bd9a@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <J0g0PSye768dhN3JoXFsZ6FivocNBLPmHNtRUCOmLTw=.5756c64a-4763-4727-9637-ba3fe7b9b17d@github.com>
 <6usTXIvS83aO2VzX5xu2EnXlpIJ8YbfrWS6b3EI0MhE=.0e8cc603-0cd3-4bd9-b309-55e4dd0f0cb0@github.com>
 <rhloCBhjvBZ4Cs8LLpD_UyHIBR08b8NIjXwIEQlirrs=.8a06186e-a315-4977-961c-b172e077bd9a@github.com>
Message-ID: <W-1ANH5uIdfAoNRB5Mp1wbdS_aswZz8JhdHNNzz6pMw=.b3e0db43-1df0-4b0f-a6fe-ca77aa23d8f1@github.com>

On Mon, 9 Sep 2024 15:00:09 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>     could be any value that is not a valid field offset

I understand that that "random value" needs to satisfy this condition.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1750433800

From shade at openjdk.org  Mon Sep  9 15:10:41 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 9 Sep 2024 15:10:41 GMT
Subject: RFR: 8339695: GenShen: Concurrent reset performance has regressed
In-Reply-To: <z64_ZOf3eSRw-WFEqNDNDWhqBiVQ_tubeKXVQHaZKTc=.55ebcfb8-4e18-4c46-a8f9-5ae318938156@github.com>
References: <z64_ZOf3eSRw-WFEqNDNDWhqBiVQ_tubeKXVQHaZKTc=.55ebcfb8-4e18-4c46-a8f9-5ae318938156@github.com>
Message-ID: <biUoeUW-106lc9EbF1fZPBO9N1GXroJVWu3JARP1lBg=.e3f86cbe-78e4-4b87-bfb9-00db25cc30c8@github.com>

On Fri, 6 Sep 2024 19:47:50 GMT, William Kemper <wkemper at openjdk.org> wrote:

> A misguided optimization inadvertently increased the time to perform the concurrent reset phase of the GC cycle. This "optimization" has been reverted and the time for the phase has returned to normal.

Looks fine, consider a simple nit.

src/hotspot/share/gc/shenandoah/shenandoahGeneration.cpp line 69:

> 67:  private:
> 68:     ShenandoahRegionIterator _regions;
> 69:     ShenandoahGeneration* _generation;

Seems mis-indented a bit.

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

Marked as reviewed by shade (Committer).

PR Review: https://git.openjdk.org/shenandoah/pull/495#pullrequestreview-2290209146
PR Review Comment: https://git.openjdk.org/shenandoah/pull/495#discussion_r1750443643

From stefank at openjdk.org  Mon Sep  9 15:34:09 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Mon, 9 Sep 2024 15:34:09 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v3]
In-Reply-To: <GA5I5QeGCRY4m_9sFnco0CkvJ18upVlhDSA-VyiNhUw=.6cbd78f0-1064-46dc-8791-18c8c63c5e8c@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <bKtmNAMLqRlWTG9MBcosxeh2rYNK_yx_gkh_qbNKt6s=.e23c8a75-0072-4c9f-8d8e-7db14826fded@github.com>
 <ySywujYrcJzmYZtj5oflhcQZbzxPv78dm29gJ5B1fqE=.31b98908-bc0f-48af-b67a-75e7351d1b74@github.com>
 <CjcHSbAikUEXe-wpmu-p2od4z6IN-QC54DCKL5hSaZY=.85532a31-e607-447b-8cea-80e97024f994@github.com>
 <VGJOzveV1b0KxnQ_lSugtMP7boOK5TPmiYT7QXgcCoM=.780e110d-491c-4bbc-9ee7-a7db237ee9dc@github.com>
 <LwLTyRUwTUB8Kph7ngHJExHVwAdJSvimoXRsh6A2HcM=.1c03eb16-4e7a-42ac-bbe1-425f4f7fed75@github.com>
 <GA5I5QeGCRY4m_9sFnco0CkvJ18upVlhDSA-VyiNhUw=.6cbd78f0-1064-46dc-8791-18c8c63c5e8c@github.com>
Message-ID: <c4JGl_coRGcWROB9KAlYGOt5zBCqqoFH_oYGKtq9z0M=.3cdaecfb-eef0-4d40-9b51-7df223118d10@github.com>

On Mon, 9 Sep 2024 12:49:05 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>>> If we get a promotion failure in the young gen, we are leaving the dead objects marked as forwarded. 
>> 
>> True; need to do sth like `obj->init_mark();` for the non-self-forwarded case. The postcondition is that no forwarded objs in eden/from.
>
> ParallelGC actually doesn't use bitmaps, it pushes all forwarded objs to preserved-marks-table, and uses that to find forwarded objects, which is why we can't remove the preserved-marks table in ParallelGC (IOW, after this patch, the preserved-marks-stuff in Parallel scavenger is *only* used to find forwarded objects. We might want to think about more efficient solutions for this).

(Just to clarify if others are reading this)

Right, what I referred to above was how we found the object to forward, which is done via the bitmaps:

          while (cur_addr < region_end) {
            cur_addr = mark_bitmap()->find_obj_beg(cur_addr, region_end);

If the Parallel Old collector didn't do that, but instead parsed the heap like Serial does, then the Parallel Young collector would also have to fix the from space copies of moved objects when when it hits a promotion failure, just like Serial does. This was just meant to point out the differences between the two collectors and why the young GC code is different.

I realize that in earlier comments I called the from-space copy of the objects "dead objects", but they are not dead they are just the stale objects that are discoverable because of promotion failure keeping the eden and from spaces.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1750480983

From stefank at openjdk.org  Mon Sep  9 15:34:10 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Mon, 9 Sep 2024 15:34:10 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v5]
In-Reply-To: <tgYxhCcpQNFDFZ3hfWxp7RYksBd-E2ODD4FctuvjVVY=.5ab13f08-736e-47de-9340-78abbf1a2541@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <TzmQRM_6QAc9tdMzNYnzSPR_nENrokTzNx2q-TPuWpw=.cfcbe6f4-4397-4c31-be73-d5a456618090@github.com>
 <-G_gdaZBT2xhZFsdyEwIqiOHpbLpiL79N6NDsW8X2BY=.bc52bd8a-21c5-40e7-a921-a5f68675200f@github.com>
 <BarC_59LJpof-lBzklJ8Dm8liOxnh6jr9cbCn6-NCTI=.64c466f7-c527-44e0-9f5f-2c6928e6a436@github.com>
 <3QGPH52NyrDPne5EgoGx2sx9OeGRu9K72onNNwzMr2M=.8a390b3d-2e8a-470e-8bb7-1ba975070c53@github.com>
 <tgYxhCcpQNFDFZ3hfWxp7RYksBd-E2ODD4FctuvjVVY=.5ab13f08-736e-47de-9340-78abbf1a2541@github.com>
Message-ID: <h4Kzrm_0dTMlvlrqQwTW6ZoSifbhEZjrTB0Cyd4Kf7M=.8c70440e-e19a-45c0-ac97-d9fd22f774ed@github.com>

On Mon, 9 Sep 2024 12:59:36 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> That %zu is SIZE_FORMAT, right?

Yes. Reviewers have lately encouraged people to use %zu instead of SIZE_FORMAT.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1750482486

From cjplummer at openjdk.org  Mon Sep  9 16:56:08 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Mon, 9 Sep 2024 16:56:08 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v6]
In-Reply-To: <Og4I5G3w51d7zF27JawLM9pm_XpHwijYt3lJZ4hpeWQ=.fd974e82-2ce0-4ebd-b49e-108ab87690a9@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <BGmZ04yibLn_KtPyQrA3sQv5OtMonrcDy3aN0vAj8NA=.5de6cae3-3a05-4a74-a15c-aade4176bdeb@github.com>
 <Og4I5G3w51d7zF27JawLM9pm_XpHwijYt3lJZ4hpeWQ=.fd974e82-2ce0-4ebd-b49e-108ab87690a9@github.com>
Message-ID: <1VACYSoQRtP9m4BJkCVrdFxueC75Kg4Kp3wjGsAA2Dw=.53563f62-70cf-4d93-8d99-69b737812ba6@github.com>

On Mon, 26 Aug 2024 21:30:51 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix bit counts in GCForwarding
>
> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/Oop.java line 85:
> 
>> 83: 
>> 84:   private static Klass getKlass(Mark mark) {
>> 85:     assert(VM.getVM().isCompactObjectHeadersEnabled());
> 
> `mark.getKlass()` already does this assert. I don't see any value in this `getKlass()` method. The caller should just call `getMark().getKlass()` rather than `getKlass(getMark())`.

I'm not sure why this got marked as resolved.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1750600652

From cjplummer at openjdk.org  Mon Sep  9 16:56:08 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Mon, 9 Sep 2024 16:56:08 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v6]
In-Reply-To: <S-95OBPOZb6GfBEUIDtHxCB4hTFPB2uNf5YmwMerGcE=.83afc323-883e-4ae0-8d10-fe7030cddb33@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <BGmZ04yibLn_KtPyQrA3sQv5OtMonrcDy3aN0vAj8NA=.5de6cae3-3a05-4a74-a15c-aade4176bdeb@github.com>
 <Og4I5G3w51d7zF27JawLM9pm_XpHwijYt3lJZ4hpeWQ=.fd974e82-2ce0-4ebd-b49e-108ab87690a9@github.com>
 <S-95OBPOZb6GfBEUIDtHxCB4hTFPB2uNf5YmwMerGcE=.83afc323-883e-4ae0-8d10-fe7030cddb33@github.com>
Message-ID: <ZnddOJnCLP0HABu3ymeWaAvcJNd3mKz8AhFwOtUAYW8=.f534bbd8-c222-4cd7-b6a9-3d6fd644c5e1@github.com>

On Mon, 9 Sep 2024 14:32:49 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/Oop.java line 169:
>> 
>>> 167:         } else {
>>> 168:           visitor.doMetadata(klass, true);
>>> 169:         }
>> 
>> Why is there no `visitor.doMetadata()` call for the compact object header case?
>
> There is no dedicated klass field anymore, the Klass* is encoded in the mark, and we would need to extract it. What is the purpose of the visitors? Do they need to see the klass/compressedKlass, or is it sufficient to visit the mark-word (which we already do, but as CInt).

I've been looking into this. It's a bit hard to follow but I think you do need to do something more here. Can you run ClhsdbInspect.java and send me the output. In specific I need to know if the log includes the following:


hsdb> + inspect 0x00000007cff154b8
instance of Oop for java/util/concurrent/locks/AbstractQueuedSynchronizer$ConditionObject @ 0x00000007cff154b8 (size = 24)
_mark: 1
_metadata._compressed_klass: InstanceKlass for java/util/concurrent/locks/AbstractQueuedSynchronizer$ConditionObject
firstWaiter: Oop for java/util/concurrent/locks/AbstractQueuedSynchronizer$ConditionNode @ 0x00000007cfff5f80
lastWaiter: Oop for java/util/concurrent/locks/AbstractQueuedSynchronizer$ConditionNode @ 0x00000007cfff5f80
this$0: Oop for java/util/concurrent/locks/ReentrantLock$NonfairSync @ 0x00000007cff15498

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1750598648

From gziemski at openjdk.org  Mon Sep  9 17:00:10 2024
From: gziemski at openjdk.org (Gerard Ziemski)
Date: Mon, 9 Sep 2024 17:00:10 GMT
Subject: RFR: 8337563: NMT: rename MEMFLAGS to MemTag
In-Reply-To: <AbadCvaQQypFx0toL07whop8G9fI4f6oJHbF0S_0ROQ=.49a23938-5229-419d-a412-6283b585793e@github.com>
References: <aQDgRwE-H5U0lz8wooLBAQZsuDnB5zZzjMhheIu3y9Y=.0bae7ae4-062e-47de-b7c3-4fedc5d7e20a@github.com>
 <AbadCvaQQypFx0toL07whop8G9fI4f6oJHbF0S_0ROQ=.49a23938-5229-419d-a412-6283b585793e@github.com>
Message-ID: <H_mPghzVaszsx2lIsiLhyR7_v0wlw0_VEBt0O_IGNHM=.2de31409-c8fa-4285-be0f-2829cc45a50d@github.com>

On Mon, 9 Sep 2024 00:13:25 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Please review this cleanup, where we rename `MEMFLAGS` to `MemTag`.
>> 
>> `MEMFLAGS` implies that we can use more than one at the same time, but those are exclusive values, so `MemTag` is a more suitable name.
>> 
>> This fix also includes a cleanup of all the related parameter names and local variable names.
>> 
>> Testing is pending...
>> 
>> Note: there is more history in old closed PRs [https://github.com/openjdk/jdk/pull/20497](https://github.com/openjdk/jdk/pull/20497) and [https://github.com/openjdk/jdk/pull/20472](https://github.com/openjdk/jdk/pull/20472)
>
> src/hotspot/share/nmt/memMapPrinter.cpp line 70:
> 
>> 68:   //end
>> 69: 
>> 70: static const char* get_shortname_for_nmt_flag(MemTag mem_tag) {
> 
> Shouldn't this be renamed to `get_shortname_for_nmt_tag`?

I went with `get_shortname_for_mem_tag()` I think that is more consistent? Is that OK?

> src/hotspot/share/nmt/memReporter.cpp line 852:
> 
>> 850:       } else if (early_site->mem_tag() != current_site->mem_tag()) {
>> 851:         // This site was originally allocated with one type, then released,
>> 852:         // then re-allocated at the same site (as far as we can tell) with a different type.
> 
> s/type/tag/

Fixed.

> src/hotspot/share/nmt/memTracker.hpp line 83:
> 
>> 81:     if (enabled()) {
>> 82:       return MallocTracker::record_malloc(mem_base, size, mem_tag, stack);
>> 83:       return MallocTracker::record_malloc(mem_base, size, mem_tag, stack);
> 
> Did this even compile? !
> Suggestion:
> 
>       return MallocTracker::record_malloc(mem_base, size, mem_tag, stack);

Fixed. None of the compilers had a problem with this weirdly enough.

> src/hotspot/share/nmt/memoryFileTracker.cpp line 51:
> 
>> 49:   for (int i = 0; i < mt_number_of_tags; i++) {
>> 50:     VirtualMemory* summary = file->_summary.by_type(NMTUtil::index_to_tag(i));
>> 51:     summary->reserve_memory(diff.type[i].commit);
> 
> Why is this `type` not `tag`?

Fixed.

> src/hotspot/share/nmt/memoryFileTracker.cpp line 109:
> 
>> 107:     tty->print_cr("Expected start out to have same type as end in, but was: %s, %s",
>> 108:                   VMATree::statetype_to_string(broken_start->val().out.state()),
>> 109:                   VMATree::statetype_to_string(broken_end->val().in.state()));
> 
> Not seeing what this rename has to do with current changes. ???

Fixed.

> src/hotspot/share/nmt/virtualMemoryTracker.cpp line 400:
> 
>> 398: 
>> 399:       // Print some more details. Don't use UL here to avoid circularities.
>> 400:       tty->print_cr("Error: existing region: [" INTPTR_FORMAT "-" INTPTR_FORMAT "), type %u.\n"
> 
> Again why `type` instead of `tag`?

Fixed.

> src/hotspot/share/nmt/virtualMemoryTracker.cpp line 560:
> 
>> 558: // Given an existing memory mapping registered with NMT, split the mapping in
>> 559: //  two. The newly created two mappings will be registered under the call
>> 560: //  stack and the memory types of the original section.
> 
> types -> tags

Fixed.

> src/hotspot/share/nmt/vmatree.cpp line 86:
> 
>> 84:         // If the state is not matching then we have different operations, such as:
>> 85:         // reserve [x1, A); ... commit [A, x2); or
>> 86:         // reserve [x1, A), type1; ... reserve [A, x2), type2; or
> 
> Why type not tag?

I will fix it.

> src/hotspot/share/nmt/vmatree.hpp line 91:
> 
>> 89:   private:
>> 90:     // Store the state and mem_tag as two bytes
>> 91:     uint8_t info[2];
> 
> I'm unclear about terminology here: type -> state ?

Those come from my initial fix, when I renamed `MEMFLAGS` -> `MemType`.

In that work the type_flag was clashing with mem_type parameter, so I renamed it from `type` to `state` 

I tried to re-use that original patch, but as you just found, some of those changes do not apply.

I will undo this change.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20872#discussion_r1750598453
PR Review Comment: https://git.openjdk.org/jdk/pull/20872#discussion_r1750596573
PR Review Comment: https://git.openjdk.org/jdk/pull/20872#discussion_r1750595789
PR Review Comment: https://git.openjdk.org/jdk/pull/20872#discussion_r1750592818
PR Review Comment: https://git.openjdk.org/jdk/pull/20872#discussion_r1750589625
PR Review Comment: https://git.openjdk.org/jdk/pull/20872#discussion_r1750588916
PR Review Comment: https://git.openjdk.org/jdk/pull/20872#discussion_r1750587807
PR Review Comment: https://git.openjdk.org/jdk/pull/20872#discussion_r1750586650
PR Review Comment: https://git.openjdk.org/jdk/pull/20872#discussion_r1750583730

From gziemski at openjdk.org  Mon Sep  9 17:00:14 2024
From: gziemski at openjdk.org (Gerard Ziemski)
Date: Mon, 9 Sep 2024 17:00:14 GMT
Subject: RFR: 8337563: NMT: rename MEMFLAGS to MemTag
In-Reply-To: <1OaddXS4qsgvGkMJXBt8kZRa7J6vQVZH1tdQ22hpGeo=.06168001-0cde-423b-bebb-24bb45d1c155@github.com>
References: <aQDgRwE-H5U0lz8wooLBAQZsuDnB5zZzjMhheIu3y9Y=.0bae7ae4-062e-47de-b7c3-4fedc5d7e20a@github.com>
 <1OaddXS4qsgvGkMJXBt8kZRa7J6vQVZH1tdQ22hpGeo=.06168001-0cde-423b-bebb-24bb45d1c155@github.com>
Message-ID: <SgWP7FKL89yi7mhJGq6VTxRQvTNuZJ1Xh_kPzhNfbQM=.df509dc1-235a-403d-9806-51ff3feb86d6@github.com>

On Sat, 7 Sep 2024 05:24:29 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Please review this cleanup, where we rename `MEMFLAGS` to `MemTag`.
>> 
>> `MEMFLAGS` implies that we can use more than one at the same time, but those are exclusive values, so `MemTag` is a more suitable name.
>> 
>> This fix also includes a cleanup of all the related parameter names and local variable names.
>> 
>> Testing is pending...
>> 
>> Note: there is more history in old closed PRs [https://github.com/openjdk/jdk/pull/20497](https://github.com/openjdk/jdk/pull/20497) and [https://github.com/openjdk/jdk/pull/20472](https://github.com/openjdk/jdk/pull/20472)
>
> src/hotspot/share/runtime/os.hpp line 918:
> 
>> 916:   static ssize_t recv(int fd, char* buf, size_t nBytes, uint type);
>> 917:   static ssize_t send(int fd, char* buf, size_t nBytes, uint type);
>> 918:   static ssize_t raw_send(int fd, char* buf, size_t nBytes, uint type);
> 
> This set of changes is wrong.  These aren't MEMFLAGS flags.
> (I hope there aren't any more like this.  This sort of thing would be easy to miss in a change this
> large.  If I were making this change I'd have broken it up into several smaller pieces.)

Looks like a find/replace issue. Reverted the change.

> src/hotspot/share/utilities/concurrentHashTable.hpp line 43:
> 
>> 41: class Mutex;
>> 42: 
>> 43: template <typename CONFIG, MemTag F>
> 
> Parameter name should be updated throughout ConcurrentHashTable. Suggest mem_tag.

We can change this later in a followup.

> src/hotspot/share/utilities/growableArray.hpp line 803:
> 
>> 801: 
>> 802: // Leaner GrowableArray for CHeap backed data arrays, with compile-time decided MemTag.
>> 803: template <typename E, MemTag F>
> 
> Another parameter needing update, but shouldn't (can't?) be called `mem_tag` because of the
> function parameter name for allocate().

We can change this later in a followup.

> src/hotspot/share/utilities/linkedlist.hpp line 368:
> 
>> 366: template <class E, int (*FUNC)(const E&, const E&),
>> 367:   AnyObj::allocation_type T = AnyObj::C_HEAP,
>> 368:   MemTag F = mtNMT, AllocFailType alloc_failmode = AllocFailStrategy::RETURN_NULL>
> 
> Another parameter name needing update.

We can change this later in a followup.

> src/hotspot/share/utilities/objectBitSet.hpp line 42:
> 
>> 40:  * during the lifetime of the ObjectBitSet. The underlying memory is allocated from C-Heap.
>> 41:  */
>> 42: template<MemTag F>
> 
> More parameter names needing update.

I followed the local pattern, but we can change this later in a followup.

> src/hotspot/share/utilities/resizeableResourceHash.hpp line 33:
> 
>> 31:     typename K, typename V,
>> 32:     AnyObj::allocation_type ALLOC_TYPE,
>> 33:     MemTag MEM_TYPE>
> 
> I think s/MEM_TYPE/mem_type/, but other non-type template parameters here are also
> all-uppercase, so I guess better to leave it for now and look at it later.

Yes, I followed the local pattern.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20872#discussion_r1750606609
PR Review Comment: https://git.openjdk.org/jdk/pull/20872#discussion_r1750603957
PR Review Comment: https://git.openjdk.org/jdk/pull/20872#discussion_r1750603545
PR Review Comment: https://git.openjdk.org/jdk/pull/20872#discussion_r1750603358
PR Review Comment: https://git.openjdk.org/jdk/pull/20872#discussion_r1750602937
PR Review Comment: https://git.openjdk.org/jdk/pull/20872#discussion_r1750601971

From gziemski at openjdk.org  Mon Sep  9 17:00:17 2024
From: gziemski at openjdk.org (Gerard Ziemski)
Date: Mon, 9 Sep 2024 17:00:17 GMT
Subject: RFR: 8337563: NMT: rename MEMFLAGS to MemTag
In-Reply-To: <VZJqPLLe8B9m3uxUOwgjJk4VUHSAfN_6bauoUAznAx8=.37289d82-39fe-4499-9ce8-038e6383dfe1@github.com>
References: <aQDgRwE-H5U0lz8wooLBAQZsuDnB5zZzjMhheIu3y9Y=.0bae7ae4-062e-47de-b7c3-4fedc5d7e20a@github.com>
 <1OaddXS4qsgvGkMJXBt8kZRa7J6vQVZH1tdQ22hpGeo=.06168001-0cde-423b-bebb-24bb45d1c155@github.com>
 <VZJqPLLe8B9m3uxUOwgjJk4VUHSAfN_6bauoUAznAx8=.37289d82-39fe-4499-9ce8-038e6383dfe1@github.com>
Message-ID: <Dz6_TJrG5OXsrLlEtl9C6ow9lIQdlIJkDEuwhVw_yXM=.69e2f78e-db74-4ffe-9c6a-aa037dd18a82@github.com>

On Mon, 9 Sep 2024 13:36:26 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> src/hotspot/share/utilities/chunkedList.hpp line 31:
>> 
>>> 29: #include "utilities/debug.hpp"
>>> 30: 
>>> 31: template <class T, MemTag F> class ChunkedList : public CHeapObj<F> {
>> 
>> Parameter name should be updated.  Suggest `mem_tag`.
>
> How about MT here or just M?  I would make this a further change though.

We can change this later in a followup.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20872#discussion_r1750604170

From gziemski at openjdk.org  Mon Sep  9 17:07:05 2024
From: gziemski at openjdk.org (Gerard Ziemski)
Date: Mon, 9 Sep 2024 17:07:05 GMT
Subject: RFR: 8337563: NMT: rename MEMFLAGS to MemTag
In-Reply-To: <z-ebUn0e3FWOsn5bMXNP_Ethi6TubjIEaEEToPYB6Oc=.3c624821-7889-4eab-988e-65e3a44e38e8@github.com>
References: <aQDgRwE-H5U0lz8wooLBAQZsuDnB5zZzjMhheIu3y9Y=.0bae7ae4-062e-47de-b7c3-4fedc5d7e20a@github.com>
 <1OaddXS4qsgvGkMJXBt8kZRa7J6vQVZH1tdQ22hpGeo=.06168001-0cde-423b-bebb-24bb45d1c155@github.com>
 <z-ebUn0e3FWOsn5bMXNP_Ethi6TubjIEaEEToPYB6Oc=.3c624821-7889-4eab-988e-65e3a44e38e8@github.com>
Message-ID: <ZNcBK-Q4hhngPzd4wJQSSpBt5dLIPjmUk8gX31ZovsM=.7bf9cdcd-e81e-4f2e-808e-312767a4dbac@github.com>

On Mon, 9 Sep 2024 00:04:58 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> src/hotspot/share/gc/shared/taskqueue.hpp line 119:
>> 
>>> 117: // TaskQueueSuper collects functionality common to all GenericTaskQueue instances.
>>> 118: 
>>> 119: template <unsigned int N, MemTag F>
>> 
>> MemTag parameter name should probably be changed here and elsewhere in taskqueue code.
>> Suggest `mem_tag`.
>
> I was going to suggest just MT which is more in keeping with the short/terse names given to type parameters.

Will be address in a followup issue.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20872#discussion_r1750615114

From gziemski at openjdk.org  Mon Sep  9 17:07:06 2024
From: gziemski at openjdk.org (Gerard Ziemski)
Date: Mon, 9 Sep 2024 17:07:06 GMT
Subject: RFR: 8337563: NMT: rename MEMFLAGS to MemTag
In-Reply-To: <1OaddXS4qsgvGkMJXBt8kZRa7J6vQVZH1tdQ22hpGeo=.06168001-0cde-423b-bebb-24bb45d1c155@github.com>
References: <aQDgRwE-H5U0lz8wooLBAQZsuDnB5zZzjMhheIu3y9Y=.0bae7ae4-062e-47de-b7c3-4fedc5d7e20a@github.com>
 <1OaddXS4qsgvGkMJXBt8kZRa7J6vQVZH1tdQ22hpGeo=.06168001-0cde-423b-bebb-24bb45d1c155@github.com>
Message-ID: <dVU8tAz2vXRolAnqB9dmT5scZ52yPdIcoP9IrPobjHw=.bc6e7dd9-3175-4642-a601-ec1e9a7d6911@github.com>

On Sat, 7 Sep 2024 05:21:50 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Please review this cleanup, where we rename `MEMFLAGS` to `MemTag`.
>> 
>> `MEMFLAGS` implies that we can use more than one at the same time, but those are exclusive values, so `MemTag` is a more suitable name.
>> 
>> This fix also includes a cleanup of all the related parameter names and local variable names.
>> 
>> Testing is pending...
>> 
>> Note: there is more history in old closed PRs [https://github.com/openjdk/jdk/pull/20497](https://github.com/openjdk/jdk/pull/20497) and [https://github.com/openjdk/jdk/pull/20472](https://github.com/openjdk/jdk/pull/20472)
>
> src/hotspot/share/runtime/lightweightSynchronizer.cpp line 63:
> 
>> 61:     static void* allocate_node(void* context, size_t size, Value const& value) {
>> 62:       ObjectMonitorTable::inc_items_count();
>> 63:       return AllocateHeap(size, MemTag::mtObjectMonitor);
> 
> pre-existing: Why the scope here and below?

Good question, I will clean this up.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20872#discussion_r1750614387

From gziemski at openjdk.org  Mon Sep  9 17:16:06 2024
From: gziemski at openjdk.org (Gerard Ziemski)
Date: Mon, 9 Sep 2024 17:16:06 GMT
Subject: RFR: 8337563: NMT: rename MEMFLAGS to MemTag
In-Reply-To: <aQDgRwE-H5U0lz8wooLBAQZsuDnB5zZzjMhheIu3y9Y=.0bae7ae4-062e-47de-b7c3-4fedc5d7e20a@github.com>
References: <aQDgRwE-H5U0lz8wooLBAQZsuDnB5zZzjMhheIu3y9Y=.0bae7ae4-062e-47de-b7c3-4fedc5d7e20a@github.com>
Message-ID: <BIDhtI2YAqm9sOWcZX7vweaMXGmK-6v_tPECWHut1xc=.40c48e02-a096-4f9d-929f-69e0fd58f9e5@github.com>

On Thu, 5 Sep 2024 16:10:05 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

> Please review this cleanup, where we rename `MEMFLAGS` to `MemTag`.
> 
> `MEMFLAGS` implies that we can use more than one at the same time, but those are exclusive values, so `MemTag` is a more suitable name.
> 
> This fix also includes a cleanup of all the related parameter names and local variable names.
> 
> Testing is pending...
> 
> Note: there is more history in old closed PRs [https://github.com/openjdk/jdk/pull/20497](https://github.com/openjdk/jdk/pull/20497) and [https://github.com/openjdk/jdk/pull/20472](https://github.com/openjdk/jdk/pull/20472)

Thank you David, Kim for your feedback, as the very first reviewers your job was the hardest.

I implemented all your feedback. The template parameter rename I was planning on doing in a followup issue, however, if you really want, I can make the fix here too. It will increase the size of the changes, but I already accommodated Stefan request to include parameters and local variables, so we can go this one last step further if you like.

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

PR Comment: https://git.openjdk.org/jdk/pull/20872#issuecomment-2338647692

From gziemski at openjdk.org  Mon Sep  9 17:19:50 2024
From: gziemski at openjdk.org (Gerard Ziemski)
Date: Mon, 9 Sep 2024 17:19:50 GMT
Subject: RFR: 8337563: NMT: rename MEMFLAGS to MemTag [v2]
In-Reply-To: <aQDgRwE-H5U0lz8wooLBAQZsuDnB5zZzjMhheIu3y9Y=.0bae7ae4-062e-47de-b7c3-4fedc5d7e20a@github.com>
References: <aQDgRwE-H5U0lz8wooLBAQZsuDnB5zZzjMhheIu3y9Y=.0bae7ae4-062e-47de-b7c3-4fedc5d7e20a@github.com>
Message-ID: <IC25wO9pM_LdcIXqxPe78GKGUFSTJ3CiCksQ4nd7GrU=.0f470483-f9cb-4e48-8cdc-deaaec49c3a3@github.com>

> Please review this cleanup, where we rename `MEMFLAGS` to `MemTag`.
> 
> `MEMFLAGS` implies that we can use more than one at the same time, but those are exclusive values, so `MemTag` is a more suitable name.
> 
> This fix also includes a cleanup of all the related parameter names and local variable names.
> 
> Testing is pending...
> 
> Note: there is more history in old closed PRs [https://github.com/openjdk/jdk/pull/20497](https://github.com/openjdk/jdk/pull/20497) and [https://github.com/openjdk/jdk/pull/20472](https://github.com/openjdk/jdk/pull/20472)

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

  fix incorrect renames, missing type -> mem_tag

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20872/files
  - new: https://git.openjdk.org/jdk/pull/20872/files/983bb6e2..9ae36d57

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

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

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

From gziemski at openjdk.org  Mon Sep  9 17:31:47 2024
From: gziemski at openjdk.org (Gerard Ziemski)
Date: Mon, 9 Sep 2024 17:31:47 GMT
Subject: RFR: 8337563: NMT: rename MEMFLAGS to MemTag [v3]
In-Reply-To: <aQDgRwE-H5U0lz8wooLBAQZsuDnB5zZzjMhheIu3y9Y=.0bae7ae4-062e-47de-b7c3-4fedc5d7e20a@github.com>
References: <aQDgRwE-H5U0lz8wooLBAQZsuDnB5zZzjMhheIu3y9Y=.0bae7ae4-062e-47de-b7c3-4fedc5d7e20a@github.com>
Message-ID: <cDkAs4tocAk6y-odbQyH6N7co9JSzDdYTM-qRzsf7WA=.81b41536-4d6b-4fc6-b5e0-efb22e8f40f3@github.com>

> Please review this cleanup, where we rename `MEMFLAGS` to `MemTag`.
> 
> `MEMFLAGS` implies that we can use more than one at the same time, but those are exclusive values, so `MemTag` is a more suitable name.
> 
> This fix also includes a cleanup of all the related parameter names and local variable names.
> 
> Testing is pending...
> 
> Note: there is more history in old closed PRs [https://github.com/openjdk/jdk/pull/20497](https://github.com/openjdk/jdk/pull/20497) and [https://github.com/openjdk/jdk/pull/20472](https://github.com/openjdk/jdk/pull/20472)

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

  fix linux build issue

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20872/files
  - new: https://git.openjdk.org/jdk/pull/20872/files/9ae36d57..998537bd

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

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

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

From rkennke at openjdk.org  Mon Sep  9 17:45:47 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Mon, 9 Sep 2024 17:45:47 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v9]
In-Reply-To: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
Message-ID: <6Rant6SjxpFIHHWNthWc_plOdnGpWPvqj3rxRe144po=.bcdbad7a-e93a-41a3-b958-6ae602c7e083@github.com>

> This is the main body of the JEP 450: Compact Object Headers (Experimental).
> 
> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing.
> 
> Main changes:
>  - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers.
>  - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded.
>  - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops).
>  - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all).
>  - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16).
>  - Arrays will now store their length at offset 8.
>  - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _coh variants of CDS archiv...

Roman Kennke has updated the pull request incrementally with six additional commits since the last revision:

 - Print as warning when UCOH doesn't match in CDS archive
 - Improve initialization of mark-word in CDS ArchiveHeapWriter
 - Simplify getKlass() in SA
 - Simplify oopDesc::init_mark()
 - Get rid of forward_safe_* methods
 - GCForwarding touch-ups

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20677/files
  - new: https://git.openjdk.org/jdk/pull/20677/files/70f492d3..2884499a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20677&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20677&range=07-08

  Stats: 132 lines in 17 files changed: 26 ins; 73 del; 33 mod
  Patch: https://git.openjdk.org/jdk/pull/20677.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20677/head:pull/20677

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

From cjplummer at openjdk.org  Mon Sep  9 18:37:09 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Mon, 9 Sep 2024 18:37:09 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v6]
In-Reply-To: <ZnddOJnCLP0HABu3ymeWaAvcJNd3mKz8AhFwOtUAYW8=.f534bbd8-c222-4cd7-b6a9-3d6fd644c5e1@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <BGmZ04yibLn_KtPyQrA3sQv5OtMonrcDy3aN0vAj8NA=.5de6cae3-3a05-4a74-a15c-aade4176bdeb@github.com>
 <Og4I5G3w51d7zF27JawLM9pm_XpHwijYt3lJZ4hpeWQ=.fd974e82-2ce0-4ebd-b49e-108ab87690a9@github.com>
 <S-95OBPOZb6GfBEUIDtHxCB4hTFPB2uNf5YmwMerGcE=.83afc323-883e-4ae0-8d10-fe7030cddb33@github.com>
 <ZnddOJnCLP0HABu3ymeWaAvcJNd3mKz8AhFwOtUAYW8=.f534bbd8-c222-4cd7-b6a9-3d6fd644c5e1@github.com>
Message-ID: <SKA53xBzGbvMWiQxBtEYG9QB2KqZOKEBMzJzbQb_Zr8=.0cd24aa4-3aed-46e6-9092-bbc4b926bb42@github.com>

On Mon, 9 Sep 2024 16:51:35 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> There is no dedicated klass field anymore, the Klass* is encoded in the mark, and we would need to extract it. What is the purpose of the visitors? Do they need to see the klass/compressedKlass, or is it sufficient to visit the mark-word (which we already do, but as CInt).
>
> I've been looking into this. It's a bit hard to follow but I think you do need to do something more here. Can you run ClhsdbInspect.java and send me the output. In specific I need to know if the log includes the following:
> 
> 
> hsdb> + inspect 0x00000007cff154b8
> instance of Oop for java/util/concurrent/locks/AbstractQueuedSynchronizer$ConditionObject @ 0x00000007cff154b8 (size = 24)
> _mark: 1
> _metadata._compressed_klass: InstanceKlass for java/util/concurrent/locks/AbstractQueuedSynchronizer$ConditionObject
> firstWaiter: Oop for java/util/concurrent/locks/AbstractQueuedSynchronizer$ConditionNode @ 0x00000007cfff5f80
> lastWaiter: Oop for java/util/concurrent/locks/AbstractQueuedSynchronizer$ConditionNode @ 0x00000007cfff5f80
> this$0: Oop for java/util/concurrent/locks/ReentrantLock$NonfairSync @ 0x00000007cff15498

I pulled your changes and I see one slight difference in the output. The following line is missing:

`_metadata._compressed_klass: InstanceKlass for java/util/concurrent/locks/AbstractQueuedSynchronizer$ConditionObject`

I realize that there is no `_metadata._compressed_klass` when you have compact headers, and that the Klass* is encoded in the `_mark` word, which is now looks something like this in the output:

_mark: 16294762323640321

So you can say that the Klass* is embedded in the _mark work, but this isn't of much help to SA users. I think what is expected is that the visitor is passed a MetadataField object that when getValue() is called on it, the Klass mirror is returned. Maybe we need a new CompactKlassField type like we current have a NarrowKlassField field type, and it will do the decoding of the _mark work into a Klass. The current getKlass() is related to this.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1750743693

From gziemski at openjdk.org  Mon Sep  9 18:41:26 2024
From: gziemski at openjdk.org (Gerard Ziemski)
Date: Mon, 9 Sep 2024 18:41:26 GMT
Subject: RFR: 8337563: NMT: rename MEMFLAGS to MemTag [v4]
In-Reply-To: <aQDgRwE-H5U0lz8wooLBAQZsuDnB5zZzjMhheIu3y9Y=.0bae7ae4-062e-47de-b7c3-4fedc5d7e20a@github.com>
References: <aQDgRwE-H5U0lz8wooLBAQZsuDnB5zZzjMhheIu3y9Y=.0bae7ae4-062e-47de-b7c3-4fedc5d7e20a@github.com>
Message-ID: <lfzuokmcCu5MvO6QpnJgoiXB0IdRERHftYq5VVGRpjM=.a3e779e5-e89e-411a-92af-a0efa3c5ba57@github.com>

> Please review this cleanup, where we rename `MEMFLAGS` to `MemTag`.
> 
> `MEMFLAGS` implies that we can use more than one at the same time, but those are exclusive values, so `MemTag` is a more suitable name.
> 
> This fix also includes a cleanup of all the related parameter names and local variable names.
> 
> Testing is pending...
> 
> Note: there is more history in old closed PRs [https://github.com/openjdk/jdk/pull/20497](https://github.com/openjdk/jdk/pull/20497) and [https://github.com/openjdk/jdk/pull/20472](https://github.com/openjdk/jdk/pull/20472)

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

  revert type->state change

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20872/files
  - new: https://git.openjdk.org/jdk/pull/20872/files/998537bd..bf062da9

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

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

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

From gziemski at openjdk.org  Mon Sep  9 19:02:25 2024
From: gziemski at openjdk.org (Gerard Ziemski)
Date: Mon, 9 Sep 2024 19:02:25 GMT
Subject: RFR: 8337563: NMT: rename MEMFLAGS to MemTag [v5]
In-Reply-To: <aQDgRwE-H5U0lz8wooLBAQZsuDnB5zZzjMhheIu3y9Y=.0bae7ae4-062e-47de-b7c3-4fedc5d7e20a@github.com>
References: <aQDgRwE-H5U0lz8wooLBAQZsuDnB5zZzjMhheIu3y9Y=.0bae7ae4-062e-47de-b7c3-4fedc5d7e20a@github.com>
Message-ID: <buLImdLbKR7m3KWE_ELGi9zoSfz4Wy7g-xsjhrVHj3A=.5e18e806-a617-4f2b-8cb4-ddc77ead662a@github.com>

> Please review this cleanup, where we rename `MEMFLAGS` to `MemTag`.
> 
> `MEMFLAGS` implies that we can use more than one at the same time, but those are exclusive values, so `MemTag` is a more suitable name.
> 
> This fix also includes a cleanup of all the related parameter names and local variable names.
> 
> Testing is pending...
> 
> Note: there is more history in old closed PRs [https://github.com/openjdk/jdk/pull/20497](https://github.com/openjdk/jdk/pull/20497) and [https://github.com/openjdk/jdk/pull/20472](https://github.com/openjdk/jdk/pull/20472)

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

  fix test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20872/files
  - new: https://git.openjdk.org/jdk/pull/20872/files/bf062da9..7a4f6e01

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

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

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

From cjplummer at openjdk.org  Mon Sep  9 19:07:10 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Mon, 9 Sep 2024 19:07:10 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v6]
In-Reply-To: <SKA53xBzGbvMWiQxBtEYG9QB2KqZOKEBMzJzbQb_Zr8=.0cd24aa4-3aed-46e6-9092-bbc4b926bb42@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <BGmZ04yibLn_KtPyQrA3sQv5OtMonrcDy3aN0vAj8NA=.5de6cae3-3a05-4a74-a15c-aade4176bdeb@github.com>
 <Og4I5G3w51d7zF27JawLM9pm_XpHwijYt3lJZ4hpeWQ=.fd974e82-2ce0-4ebd-b49e-108ab87690a9@github.com>
 <S-95OBPOZb6GfBEUIDtHxCB4hTFPB2uNf5YmwMerGcE=.83afc323-883e-4ae0-8d10-fe7030cddb33@github.com>
 <ZnddOJnCLP0HABu3ymeWaAvcJNd3mKz8AhFwOtUAYW8=.f534bbd8-c222-4cd7-b6a9-3d6fd644c5e1@github.com>
 <SKA53xBzGbvMWiQxBtEYG9QB2KqZOKEBMzJzbQb_Zr8=.0cd24aa4-3aed-46e6-9092-bbc4b926bb42@github.com>
Message-ID: <xyQ56u8rEyLnbVv9iP23zziwfEkc0v9bm1MGVQ8BUHY=.352e102f-41d3-4ef6-86d2-2ebc998671d1@github.com>

On Mon, 9 Sep 2024 18:34:10 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> I've been looking into this. It's a bit hard to follow but I think you do need to do something more here. Can you run ClhsdbInspect.java and send me the output. In specific I need to know if the log includes the following:
>> 
>> 
>> hsdb> + inspect 0x00000007cff154b8
>> instance of Oop for java/util/concurrent/locks/AbstractQueuedSynchronizer$ConditionObject @ 0x00000007cff154b8 (size = 24)
>> _mark: 1
>> _metadata._compressed_klass: InstanceKlass for java/util/concurrent/locks/AbstractQueuedSynchronizer$ConditionObject
>> firstWaiter: Oop for java/util/concurrent/locks/AbstractQueuedSynchronizer$ConditionNode @ 0x00000007cfff5f80
>> lastWaiter: Oop for java/util/concurrent/locks/AbstractQueuedSynchronizer$ConditionNode @ 0x00000007cfff5f80
>> this$0: Oop for java/util/concurrent/locks/ReentrantLock$NonfairSync @ 0x00000007cff15498
>
> I pulled your changes and I see one slight difference in the output. The following line is missing:
> 
> `_metadata._compressed_klass: InstanceKlass for java/util/concurrent/locks/AbstractQueuedSynchronizer$ConditionObject`
> 
> I realize that there is no `_metadata._compressed_klass` when you have compact headers, and that the Klass* is encoded in the `_mark` word, which is now looks something like this in the output:
> 
> _mark: 16294762323640321
> 
> So you can say that the Klass* is embedded in the _mark work, but this isn't of much help to SA users. I think what is expected is that the visitor is passed a MetadataField object that when getValue() is called on it, the Klass mirror is returned. Maybe we need a new CompactKlassField type like we current have a NarrowKlassField field type, and it will do the decoding of the _mark work into a Klass. The current getKlass() is related to this.

Thinking about this a bit more, maybe _mark needs to be a MetadataFile rather than CInt. This is a kind of odd situation. Basically we have a CInt field that is more than just simple bits used as flags or small integers. It also gets you to the Klass*. Possibly SA should treat _mark is two seprate fields; one that remains a CInt as it currently is and another that treats it as an encoded Klass* like the NarrowKlassField case.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1750788243

From coleenp at openjdk.org  Mon Sep  9 19:55:16 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 9 Sep 2024 19:55:16 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v9]
In-Reply-To: <6Rant6SjxpFIHHWNthWc_plOdnGpWPvqj3rxRe144po=.bcdbad7a-e93a-41a3-b958-6ae602c7e083@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <6Rant6SjxpFIHHWNthWc_plOdnGpWPvqj3rxRe144po=.bcdbad7a-e93a-41a3-b958-6ae602c7e083@github.com>
Message-ID: <NR6CKOtdUaVarB7hiAUIAsIMe03qiTQr5VcEOWGt8mA=.164efc10-f0ff-4ddf-80b8-c56599c0ba7d@github.com>

On Mon, 9 Sep 2024 17:45:47 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> This is the main body of the JEP 450: Compact Object Headers (Experimental).
>> 
>> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing.
>> 
>> Main changes:
>>  - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers.
>>  - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded.
>>  - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops).
>>  - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all).
>>  - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16).
>>  - Arrays will now store their length at offset 8.
>>  - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _co...
>
> Roman Kennke has updated the pull request incrementally with six additional commits since the last revision:
> 
>  - Print as warning when UCOH doesn't match in CDS archive
>  - Improve initialization of mark-word in CDS ArchiveHeapWriter
>  - Simplify getKlass() in SA
>  - Simplify oopDesc::init_mark()
>  - Get rid of forward_safe_* methods
>  - GCForwarding touch-ups

I reviewed the oops code so far.

src/hotspot/share/oops/compressedKlass.cpp line 116:

> 114:   _range = end - _base;
> 115: 
> 116:   DEBUG_ONLY(assert_is_valid_encoding(addr, len, _base, _shift);)

Can you refactor so the aarch64 path runs this same code without duplication?

src/hotspot/share/oops/klass.hpp line 173:

> 171: 
> 172:   markWord _prototype_header;   // Used to initialize objects' header
> 173: 

I think you should move this up after ClassLoaderData, as there might be an alignment gap (you can run pahole to check).

src/hotspot/share/oops/klass.hpp line 718:

> 716: 
> 717:   markWord prototype_header() const {
> 718:     assert(UseCompactObjectHeaders, "only use with compact object headers");

Should this unconditionally return _prototype_header since it's initialized to markWord::prototype_header(), or would that decrease performance for the non-compact headers case?

src/hotspot/share/oops/klass.inline.hpp line 54:

> 52: }
> 53: 
> 54: inline void Klass::set_prototype_header(markWord header) {

Can you put a comment that this is only used when dumping the archive?  Because otherwise the Klass::_prototype_header field should always be initialized to the right thing (either with Klass encoded or as markWord::protoytpe_header()) and doesn't change.

src/hotspot/share/oops/markWord.inline.hpp line 90:

> 88:   ShouldNotReachHere();
> 89:   return markWord();
> 90: #endif

Is the ifdef _LP64 necessary, since UseCompactObjectHeaders should always be false for 32 bits?

src/hotspot/share/oops/oop.inline.hpp line 90:

> 88:   } else {
> 89:     return markWord::prototype();
> 90:   }

Could this be unconditional since prototoype_header is initialized for all Klasses?

src/hotspot/share/oops/typeArrayKlass.cpp line 175:

> 173: size_t TypeArrayKlass::oop_size(oop obj) const {
> 174:   // In this assert, we cannot safely access the Klass* with compact headers.
> 175:   assert(UseCompactObjectHeaders || obj->is_typeArray(),"must be a type array");

Why not?  I think I'm missing something.  Klass should be in the markWord and that should be ok (?)

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

PR Review: https://git.openjdk.org/jdk/pull/20677#pullrequestreview-2290316150
PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1750529270
PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1750727211
PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1750730078
PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1750736547
PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1750739441
PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1750842383
PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1750721069

From coleenp at openjdk.org  Mon Sep  9 19:55:19 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 9 Sep 2024 19:55:19 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v8]
In-Reply-To: <J0g0PSye768dhN3JoXFsZ6FivocNBLPmHNtRUCOmLTw=.5756c64a-4763-4727-9637-ba3fe7b9b17d@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <J0g0PSye768dhN3JoXFsZ6FivocNBLPmHNtRUCOmLTw=.5756c64a-4763-4727-9637-ba3fe7b9b17d@github.com>
Message-ID: <vt3oD_XW4eFNTnPYoSa0-TZiEsFtBXJKfPdsIoqVuXM=.7e14c4df-4c66-4f52-9a59-e86fbcb6e7d9@github.com>

On Mon, 9 Sep 2024 11:55:52 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> This is the main body of the JEP 450: Compact Object Headers (Experimental).
>> 
>> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing.
>> 
>> Main changes:
>>  - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers.
>>  - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded.
>>  - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops).
>>  - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all).
>>  - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16).
>>  - Arrays will now store their length at offset 8.
>>  - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _co...
>
> Roman Kennke has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Try to avoid lea in loadNklass (aarch64)
>  - Fix release build error

src/hotspot/cpu/aarch64/compressedKlass_aarch64.cpp line 147:

> 145: #endif
> 146: 
> 147:   return true;

This should only be in the compressedKlass.cpp file.

src/hotspot/share/oops/compressedKlass.cpp line 214:

> 212:     ss.print("Class space size (%zu) exceeds the maximum possible size (%zu)",
> 213:               len, max_encoding_range_size());
> 214:     vm_exit_during_initialization(ss.base());

Why does this exit and not turn off compressed klass pointers and compact object headers?

src/hotspot/share/oops/compressedKlass.cpp line 222:

> 220:     return;
> 221:   }
> 222: #endif

Why not add null pd_initialize to zero to remove this conditional code?

src/hotspot/share/oops/compressedKlass.cpp line 224:

> 222: #endif
> 223: 
> 224:   if (tiny_classpointer_mode()) {

I kind of agree with Thomas Schatzl for this.  Maybe it should be compact_classpointer_mode(). It's nice to have a new string for grep, but they're not really that tiny.

src/hotspot/share/oops/compressedKlass.cpp line 234:

> 232:     _range = len;
> 233: 
> 234:     constexpr int log_cacheline = 6;

Is 6 the log of DEFAULT_CACHE_LINE_SIZE?

src/hotspot/share/oops/compressedKlass.cpp line 243:

> 241:   } else {
> 242: 
> 243:     // In legacy mode, we try, in order of preference:

Can you not use the word 'legacy' here?  Maybe in "non-compact object header mode"...

src/hotspot/share/oops/compressedKlass.inline.hpp line 100:

> 98:   check_valid_klass(k, base(), shift());
> 99:   // Also assert that k falls into what we know is the valid Klass range. This is usually smaller
> 100:   // than the encoding range (e.g. encoding range covers 4G, but we only have 1G class space and a

1G is the default CompressedClassSpaceSize but can be larger, right?  So the comment isn't quite accurate.  Or with tiny class pointers can it only be 1G?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1750527537
PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1750511912
PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1750513660
PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1750515923
PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1750520712
PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1750524690
PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1750662637

From coleenp at openjdk.org  Mon Sep  9 19:55:20 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 9 Sep 2024 19:55:20 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v6]
In-Reply-To: <86SISXYdKqHq5_nSqeVVNgmxplVK6QuHvOjCmiCKkzQ=.92ac6af1-9a94-4068-b625-1e331314826e@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <BGmZ04yibLn_KtPyQrA3sQv5OtMonrcDy3aN0vAj8NA=.5de6cae3-3a05-4a74-a15c-aade4176bdeb@github.com>
 <86SISXYdKqHq5_nSqeVVNgmxplVK6QuHvOjCmiCKkzQ=.92ac6af1-9a94-4068-b625-1e331314826e@github.com>
Message-ID: <4cTKmlYUEtFpr2TURf25gd7-_eSb-uF0cC0BmLl6wd0=.b9f0482d-5439-421b-9a29-7a014fb72558@github.com>

On Mon, 9 Sep 2024 10:02:53 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix bit counts in GCForwarding
>
> src/hotspot/share/oops/compressedKlass.hpp line 43:
> 
>> 41: 
>> 42:   // Tiny-class-pointer mode
>> 43:   static int _tiny_cp; // -1, 0=true, 1=false
> 
> Suggestion:
> 
>   static int _tiny_cp; // -1 = uninitialized, 0 = true, 1 = false
> 
> In addition to that, I am not sure if introducing a new term ("tiny") for compact class header related changes (and just here) makes the code more clear; I would have expected a "_compact_" prefix. Also all other members use "k"-klass and spell out "klass pointer", so I would prefer to keep that style.

I agree with this.  'cp' reads as ConstantPool for me even though this is a different context.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1750531167

From stefank at openjdk.org  Mon Sep  9 20:07:13 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Mon, 9 Sep 2024 20:07:13 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v9]
In-Reply-To: <NR6CKOtdUaVarB7hiAUIAsIMe03qiTQr5VcEOWGt8mA=.164efc10-f0ff-4ddf-80b8-c56599c0ba7d@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <6Rant6SjxpFIHHWNthWc_plOdnGpWPvqj3rxRe144po=.bcdbad7a-e93a-41a3-b958-6ae602c7e083@github.com>
 <NR6CKOtdUaVarB7hiAUIAsIMe03qiTQr5VcEOWGt8mA=.164efc10-f0ff-4ddf-80b8-c56599c0ba7d@github.com>
Message-ID: <1vlOROPKL6eDagcb0xz0MGe6vA6vYBVa4UzVsCZ5Q8I=.d5408660-ee94-4118-b809-d13a3dc500b4@github.com>

On Mon, 9 Sep 2024 18:15:38 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Roman Kennke has updated the pull request incrementally with six additional commits since the last revision:
>> 
>>  - Print as warning when UCOH doesn't match in CDS archive
>>  - Improve initialization of mark-word in CDS ArchiveHeapWriter
>>  - Simplify getKlass() in SA
>>  - Simplify oopDesc::init_mark()
>>  - Get rid of forward_safe_* methods
>>  - GCForwarding touch-ups
>
> src/hotspot/share/oops/typeArrayKlass.cpp line 175:
> 
>> 173: size_t TypeArrayKlass::oop_size(oop obj) const {
>> 174:   // In this assert, we cannot safely access the Klass* with compact headers.
>> 175:   assert(UseCompactObjectHeaders || obj->is_typeArray(),"must be a type array");
> 
> Why not?  I think I'm missing something.  Klass should be in the markWord and that should be ok (?)

I tracked this down to only (at least in my testing) happen from `size_given_klass` when called from the GC when it is about to copy an object. While that happens another thread can racingly succeed to copy the object and install a forwarding pointer over the old copy. When that happens the klass pointer is broken and the call to oopDesc::is_typeArray() crashes.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1750862842

From kdnilsen at openjdk.org  Mon Sep  9 20:11:25 2024
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Mon, 9 Sep 2024 20:11:25 GMT
Subject: RFR: 8339611: GenShen: Simplify
 ShenandoahOldHeuristics::trigger_collection_if_fragmented [v2]
In-Reply-To: <-r69A9Nvfd00Yb1xudacPV-eEDJGhaGj-CXw88ZfGH8=.76e8a84c-0c26-4965-bdd5-fcdff0e400ae@github.com>
References: <q3WvOqHO5pxBtaFlO2Ep4ZibIB1nyEPyQ-1to21TqS4=.31ba4e8d-2096-4bb4-aad5-902839638ac9@github.com>
 <W7N9GokysT1WyvUOKQ8B51b5x1IBLLUa-AyyOygX9Lo=.9900c18c-2f03-4349-b98a-bc25c4edae80@github.com>
 <XQ5AhvXa2kCDgnEDk86hDsmMgUgpYEPOJGV2y6y9wZI=.43375872-35c0-465f-91b8-79feb38c294d@github.com>
 <lgR4zrz_vkkgYitJPu9oVkqBYjUd0-bvjbXPExgz3ow=.8951ffbf-3775-4156-a500-aa820ab62f6a@github.com>
 <-r69A9Nvfd00Yb1xudacPV-eEDJGhaGj-CXw88ZfGH8=.76e8a84c-0c26-4965-bdd5-fcdff0e400ae@github.com>
Message-ID: <xfzIGrNp9d3WdAzD3JHquz1nnnhwBXVZiQR_gK0CY24=.2a15ac87-21ff-4ad6-ba83-08fd525642db@github.com>

On Fri, 6 Sep 2024 21:29:11 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> But if we are at 110% old_span_percent, we have violated our intended Humongous Reserves, so I'm thinking we should try to squeeze that last 10% out of old so we don't have to STW on the next humongous allocation request...
>
> I have a few broader questions:
> * why is `allowed_old_gen_span` defined in terms of humongous reserve?
> * why do we want to square `old_span_percent` and divide it into `old_density`? The comments suggest we ought to be comparing `old_density` directly?

The idea is that services that anticipate a need for "lots of humongous" allocation can specify a non-zero value for ShenandoahGenerationalHumongousReserve.  If this value is non-zero, GenShen endeavors to avoid placing old-gen regions into the first N% of the heap.  The low end of the heap is reserved for humongous regions, leaving the rest of the heap eligible for Old regions.

Each time we rebuild the freeset, the top-most available regions are reserved for old collector. Next to these, we reserve for the collector (young "survivor regions").  The remaining heap is available for mutator allocations, with humongous allocations prioritized to bottom.

There's an "implicit assumption" in this code that the top-most old-gen region is aligned at top of the heap.  I'll change this by defining old_region_span as (num_regions() - first_old_region).  This makes the correlation more clear.  (I'll also add some comments).

The reason for squaring old_span_percent is because we want non-linear triggering of defragmenting old.  We don't really care about old fragmentation if old's span is small.  Doing too much defragmentation of OLD is shown to degrade performance when the defragmentation was really not "necessary".  With linear (not-squared) old_span_percent, we would be triggering almost twice as frequently at lower span values and less aggressively when old_span_percent exceeds its allowed span:
  // Trigger if old_span_percent is: 110% and density is below 82.5%
  //                                                      100%                                    75% (same at this trigger)
  //                                                       90%                                     67.5%
  //                                                       80%                                     60%
  //                                                       70%                                     56.25%
  //                                                       60%                                     45%
  //                                                       50%                                     37.5%                                      

As old span approaches the "target maximum span" it becomes increasingly important to defragment old.  On the other hand, if we totally ignore fragmentation until we have exceeded the limit, we have high probability of experiencing a STW Full GC due to humongous allocation failure.  This is because:

1. Old defragmentation generally requires many GC cycles, first to do OLD marking, and then to do the mixed evacuations.
2. Defragmenting mixed evacuations typically run slower than "traditional" mixed evacuations.  This is because a typical mixed evacuation only evacuates regions that have "abundant garbage".  But a defragmenting mixed evacuation may have to evacuate regions that are highly utilized.

One other reason to not totally ignore defragmentation until it has become "urgent" is because early investment in defragmenting can prevent the more severe forms of fragmentation from manifesting. When large numbers of regions with low utilization have been promoted in place (which s is one of the key causes of old fragmentation), it is easier to consolidate the live memory from multiple sparsely populated old-gen regions while they are still sparsely populated.  Otherwise, if we delay the defragmentation effort, it is likely that many of the sparsely populated regions become high utilized before we defragment, and then we'll have to copy a lot more data around in order to move regions out of the humongous region zone.

There is room for more extensive performance measurements and improved heuristics, I'm sure.

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

PR Review Comment: https://git.openjdk.org/shenandoah/pull/492#discussion_r1750868532

From coleenp at openjdk.org  Mon Sep  9 20:23:11 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 9 Sep 2024 20:23:11 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v9]
In-Reply-To: <1vlOROPKL6eDagcb0xz0MGe6vA6vYBVa4UzVsCZ5Q8I=.d5408660-ee94-4118-b809-d13a3dc500b4@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <6Rant6SjxpFIHHWNthWc_plOdnGpWPvqj3rxRe144po=.bcdbad7a-e93a-41a3-b958-6ae602c7e083@github.com>
 <NR6CKOtdUaVarB7hiAUIAsIMe03qiTQr5VcEOWGt8mA=.164efc10-f0ff-4ddf-80b8-c56599c0ba7d@github.com>
 <1vlOROPKL6eDagcb0xz0MGe6vA6vYBVa4UzVsCZ5Q8I=.d5408660-ee94-4118-b809-d13a3dc500b4@github.com>
Message-ID: <s69LCOhxAaI5gsdJKdqHoyQfdqNlcdftQW9xiyiqG1w=.b754a259-4f44-4844-a926-9b05c7199652@github.com>

On Mon, 9 Sep 2024 20:04:22 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> src/hotspot/share/oops/typeArrayKlass.cpp line 175:
>> 
>>> 173: size_t TypeArrayKlass::oop_size(oop obj) const {
>>> 174:   // In this assert, we cannot safely access the Klass* with compact headers.
>>> 175:   assert(UseCompactObjectHeaders || obj->is_typeArray(),"must be a type array");
>> 
>> Why not?  I think I'm missing something.  Klass should be in the markWord and that should be ok (?)
>
> I tracked this down to only (at least in my testing) happen from `size_given_klass` when called from the GC when it is about to copy an object. While that happens another thread can racingly succeed to copy the object and install a forwarding pointer over the old copy. When that happens the klass pointer is broken and the call to oopDesc::is_typeArray() crashes.

I did miss something.  I thought the markWord was never overwritten by the forwarding pointer.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1750882259

From kdnilsen at openjdk.org  Mon Sep  9 20:43:39 2024
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Mon, 9 Sep 2024 20:43:39 GMT
Subject: RFR: 8339611: GenShen: Simplify
 ShenandoahOldHeuristics::trigger_collection_if_fragmented [v3]
In-Reply-To: <q3WvOqHO5pxBtaFlO2Ep4ZibIB1nyEPyQ-1to21TqS4=.31ba4e8d-2096-4bb4-aad5-902839638ac9@github.com>
References: <q3WvOqHO5pxBtaFlO2Ep4ZibIB1nyEPyQ-1to21TqS4=.31ba4e8d-2096-4bb4-aad5-902839638ac9@github.com>
Message-ID: <wQ6Yt5q3w1mBNrQ-8C4C64mP4bcjEEni-r9oej4QfD8=.c7ac6c11-2047-4ed6-bf3b-297a56e61313@github.com>

> Replace iterative solution with a single mathematical computation, and adjust old-gen defragmentation efforts to be a bit less aggressive.

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

  Improve comments and clarify intent of old_region_span

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

Changes:
  - all: https://git.openjdk.org/shenandoah/pull/492/files
  - new: https://git.openjdk.org/shenandoah/pull/492/files/76bab3ad..327c5009

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

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

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

From wkemper at openjdk.org  Mon Sep  9 22:38:27 2024
From: wkemper at openjdk.org (William Kemper)
Date: Mon, 9 Sep 2024 22:38:27 GMT
Subject: RFR: 8339611: GenShen: Simplify
 ShenandoahOldHeuristics::trigger_collection_if_fragmented [v3]
In-Reply-To: <wQ6Yt5q3w1mBNrQ-8C4C64mP4bcjEEni-r9oej4QfD8=.c7ac6c11-2047-4ed6-bf3b-297a56e61313@github.com>
References: <q3WvOqHO5pxBtaFlO2Ep4ZibIB1nyEPyQ-1to21TqS4=.31ba4e8d-2096-4bb4-aad5-902839638ac9@github.com>
 <wQ6Yt5q3w1mBNrQ-8C4C64mP4bcjEEni-r9oej4QfD8=.c7ac6c11-2047-4ed6-bf3b-297a56e61313@github.com>
Message-ID: <sIfFUyov5SVCHio_-ZjJY5gL4preXED26Vf85KFLqOQ=.bfbfdc25-b684-4921-a5d0-f0843f8eabf6@github.com>

On Mon, 9 Sep 2024 20:43:39 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> Replace iterative solution with a single mathematical computation, and adjust old-gen defragmentation efforts to be a bit less aggressive.
>
> Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improve comments and clarify intent of old_region_span

Marked as reviewed by wkemper (Committer).

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

PR Review: https://git.openjdk.org/shenandoah/pull/492#pullrequestreview-2291065092

From wkemper at openjdk.org  Mon Sep  9 22:38:27 2024
From: wkemper at openjdk.org (William Kemper)
Date: Mon, 9 Sep 2024 22:38:27 GMT
Subject: RFR: 8339611: GenShen: Simplify
 ShenandoahOldHeuristics::trigger_collection_if_fragmented [v2]
In-Reply-To: <xfzIGrNp9d3WdAzD3JHquz1nnnhwBXVZiQR_gK0CY24=.2a15ac87-21ff-4ad6-ba83-08fd525642db@github.com>
References: <q3WvOqHO5pxBtaFlO2Ep4ZibIB1nyEPyQ-1to21TqS4=.31ba4e8d-2096-4bb4-aad5-902839638ac9@github.com>
 <W7N9GokysT1WyvUOKQ8B51b5x1IBLLUa-AyyOygX9Lo=.9900c18c-2f03-4349-b98a-bc25c4edae80@github.com>
 <XQ5AhvXa2kCDgnEDk86hDsmMgUgpYEPOJGV2y6y9wZI=.43375872-35c0-465f-91b8-79feb38c294d@github.com>
 <lgR4zrz_vkkgYitJPu9oVkqBYjUd0-bvjbXPExgz3ow=.8951ffbf-3775-4156-a500-aa820ab62f6a@github.com>
 <-r69A9Nvfd00Yb1xudacPV-eEDJGhaGj-CXw88ZfGH8=.76e8a84c-0c26-4965-bdd5-fcdff0e400ae@github.com>
 <xfzIGrNp9d3WdAzD3JHquz1nnnhwBXVZiQR_gK0CY24=.2a15ac87-21ff-4ad6-ba83-08fd525642db@github.com>
Message-ID: <UVNcoLy9rS79106u2IPtJ5rZwuMQUgkdbeUJXEr1txU=.8aac7766-6021-4c27-b4d8-2f3ad7876849@github.com>

On Mon, 9 Sep 2024 20:08:51 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> I have a few broader questions:
>> * why is `allowed_old_gen_span` defined in terms of humongous reserve?
>> * why do we want to square `old_span_percent` and divide it into `old_density`? The comments suggest we ought to be comparing `old_density` directly?
>
> The idea is that services that anticipate a need for "lots of humongous" allocation can specify a non-zero value for ShenandoahGenerationalHumongousReserve.  If this value is non-zero, GenShen endeavors to avoid placing old-gen regions into the first N% of the heap.  The low end of the heap is reserved for humongous regions, leaving the rest of the heap eligible for Old regions.
> 
> Each time we rebuild the freeset, the top-most available regions are reserved for old collector. Next to these, we reserve for the collector (young "survivor regions").  The remaining heap is available for mutator allocations, with humongous allocations prioritized to bottom.
> 
> There's an "implicit assumption" in this code that the top-most old-gen region is aligned at top of the heap.  I'll change this by defining old_region_span as (num_regions() - first_old_region).  This makes the correlation more clear.  (I'll also add some comments).
> 
> The reason for squaring old_span_percent is because we want non-linear triggering of defragmenting old.  We don't really care about old fragmentation if old's span is small.  Doing too much defragmentation of OLD is shown to degrade performance when the defragmentation was really not "necessary".  With linear (not-squared) old_span_percent, we would be triggering almost twice as frequently at lower span values and less aggressively when old_span_percent exceeds its allowed span:
>   // Trigger if old_span_percent is: 110% and density is below 82.5%
>   //                                                      100%                                    75% (same at this trigger)
>   //                                                       90%                                     67.5%
>   //                                                       80%                                     60%
>   //                                                       70%                                     56.25%
>   //                                                       60%                                     45%
>   //                                                       50%                                     37.5%                                      
> 
> As old span approaches the "target maximum span" it becomes increasingly important to defragment old.  On the other hand, if we totally ignore fragmentation until we have exceeded the limit, we have high probability of experiencing a STW Full GC due to humongous allocation failure.  This is because:
> 
> 1. Old defragmentation general...

Thank you for the detailed explanation. It makes more sense now.

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

PR Review Comment: https://git.openjdk.org/shenandoah/pull/492#discussion_r1751016226

From dholmes at openjdk.org  Tue Sep 10 06:00:11 2024
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 10 Sep 2024 06:00:11 GMT
Subject: RFR: 8337563: NMT: rename MEMFLAGS to MemTag
In-Reply-To: <BIDhtI2YAqm9sOWcZX7vweaMXGmK-6v_tPECWHut1xc=.40c48e02-a096-4f9d-929f-69e0fd58f9e5@github.com>
References: <aQDgRwE-H5U0lz8wooLBAQZsuDnB5zZzjMhheIu3y9Y=.0bae7ae4-062e-47de-b7c3-4fedc5d7e20a@github.com>
 <BIDhtI2YAqm9sOWcZX7vweaMXGmK-6v_tPECWHut1xc=.40c48e02-a096-4f9d-929f-69e0fd58f9e5@github.com>
Message-ID: <PbZQ9H8J5RJFS8ofV__yIPUbkZ_Dvw07mMwi1K0s2zM=.ad5cfaab-240e-40a6-9a33-575458e61787@github.com>

On Mon, 9 Sep 2024 17:13:11 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

> The template parameter rename I was planning on doing in a followup issue, however, if you really want, I can make the fix here too.

Personally I'd be okay with doing it here as one final commit that can be viewed in isolation.

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

PR Comment: https://git.openjdk.org/jdk/pull/20872#issuecomment-2339696620

From rkennke at openjdk.org  Tue Sep 10 07:23:13 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Tue, 10 Sep 2024 07:23:13 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v6]
In-Reply-To: <86SISXYdKqHq5_nSqeVVNgmxplVK6QuHvOjCmiCKkzQ=.92ac6af1-9a94-4068-b625-1e331314826e@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <BGmZ04yibLn_KtPyQrA3sQv5OtMonrcDy3aN0vAj8NA=.5de6cae3-3a05-4a74-a15c-aade4176bdeb@github.com>
 <86SISXYdKqHq5_nSqeVVNgmxplVK6QuHvOjCmiCKkzQ=.92ac6af1-9a94-4068-b625-1e331314826e@github.com>
Message-ID: <Ed16htADrBzE1qG3KNbjqiOocZTb_s_n4LG5jfENVEs=.b0ffbe54-30a7-496d-ae7c-9204f97e1eb5@github.com>

On Mon, 9 Sep 2024 10:16:24 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix bit counts in GCForwarding
>
> src/hotspot/share/gc/shared/gcForwarding.hpp line 41:
> 
>> 39:  * bits (to indicate 'forwarded' state as usual).
>> 40:  */
>> 41: class GCForwarding : public AllStatic {
> 
> Since this class is only used for Full GCs, it may be useful to include that information, i.e. something like `FullGCForwarding` to avoid confusion why it is not used for other GCs too.
> (Unless this has been discussed and even rejected by me before).

I agree. In-fact, that has been my original name. It has been suggested that I change it to SlidingForwarding when that was the approach that we were going to take, but with the new implementation, FullGCForwarding makes most sense. I'll change it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1751400378

From rkennke at openjdk.org  Tue Sep 10 07:56:09 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Tue, 10 Sep 2024 07:56:09 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v6]
In-Reply-To: <86SISXYdKqHq5_nSqeVVNgmxplVK6QuHvOjCmiCKkzQ=.92ac6af1-9a94-4068-b625-1e331314826e@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <BGmZ04yibLn_KtPyQrA3sQv5OtMonrcDy3aN0vAj8NA=.5de6cae3-3a05-4a74-a15c-aade4176bdeb@github.com>
 <86SISXYdKqHq5_nSqeVVNgmxplVK6QuHvOjCmiCKkzQ=.92ac6af1-9a94-4068-b625-1e331314826e@github.com>
Message-ID: <Ok_qSVYsLHQokqwR-CoQcmDE2Ai8uZldwMB5tZT8r6Y=.7c8d6e77-45ed-4896-9629-fbb0a6074655@github.com>

On Mon, 9 Sep 2024 10:21:54 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix bit counts in GCForwarding
>
> src/hotspot/share/gc/shared/collectedHeap.cpp line 232:
> 
>> 230:   }
>> 231: 
>> 232:   // With compact headers, we can't safely access the class, due
> 
> Suggestion:
> 
>   // With compact headers, we can't safely access the klass, due
> 
> 
> This is the case why? Because we might not have copied the header yet? Is this method actually ever used while the forwarded object is unstable?
> Given this is used for verification only afaik, we should make an effort to provide that check.

With compact headers, we can't safely access the Klass* when the object has been forwarded, because non-full-GC-forwarding temporarily overwrites the mark-word, and thus the Klass*, with the forwarding pointer, and here we have no way to make a distinction between Full-GC and regular GC forwarding.

I improved the code to make the check when the object is not forwarded. Not sure if we could/should do more (e.g. pass around is_full argument to make the distinction, or find the - possibly few - places where we might call is_oop() on from-space objects in regular GC and do the check in a forwardee-safe way?).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1751448814

From rkennke at openjdk.org  Tue Sep 10 08:36:13 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Tue, 10 Sep 2024 08:36:13 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v8]
In-Reply-To: <rhloCBhjvBZ4Cs8LLpD_UyHIBR08b8NIjXwIEQlirrs=.8a06186e-a315-4977-961c-b172e077bd9a@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <J0g0PSye768dhN3JoXFsZ6FivocNBLPmHNtRUCOmLTw=.5756c64a-4763-4727-9637-ba3fe7b9b17d@github.com>
 <6usTXIvS83aO2VzX5xu2EnXlpIJ8YbfrWS6b3EI0MhE=.0e8cc603-0cd3-4bd9-b309-55e4dd0f0cb0@github.com>
 <rhloCBhjvBZ4Cs8LLpD_UyHIBR08b8NIjXwIEQlirrs=.8a06186e-a315-4977-961c-b172e077bd9a@github.com>
Message-ID: <U4wnNpLlescFdpGPsZwetL2Ymz6ygUyw7lNnEkwiw68=.5118cf4f-c46d-4ac1-8b5b-48f86e590f1c@github.com>

On Mon, 9 Sep 2024 14:58:07 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> src/hotspot/share/oops/oop.hpp line 134:
>> 
>>> 132:   inline Klass*   forward_safe_klass(markWord m) const;
>>> 133:   inline size_t   forward_safe_size();
>>> 134:   inline void     forward_safe_init_mark();
>> 
>> Given the comment these methods do not seem "safe" to me. Maybe use "raw" or something to better indicate that care must be taken to use them.
>> 
>> Maybe the "safe" refers to use them only in "safe" contexts, but in Hotspot code iirc we use something like "raw" or "unsafe".
>
> Restating my earlier comment about this: These functions are mainly used by the GCs. In one of the patches I've cleaned away all usages except for those in Shenandoah. I would prefer to see these completely removed from the oops/ directory and let the GCs decide when and how to perform "safe" reads of these values.

I've removed those methods.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1751514466

From rkennke at openjdk.org  Tue Sep 10 08:40:12 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Tue, 10 Sep 2024 08:40:12 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v8]
In-Reply-To: <W-1ANH5uIdfAoNRB5Mp1wbdS_aswZz8JhdHNNzz6pMw=.b3e0db43-1df0-4b0f-a6fe-ca77aa23d8f1@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <J0g0PSye768dhN3JoXFsZ6FivocNBLPmHNtRUCOmLTw=.5756c64a-4763-4727-9637-ba3fe7b9b17d@github.com>
 <6usTXIvS83aO2VzX5xu2EnXlpIJ8YbfrWS6b3EI0MhE=.0e8cc603-0cd3-4bd9-b309-55e4dd0f0cb0@github.com>
 <rhloCBhjvBZ4Cs8LLpD_UyHIBR08b8NIjXwIEQlirrs=.8a06186e-a315-4977-961c-b172e077bd9a@github.com>
 <W-1ANH5uIdfAoNRB5Mp1wbdS_aswZz8JhdHNNzz6pMw=.b3e0db43-1df0-4b0f-a6fe-ca77aa23d8f1@github.com>
Message-ID: <k5oJ0MxPfzSI0V4d8SGr8ApvuM9Xpuy25WiJsJ51Tl8=.62dd2a4c-497d-42bc-a513-0151786b19c5@github.com>

On Mon, 9 Sep 2024 15:01:10 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Just to be clear, the second part of the quoted sentence is important:
>>> could be any value *that is not a valid field offset*
>
>>     could be any value that is not a valid field offset
> 
> I understand that that "random value" needs to satisfy this condition.

With compact headers, this value should only be used in C2, and not really as an actual offset. An earlier version of the change had the value in src/hotspot/share/opto/type.hpp instead, and only an assert(!UCOH) in oopDesc::klass_offset_in_bytes(). I think this would be a better solution overall, because it prevents accidental (and wrong) usage of the klass_offset in the runtime. Back then it has been rejected by somebody (don't remember), because it made the C2 diff a little messier, so I kept it like it is now. I would prefer to reinstate it, though.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1751522091

From rkennke at openjdk.org  Tue Sep 10 08:44:11 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Tue, 10 Sep 2024 08:44:11 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v8]
In-Reply-To: <6usTXIvS83aO2VzX5xu2EnXlpIJ8YbfrWS6b3EI0MhE=.0e8cc603-0cd3-4bd9-b309-55e4dd0f0cb0@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <J0g0PSye768dhN3JoXFsZ6FivocNBLPmHNtRUCOmLTw=.5756c64a-4763-4727-9637-ba3fe7b9b17d@github.com>
 <6usTXIvS83aO2VzX5xu2EnXlpIJ8YbfrWS6b3EI0MhE=.0e8cc603-0cd3-4bd9-b309-55e4dd0f0cb0@github.com>
Message-ID: <bDtRnL6u3kG7s2mNBQyDSrWboOmMhdJVzUwfqd8osig=.c47cbaa9-9036-43f9-9fc7-75781296961b@github.com>

On Mon, 9 Sep 2024 12:12:23 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Roman Kennke has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Try to avoid lea in loadNklass (aarch64)
>>  - Fix release build error
>
> src/hotspot/share/oops/objArrayKlass.inline.hpp line 74:
> 
>> 72: void ObjArrayKlass::oop_oop_iterate(oop obj, OopClosureType* closure) {
>> 73:   // In this assert, we cannot safely access the Klass* with compact headers.
>> 74:   assert (UseCompactObjectHeaders || obj->is_array(), "obj must be array");
> 
> If we can't safely access the `Klass*` here, why is the call to `obj->klass()` below safe?

Good question. This comment and assert can probably be removed (same for the similar comment/assert in TypeArrayKlass::oop_oop_iterate_impl(). Could be a left-over from a time when we had to deal with OM and/or stack-locks in the header.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1751527745

From mli at openjdk.org  Tue Sep 10 08:54:13 2024
From: mli at openjdk.org (Hamlin Li)
Date: Tue, 10 Sep 2024 08:54:13 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v6]
In-Reply-To: <6I0T4rOjOTj-FZxpspatEo6j1_Num75bCAOBNxsrHI8=.097f731e-7c92-4eac-a379-c2df336cd412@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <BGmZ04yibLn_KtPyQrA3sQv5OtMonrcDy3aN0vAj8NA=.5de6cae3-3a05-4a74-a15c-aade4176bdeb@github.com>
 <utcfd2HiwL8a7ut2UJ7tHb1P_oz5TKXA9bwGQ5G_FnE=.63fa2666-dc3f-406d-b8d2-4f960f05f05d@github.com>
 <n33g0VZINE0Qly_UoJV2zOCDkapbuqFgRyzTYor6TrE=.7acb0ac5-5bbe-4747-bf3c-20110201616c@github.com>
 <wVUrQQtzaYdZNPBPyiuln0Zd8C67zG2y0yX2Iik6l_I=.0be5dcf7-c48d-4bb9-9966-23530f0b8d2e@github.com>
 <6I0T4rOjOTj-FZxpspatEo6j1_Num75bCAOBNxsrHI8=.097f731e-7c92-4eac-a379-c2df336cd412@github.com>
Message-ID: <J6x6kmRiK5huvPUhwooOR4_0blKnZqNvTaP-_kKhGlE=.e9e64c89-297b-42ee-ba51-1b79422d0387@github.com>

On Mon, 9 Sep 2024 14:08:53 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> Yes, I'm interested in it. Thanks for raising the discussion. :)
>
> If anybody is doing it, please send me a patch, or we can do it as a follow-up PR.

Thanks. I'll send it to you if I finish it in time, otherwise I will do it in a separate pr.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1751544394

From rkennke at openjdk.org  Tue Sep 10 09:31:09 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Tue, 10 Sep 2024 09:31:09 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v8]
In-Reply-To: <k5oJ0MxPfzSI0V4d8SGr8ApvuM9Xpuy25WiJsJ51Tl8=.62dd2a4c-497d-42bc-a513-0151786b19c5@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <J0g0PSye768dhN3JoXFsZ6FivocNBLPmHNtRUCOmLTw=.5756c64a-4763-4727-9637-ba3fe7b9b17d@github.com>
 <6usTXIvS83aO2VzX5xu2EnXlpIJ8YbfrWS6b3EI0MhE=.0e8cc603-0cd3-4bd9-b309-55e4dd0f0cb0@github.com>
 <rhloCBhjvBZ4Cs8LLpD_UyHIBR08b8NIjXwIEQlirrs=.8a06186e-a315-4977-961c-b172e077bd9a@github.com>
 <W-1ANH5uIdfAoNRB5Mp1wbdS_aswZz8JhdHNNzz6pMw=.b3e0db43-1df0-4b0f-a6fe-ca77aa23d8f1@github.com>
 <k5oJ0MxPfzSI0V4d8SGr8ApvuM9Xpuy25WiJsJ51Tl8=.62dd2a4c-497d-42bc-a513-0151786b19c5@github.com>
Message-ID: <NM8izXWScsGxiKeCqUapYVOoPaUfzdHwJq1GvAH58cs=.28e5b32c-59e0-4b24-8244-9580296d2e84@github.com>

On Tue, 10 Sep 2024 08:37:43 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>>>     could be any value that is not a valid field offset
>> 
>> I understand that that "random value" needs to satisfy this condition.
>
> With compact headers, this value should only be used in C2, and not really as an actual offset. An earlier version of the change had the value in src/hotspot/share/opto/type.hpp instead, and only an assert(!UCOH) in oopDesc::klass_offset_in_bytes(). I think this would be a better solution overall, because it prevents accidental (and wrong) usage of the klass_offset in the runtime. Back then it has been rejected by somebody (don't remember), because it made the C2 diff a little messier, so I kept it like it is now. I would prefer to reinstate it, though.

> (Fwiw, the method is also used during Universe initialization).

Yes, but only in the -UCOH branch.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1751604467

From stefank at openjdk.org  Tue Sep 10 10:05:10 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Tue, 10 Sep 2024 10:05:10 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v8]
In-Reply-To: <bDtRnL6u3kG7s2mNBQyDSrWboOmMhdJVzUwfqd8osig=.c47cbaa9-9036-43f9-9fc7-75781296961b@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <J0g0PSye768dhN3JoXFsZ6FivocNBLPmHNtRUCOmLTw=.5756c64a-4763-4727-9637-ba3fe7b9b17d@github.com>
 <6usTXIvS83aO2VzX5xu2EnXlpIJ8YbfrWS6b3EI0MhE=.0e8cc603-0cd3-4bd9-b309-55e4dd0f0cb0@github.com>
 <bDtRnL6u3kG7s2mNBQyDSrWboOmMhdJVzUwfqd8osig=.c47cbaa9-9036-43f9-9fc7-75781296961b@github.com>
Message-ID: <WyTjHxMb_l-Hkfe-sTK0e_4UpI9cn0E7BBiCpKDVI34=.282c10e9-a1cd-4d46-9d1f-133030ac9c58@github.com>

On Tue, 10 Sep 2024 08:41:16 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> src/hotspot/share/oops/objArrayKlass.inline.hpp line 74:
>> 
>>> 72: void ObjArrayKlass::oop_oop_iterate(oop obj, OopClosureType* closure) {
>>> 73:   // In this assert, we cannot safely access the Klass* with compact headers.
>>> 74:   assert (UseCompactObjectHeaders || obj->is_array(), "obj must be array");
>> 
>> If we can't safely access the `Klass*` here, why is the call to `obj->klass()` below safe?
>
> Good question. This comment and assert can probably be removed (same for the similar comment/assert in TypeArrayKlass::oop_oop_iterate_impl(). Could be a left-over from a time when we had to deal with OM and/or stack-locks in the header.

FWIW, I've been running tests with this assert restored (and the one in TypeArrayKlass) without hitting any problems.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1751656595

From rkennke at openjdk.org  Tue Sep 10 11:29:09 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Tue, 10 Sep 2024 11:29:09 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v6]
In-Reply-To: <Ok_qSVYsLHQokqwR-CoQcmDE2Ai8uZldwMB5tZT8r6Y=.7c8d6e77-45ed-4896-9629-fbb0a6074655@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <BGmZ04yibLn_KtPyQrA3sQv5OtMonrcDy3aN0vAj8NA=.5de6cae3-3a05-4a74-a15c-aade4176bdeb@github.com>
 <86SISXYdKqHq5_nSqeVVNgmxplVK6QuHvOjCmiCKkzQ=.92ac6af1-9a94-4068-b625-1e331314826e@github.com>
 <Ok_qSVYsLHQokqwR-CoQcmDE2Ai8uZldwMB5tZT8r6Y=.7c8d6e77-45ed-4896-9629-fbb0a6074655@github.com>
Message-ID: <SypFb1aukQ3WLqnYAGKUJj1LaS8ZEWucIFA8FzKKWXA=.92647e41-af44-4b88-933f-0f1cc6eff820@github.com>

On Tue, 10 Sep 2024 07:53:23 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> src/hotspot/share/gc/shared/collectedHeap.cpp line 232:
>> 
>>> 230:   }
>>> 231: 
>>> 232:   // With compact headers, we can't safely access the class, due
>> 
>> Suggestion:
>> 
>>   // With compact headers, we can't safely access the klass, due
>> 
>> 
>> This is the case why? Because we might not have copied the header yet? Is this method actually ever used while the forwarded object is unstable?
>> Given this is used for verification only afaik, we should make an effort to provide that check.
>
> With compact headers, we can't safely access the Klass* when the object has been forwarded, because non-full-GC-forwarding temporarily overwrites the mark-word, and thus the Klass*, with the forwarding pointer, and here we have no way to make a distinction between Full-GC and regular GC forwarding.
> 
> I improved the code to make the check when the object is not forwarded. Not sure if we could/should do more (e.g. pass around is_full argument to make the distinction, or find the - possibly few - places where we might call is_oop() on from-space objects in regular GC and do the check in a forwardee-safe way?).

Ah, I found it! It seems only the ShenandoahVerifier calls oop_iterate() on from_space objects, which can have a forwarding, which would mess with the object's Klass*. We're lucky because that iterator doesn't visit the Klass*. I see the following ways out:
- The caller must ensure that the oop is ok and Klass* is accessible. I could do that in the ShenandoahVerifier. It kinda defeats the point, though, we want the verifier operate on the 'raw' object, not necessarily the forwardee.
- Next easy way out would be to use 'this' instead of obj->klass(). Should makes sense, because it should always be the same. Using 'this' in the assert (this->is_array_klass()) is kinda bogus, though. And asserting (this == obj->klass()) would be nice, but would have the same problem as before where we would need to exclude UCOH for the case where Shenandoah needs it. In-fact, this is done already in oopDesc::oop_iterate_backwards(), but also excluding UCOH.
- We could add a hook in the iterator that gives the Klass* for a given oop, which can then be overridden by the actual iterator to do the right thing, e.g. load the Klass* from the forwardee.

WDYT?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1751770293

From stuefe at openjdk.org  Tue Sep 10 12:07:09 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Tue, 10 Sep 2024 12:07:09 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v8]
In-Reply-To: <vt3oD_XW4eFNTnPYoSa0-TZiEsFtBXJKfPdsIoqVuXM=.7e14c4df-4c66-4f52-9a59-e86fbcb6e7d9@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <J0g0PSye768dhN3JoXFsZ6FivocNBLPmHNtRUCOmLTw=.5756c64a-4763-4727-9637-ba3fe7b9b17d@github.com>
 <vt3oD_XW4eFNTnPYoSa0-TZiEsFtBXJKfPdsIoqVuXM=.7e14c4df-4c66-4f52-9a59-e86fbcb6e7d9@github.com>
Message-ID: <sUnwVBIPq6l_4sgw5hOnjU4cP_RL4AM7f9RCFIOK6lc=.cb3e7f4b-e862-48f8-a308-e762ea272294@github.com>

On Mon, 9 Sep 2024 15:49:57 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Roman Kennke has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Try to avoid lea in loadNklass (aarch64)
>>  - Fix release build error
>
> src/hotspot/share/oops/compressedKlass.cpp line 214:
> 
>> 212:     ss.print("Class space size (%zu) exceeds the maximum possible size (%zu)",
>> 213:               len, max_encoding_range_size());
>> 214:     vm_exit_during_initialization(ss.base());
> 
> Why does this exit and not turn off compressed klass pointers and compact object headers?

This is tricky. We are already deep in initialization and have done a couple of decisions based on +UseCompressedClassPointers (e.g. CDS setup). I *think* we could still go with -UseCCP, but I wonder whether this is wise. 

Note that this error is not new. In the old code, we simply asserted. That left us with UB in release builds, which remains unresolved. I simply made the error explicit in release too.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1751819814

From stuefe at openjdk.org  Tue Sep 10 12:16:11 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Tue, 10 Sep 2024 12:16:11 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v8]
In-Reply-To: <vt3oD_XW4eFNTnPYoSa0-TZiEsFtBXJKfPdsIoqVuXM=.7e14c4df-4c66-4f52-9a59-e86fbcb6e7d9@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <J0g0PSye768dhN3JoXFsZ6FivocNBLPmHNtRUCOmLTw=.5756c64a-4763-4727-9637-ba3fe7b9b17d@github.com>
 <vt3oD_XW4eFNTnPYoSa0-TZiEsFtBXJKfPdsIoqVuXM=.7e14c4df-4c66-4f52-9a59-e86fbcb6e7d9@github.com>
Message-ID: <Qmq5KYm4QolMsEt29X8lhx1oWSkBEApS-3iaIXd3L7o=.42bba1bc-d795-4712-a1b6-dab2781a60f7@github.com>

On Mon, 9 Sep 2024 15:50:50 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Roman Kennke has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Try to avoid lea in loadNklass (aarch64)
>>  - Fix release build error
>
> src/hotspot/share/oops/compressedKlass.cpp line 222:
> 
>> 220:     return;
>> 221:   }
>> 222: #endif
> 
> Why not add null pd_initialize to zero to remove this conditional code?

I can do that. Added to backlist (https://wiki.openjdk.org/display/lilliput/JEP-450+Review+Todo)

> src/hotspot/share/oops/compressedKlass.cpp line 224:
> 
>> 222: #endif
>> 223: 
>> 224:   if (tiny_classpointer_mode()) {
> 
> I kind of agree with Thomas Schatzl for this.  Maybe it should be compact_classpointer_mode(). It's nice to have a new string for grep, but they're not really that tiny.

Yes, makes sense. Added to backlist. 

This coding was developed somewhat independently from +COH at the beginning, but now the two parts (tinycp and the rest of COH) depend on each other anyway. I should just use UseCompactObjectHeaders or a flag directly derived from it.

> src/hotspot/share/oops/compressedKlass.cpp line 234:
> 
>> 232:     _range = len;
>> 233: 
>> 234:     constexpr int log_cacheline = 6;
> 
> Is 6 the log of DEFAULT_CACHE_LINE_SIZE?

64, yes

> src/hotspot/share/oops/compressedKlass.cpp line 243:
> 
>> 241:   } else {
>> 242: 
>> 243:     // In legacy mode, we try, in order of preference:
> 
> Can you not use the word 'legacy' here?  Maybe in "non-compact object header mode"...

okay.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1751828214
PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1751831035
PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1751831994
PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1751833034

From coleenp at openjdk.org  Tue Sep 10 12:22:09 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 10 Sep 2024 12:22:09 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v8]
In-Reply-To: <sUnwVBIPq6l_4sgw5hOnjU4cP_RL4AM7f9RCFIOK6lc=.cb3e7f4b-e862-48f8-a308-e762ea272294@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <J0g0PSye768dhN3JoXFsZ6FivocNBLPmHNtRUCOmLTw=.5756c64a-4763-4727-9637-ba3fe7b9b17d@github.com>
 <vt3oD_XW4eFNTnPYoSa0-TZiEsFtBXJKfPdsIoqVuXM=.7e14c4df-4c66-4f52-9a59-e86fbcb6e7d9@github.com>
 <sUnwVBIPq6l_4sgw5hOnjU4cP_RL4AM7f9RCFIOK6lc=.cb3e7f4b-e862-48f8-a308-e762ea272294@github.com>
Message-ID: <Kr9eGGeMs3LB-ULkPBBkaBBvURU3P7NJItuUR3Gmpmo=.d93bed80-2c06-414d-b8bd-b8f57a4deee3@github.com>

On Tue, 10 Sep 2024 12:03:59 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> src/hotspot/share/oops/compressedKlass.cpp line 214:
>> 
>>> 212:     ss.print("Class space size (%zu) exceeds the maximum possible size (%zu)",
>>> 213:               len, max_encoding_range_size());
>>> 214:     vm_exit_during_initialization(ss.base());
>> 
>> Why does this exit and not turn off compressed klass pointers and compact object headers?
>
> This is tricky. We are already deep in initialization and have done a couple of decisions based on +UseCompressedClassPointers (e.g. CDS setup). I *think* we could still go with -UseCCP, but I wonder whether this is wise. 
> 
> Note that this error is not new. In the old code, we simply asserted. That left us with UB in release builds, which remains unresolved. I simply made the error explicit in release too.

Ok, in this case, that's fine if we already asserted.  A fatal error is better.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1751840556

From rkennke at openjdk.org  Tue Sep 10 12:42:48 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Tue, 10 Sep 2024 12:42:48 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v10]
In-Reply-To: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
Message-ID: <RNbGUr1omfddrAOB_cPdxKaNbErq6Pj8cRidmhnmgZY=.f9ee76ff-4dcc-4739-809a-b8da10e4eadf@github.com>

> This is the main body of the JEP 450: Compact Object Headers (Experimental).
> 
> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing.
> 
> Main changes:
>  - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers.
>  - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded.
>  - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops).
>  - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all).
>  - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16).
>  - Arrays will now store their length at offset 8.
>  - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _coh variants of CDS archiv...

Roman Kennke has updated the pull request incrementally with six additional commits since the last revision:

 - More touch-ups, fix Shenandoah oop iterator
 - Remove asserts in XArrayKlass::oop_oop_iterate()
 - Various touch-ups
 - Improve is_oop()
 - Rename GCForwarding -> FullGCForwarding; some touch-ups
 - Fix comment

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20677/files
  - new: https://git.openjdk.org/jdk/pull/20677/files/2884499a..5da250cf

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20677&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20677&range=08-09

  Stats: 238 lines in 36 files changed: 74 ins; 65 del; 99 mod
  Patch: https://git.openjdk.org/jdk/pull/20677.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20677/head:pull/20677

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

From stuefe at openjdk.org  Tue Sep 10 12:42:49 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Tue, 10 Sep 2024 12:42:49 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v10]
In-Reply-To: <NR6CKOtdUaVarB7hiAUIAsIMe03qiTQr5VcEOWGt8mA=.164efc10-f0ff-4ddf-80b8-c56599c0ba7d@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <6Rant6SjxpFIHHWNthWc_plOdnGpWPvqj3rxRe144po=.bcdbad7a-e93a-41a3-b958-6ae602c7e083@github.com>
 <NR6CKOtdUaVarB7hiAUIAsIMe03qiTQr5VcEOWGt8mA=.164efc10-f0ff-4ddf-80b8-c56599c0ba7d@github.com>
Message-ID: <EZmLU9kQ--5-_Xi99YZG9HsKibIwnot3VcSI50gP6SY=.058873e4-dc41-460f-a5e4-3887d9be9d48@github.com>

On Mon, 9 Sep 2024 15:59:43 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Roman Kennke has updated the pull request incrementally with six additional commits since the last revision:
>> 
>>  - More touch-ups, fix Shenandoah oop iterator
>>  - Remove asserts in XArrayKlass::oop_oop_iterate()
>>  - Various touch-ups
>>  - Improve is_oop()
>>  - Rename GCForwarding -> FullGCForwarding; some touch-ups
>>  - Fix comment
>
> src/hotspot/share/oops/compressedKlass.cpp line 116:
> 
>> 114:   _range = end - _base;
>> 115: 
>> 116:   DEBUG_ONLY(assert_is_valid_encoding(addr, len, _base, _shift);)
> 
> Can you refactor so the aarch64 path runs this same code without duplication?

In tinycp mode, aarch64 runs this code though? The aarch64 variant of pd_initialize just returns then. In non-COH mode (preexisting, not touched by this patch) Aarch64 needs its own handling.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1751866773

From stuefe at openjdk.org  Tue Sep 10 12:42:49 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Tue, 10 Sep 2024 12:42:49 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v6]
In-Reply-To: <4cTKmlYUEtFpr2TURf25gd7-_eSb-uF0cC0BmLl6wd0=.b9f0482d-5439-421b-9a29-7a014fb72558@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <BGmZ04yibLn_KtPyQrA3sQv5OtMonrcDy3aN0vAj8NA=.5de6cae3-3a05-4a74-a15c-aade4176bdeb@github.com>
 <86SISXYdKqHq5_nSqeVVNgmxplVK6QuHvOjCmiCKkzQ=.92ac6af1-9a94-4068-b625-1e331314826e@github.com>
 <4cTKmlYUEtFpr2TURf25gd7-_eSb-uF0cC0BmLl6wd0=.b9f0482d-5439-421b-9a29-7a014fb72558@github.com>
Message-ID: <j8Kjz_b9OX7HADy3DxIfM6yOCxA6_Rk4scI6UxTI2Rs=.7b20c9e9-5c39-4f86-9b0c-732c116d323a@github.com>

On Mon, 9 Sep 2024 16:01:10 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> src/hotspot/share/oops/compressedKlass.hpp line 43:
>> 
>>> 41: 
>>> 42:   // Tiny-class-pointer mode
>>> 43:   static int _tiny_cp; // -1, 0=true, 1=false
>> 
>> Suggestion:
>> 
>>   static int _tiny_cp; // -1 = uninitialized, 0 = true, 1 = false
>> 
>> In addition to that, I am not sure if introducing a new term ("tiny") for compact class header related changes (and just here) makes the code more clear; I would have expected a "_compact_" prefix. Also all other members use "k"-klass and spell out "klass pointer", so I would prefer to keep that style.
>
> I agree with this.  'cp' reads as ConstantPool for me even though this is a different context.

Okay, I will change that

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1751867998

From gziemski at openjdk.org  Tue Sep 10 14:18:08 2024
From: gziemski at openjdk.org (Gerard Ziemski)
Date: Tue, 10 Sep 2024 14:18:08 GMT
Subject: RFR: 8337563: NMT: rename MEMFLAGS to MemTag
In-Reply-To: <PbZQ9H8J5RJFS8ofV__yIPUbkZ_Dvw07mMwi1K0s2zM=.ad5cfaab-240e-40a6-9a33-575458e61787@github.com>
References: <aQDgRwE-H5U0lz8wooLBAQZsuDnB5zZzjMhheIu3y9Y=.0bae7ae4-062e-47de-b7c3-4fedc5d7e20a@github.com>
 <BIDhtI2YAqm9sOWcZX7vweaMXGmK-6v_tPECWHut1xc=.40c48e02-a096-4f9d-929f-69e0fd58f9e5@github.com>
 <PbZQ9H8J5RJFS8ofV__yIPUbkZ_Dvw07mMwi1K0s2zM=.ad5cfaab-240e-40a6-9a33-575458e61787@github.com>
Message-ID: <zZ5zl-CqYtuZbIlaKdvguxXDE80NmZnOwPfC3qwvNWU=.c77376d7-450b-44e8-98ef-3affdfee05f4@github.com>

On Tue, 10 Sep 2024 05:57:08 GMT, David Holmes <dholmes at openjdk.org> wrote:

> > The template parameter rename I was planning on doing in a followup issue, however, if you really want, I can make the fix here too.
> 
> Personally I'd be okay with doing it here as one final commit that can be viewed in isolation.

Sure, I can do it.

Is everyone OK with MT as the template parameter name? Another obvious choice is MEM_TAG

Side note: why are template parameter names all capitals? To help distinguish them from "regular" parameters? Do we still want that naming scheme, or can we switch here to using mem_tag?

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

PR Comment: https://git.openjdk.org/jdk/pull/20872#issuecomment-2340957192

From stefank at openjdk.org  Tue Sep 10 15:40:10 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Tue, 10 Sep 2024 15:40:10 GMT
Subject: RFR: 8337563: NMT: rename MEMFLAGS to MemTag [v5]
In-Reply-To: <buLImdLbKR7m3KWE_ELGi9zoSfz4Wy7g-xsjhrVHj3A=.5e18e806-a617-4f2b-8cb4-ddc77ead662a@github.com>
References: <aQDgRwE-H5U0lz8wooLBAQZsuDnB5zZzjMhheIu3y9Y=.0bae7ae4-062e-47de-b7c3-4fedc5d7e20a@github.com>
 <buLImdLbKR7m3KWE_ELGi9zoSfz4Wy7g-xsjhrVHj3A=.5e18e806-a617-4f2b-8cb4-ddc77ead662a@github.com>
Message-ID: <lSSQs7p7nNMG71-MO8NCL40y6qd8x8NmqEtqjOO78xU=.554e183b-e59c-4095-8a98-c6b8f0bfc34c@github.com>

On Mon, 9 Sep 2024 19:02:25 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

>> Please review this cleanup, where we rename `MEMFLAGS` to `MemTag`.
>> 
>> `MEMFLAGS` implies that we can use more than one at the same time, but those are exclusive values, so `MemTag` is a more suitable name.
>> 
>> This fix also includes a cleanup of all the related parameter names and local variable names.
>> 
>> Testing is pending...
>> 
>> Note: there is more history in old closed PRs [https://github.com/openjdk/jdk/pull/20497](https://github.com/openjdk/jdk/pull/20497) and [https://github.com/openjdk/jdk/pull/20472](https://github.com/openjdk/jdk/pull/20472)
>
> Gerard Ziemski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix test

At least in the GC code we sometimes spell out the template parameter name with CamelCase: Iterator, Function, ClosureType, OopClosureT, Parallel, ...

I'm OK with using MT as the template parameter name. I'm also OK with using mem_tag, but you might hit problems when classes both have template parameter name and functions that take a MemTag. I see that GrowableArrayCHeap has this situation, but it looks like that is accidental code and isn't really needed, so maybe this isn't a big concern.

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

PR Comment: https://git.openjdk.org/jdk/pull/20872#issuecomment-2341288588

From wkemper at openjdk.org  Tue Sep 10 17:17:36 2024
From: wkemper at openjdk.org (William Kemper)
Date: Tue, 10 Sep 2024 17:17:36 GMT
Subject: RFR: 8339870: Remove yet more stale TODOs
Message-ID: <R2zLMF_H62csd-NyxcVPsR9BaqxKlS8t6llk4_p6_hI=.77d6a2aa-6d10-4c6d-8582-ae37dbd78d5f@github.com>

Final round of TODO removal.

## Testing

GHA, Internal pipelines

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

Commit messages:
 - Make verify more strict
 - Make generation's inclusion test stricter
 - Remove more TODOs (moved into ticketing)
 - Use table scanner abstraction for remset verification closure
 - Merge remote-tracking branch 'shenandoah/master' into fix-yet-more-stale-todos
 - Remove TODOs, consolidate remset verification for regions
 - Remove TODOs, fix typo in closure name
 - Remove TODOs, put pointer's asterisk next to type
 - Remove TODOs
 - oop arguments do not need to be const
 - ... and 11 more: https://git.openjdk.org/shenandoah/compare/662d146d...8719ba9d

Changes: https://git.openjdk.org/shenandoah/pull/496/files
  Webrev: https://webrevs.openjdk.org/?repo=shenandoah&pr=496&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8339870
  Stats: 265 lines in 10 files changed: 48 ins; 132 del; 85 mod
  Patch: https://git.openjdk.org/shenandoah/pull/496.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah.git pull/496/head:pull/496

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

From rkennke at openjdk.org  Tue Sep 10 19:11:30 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Tue, 10 Sep 2024 19:11:30 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v11]
In-Reply-To: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
Message-ID: <DUgk6HT_Zk5KnbmAd_HzrJi4B8D1J-uuoAGzReWyI8s=.6c04f90a-bf1d-49af-a31d-5224973952d4@github.com>

> This is the main body of the JEP 450: Compact Object Headers (Experimental).
> 
> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing.
> 
> Main changes:
>  - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers.
>  - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded.
>  - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops).
>  - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all).
>  - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16).
>  - Arrays will now store their length at offset 8.
>  - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _coh variants of CDS archiv...

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

  Fix FullGCForwarding initialization

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20677/files
  - new: https://git.openjdk.org/jdk/pull/20677/files/5da250cf..6abda7bc

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20677&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20677&range=09-10

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

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

From stuefe at openjdk.org  Tue Sep 10 19:11:30 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Tue, 10 Sep 2024 19:11:30 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v8]
In-Reply-To: <vt3oD_XW4eFNTnPYoSa0-TZiEsFtBXJKfPdsIoqVuXM=.7e14c4df-4c66-4f52-9a59-e86fbcb6e7d9@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <J0g0PSye768dhN3JoXFsZ6FivocNBLPmHNtRUCOmLTw=.5756c64a-4763-4727-9637-ba3fe7b9b17d@github.com>
 <vt3oD_XW4eFNTnPYoSa0-TZiEsFtBXJKfPdsIoqVuXM=.7e14c4df-4c66-4f52-9a59-e86fbcb6e7d9@github.com>
Message-ID: <yk4X4o4WwCsA2Hj5ncidSj7Ng-74NfzKZy4J37uHnyQ=.dcc835de-584a-4922-9234-c7b54d7e35ed@github.com>

On Mon, 9 Sep 2024 17:40:03 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Roman Kennke has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Try to avoid lea in loadNklass (aarch64)
>>  - Fix release build error
>
> src/hotspot/share/oops/compressedKlass.inline.hpp line 100:
> 
>> 98:   check_valid_klass(k, base(), shift());
>> 99:   // Also assert that k falls into what we know is the valid Klass range. This is usually smaller
>> 100:   // than the encoding range (e.g. encoding range covers 4G, but we only have 1G class space and a
> 
> 1G is the default CompressedClassSpaceSize but can be larger, right?  So the comment isn't quite accurate.  Or with tiny class pointers can it only be 1G?

The comment was misleading, it referred to the 1g default class space. I recently changed class space (in mainline) to be max. 4GB (minus whatever little CDS needs), and for +COH, this is still true. 22 bit class pointer and 10 bit shift still gives us a max encoding range size of 4GB.

I will update the comment. (->backlist)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1751872461

From coleenp at openjdk.org  Tue Sep 10 20:39:09 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 10 Sep 2024 20:39:09 GMT
Subject: RFR: 8337563: NMT: rename MEMFLAGS to MemTag [v5]
In-Reply-To: <buLImdLbKR7m3KWE_ELGi9zoSfz4Wy7g-xsjhrVHj3A=.5e18e806-a617-4f2b-8cb4-ddc77ead662a@github.com>
References: <aQDgRwE-H5U0lz8wooLBAQZsuDnB5zZzjMhheIu3y9Y=.0bae7ae4-062e-47de-b7c3-4fedc5d7e20a@github.com>
 <buLImdLbKR7m3KWE_ELGi9zoSfz4Wy7g-xsjhrVHj3A=.5e18e806-a617-4f2b-8cb4-ddc77ead662a@github.com>
Message-ID: <xVN52cTBy0_c5wniriBzT7ineAKXo1-QdRpPu_jngiI=.db27e8c5-592a-4932-bb74-63fd8aef17fa@github.com>

On Mon, 9 Sep 2024 19:02:25 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

>> Please review this cleanup, where we rename `MEMFLAGS` to `MemTag`.
>> 
>> `MEMFLAGS` implies that we can use more than one at the same time, but those are exclusive values, so `MemTag` is a more suitable name.
>> 
>> This fix also includes a cleanup of all the related parameter names and local variable names.
>> 
>> Testing is pending...
>> 
>> Note: there is more history in old closed PRs [https://github.com/openjdk/jdk/pull/20497](https://github.com/openjdk/jdk/pull/20497) and [https://github.com/openjdk/jdk/pull/20472](https://github.com/openjdk/jdk/pull/20472)
>
> Gerard Ziemski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix test

So many mem_tags.  It looks fine to me.  I didn't see that many "MemTag F"'s except in the ConcurrentHashTable.  You could change that in a further patch.  I would prefer a one letter template parameter name like maybe M (since T seems too generic).  But F doesn't really bother me that much.  It's not like typename E means that much either.

Update: if people want the template parameter to be MemTag MT, that's fine too.

src/hotspot/share/nmt/memTracker.hpp line 265:

> 263: 
> 264:   // MallocLimt: Given an allocation size s, check if mallocing this much
> 265:   // under category f would hit either the global limit or the limit for mem_tag.

I don't know what "category f" is.   Maybe reword as

    // MallocLimit: Given an allocation size s, check if allocating this much memory would hit the global limit or the
    // limit tagged with mem_tag.

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

Marked as reviewed by coleenp (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20872#pullrequestreview-2293706394
PR Comment: https://git.openjdk.org/jdk/pull/20872#issuecomment-2341965524
PR Review Comment: https://git.openjdk.org/jdk/pull/20872#discussion_r1752681558

From ysr at openjdk.org  Tue Sep 10 20:40:29 2024
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Tue, 10 Sep 2024 20:40:29 GMT
Subject: RFR: 8339870: Remove yet more stale TODOs
In-Reply-To: <R2zLMF_H62csd-NyxcVPsR9BaqxKlS8t6llk4_p6_hI=.77d6a2aa-6d10-4c6d-8582-ae37dbd78d5f@github.com>
References: <R2zLMF_H62csd-NyxcVPsR9BaqxKlS8t6llk4_p6_hI=.77d6a2aa-6d10-4c6d-8582-ae37dbd78d5f@github.com>
Message-ID: <R4_GiNGjfn3lxMJfeJ69JxUf90OjzlrnwK5YDUCQKYE=.261feb1a-f8b4-4ce3-877b-c64fe3c33e88@github.com>

On Tue, 10 Sep 2024 17:12:13 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Final round of TODO removal.
> * Move asterisk for pointer next to type, not variable
> * Remembered set verifier uses a small 'scanner' abstraction to simplify reading of read or write card table
> 
> ## Testing
> 
> GHA, Internal pipelines

Looks good. Thanks for the cleanups!

src/hotspot/share/gc/shenandoah/shenandoahConcurrentGC.cpp line 687:

> 685:     _generation->prepare_regions_and_collection_set(true /*concurrent*/);
> 686: 
> 687:     // Upon return from prepare_regions_and_collection_set(), certain parameters have been established to govern the

For the block comment at lines 687-702 (right pane), would it make sense to move it to the spec of `prepare_...` and remove this block comment from here?

src/hotspot/share/gc/shenandoah/shenandoahFullGC.cpp line 736:

> 734: //  of memory.  As currently implemented, all regions are compacted toward the low-end of memory.  This creates more
> 735: //  fragmentation of the heap, because old-gen regions get scattered among low-address regions such that it becomes
> 736: //  more difficult to find contiguous regions for humongous objects.

Is this covered in a ticket?

src/hotspot/share/gc/shenandoah/shenandoahOldGeneration.cpp line 728:

> 726:         assert(_old_heuristics->coalesce_and_fill_candidates_count() > 0, "Expected coalesce and fill candidates");
> 727:         // When the heuristic put the old generation in this state, it didn't know
> 728:         // that we would unload classes and make everything parseable. But, we know

parsable

src/hotspot/share/gc/shenandoah/shenandoahScanRemembered.cpp line 91:

> 89: }
> 90: 
> 91: bool ShenandoahDirectCardMarkRememberedSet::is_write_card_dirty(HeapWord* p) const {

Interesting. Is this new? Is it used somewhere or introduced for the purpose of a more consistent/uniform API?

(Not requiring any change; just asking. I am all for uniform/consistent APIs.)

src/hotspot/share/gc/shenandoah/shenandoahScanRemembered.cpp line 324:

> 322: }
> 323: 
> 324: bool ShenandoahScanRemembered::is_write_card_dirty(HeapWord* p) {

Same question/remark as I asked/made for the ShenDirectCardMarkRS api above at line 91.

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

> 870:   size_t _chunk_offset;          // HeapWordSize offset
> 871:   size_t _chunk_size;            // HeapWordSize qty
> 872: };

At line 880 below:

"other worker will threads repeatedly ..." should be "other worker threads will repeatedly".

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

Marked as reviewed by ysr (Committer).

PR Review: https://git.openjdk.org/shenandoah/pull/496#pullrequestreview-2293570817
PR Review Comment: https://git.openjdk.org/shenandoah/pull/496#discussion_r1752598856
PR Review Comment: https://git.openjdk.org/shenandoah/pull/496#discussion_r1752628748
PR Review Comment: https://git.openjdk.org/shenandoah/pull/496#discussion_r1752631946
PR Review Comment: https://git.openjdk.org/shenandoah/pull/496#discussion_r1752652646
PR Review Comment: https://git.openjdk.org/shenandoah/pull/496#discussion_r1752657839
PR Review Comment: https://git.openjdk.org/shenandoah/pull/496#discussion_r1752667945

From ysr at openjdk.org  Tue Sep 10 20:40:30 2024
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Tue, 10 Sep 2024 20:40:30 GMT
Subject: RFR: 8339870: Remove yet more stale TODOs
In-Reply-To: <R4_GiNGjfn3lxMJfeJ69JxUf90OjzlrnwK5YDUCQKYE=.261feb1a-f8b4-4ce3-877b-c64fe3c33e88@github.com>
References: <R2zLMF_H62csd-NyxcVPsR9BaqxKlS8t6llk4_p6_hI=.77d6a2aa-6d10-4c6d-8582-ae37dbd78d5f@github.com>
 <R4_GiNGjfn3lxMJfeJ69JxUf90OjzlrnwK5YDUCQKYE=.261feb1a-f8b4-4ce3-877b-c64fe3c33e88@github.com>
Message-ID: <go3oICacztbX2NQEs54XcO-h4pUuN0pLxl0plBS2OxQ=.d1a6614d-7fc0-4297-a69d-70b4222f9f65@github.com>

On Tue, 10 Sep 2024 19:16:39 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

>> Final round of TODO removal.
>> * Move asterisk for pointer next to type, not variable
>> * Remembered set verifier uses a small 'scanner' abstraction to simplify reading of read or write card table
>> 
>> ## Testing
>> 
>> GHA, Internal pipelines
>
> src/hotspot/share/gc/shenandoah/shenandoahConcurrentGC.cpp line 687:
> 
>> 685:     _generation->prepare_regions_and_collection_set(true /*concurrent*/);
>> 686: 
>> 687:     // Upon return from prepare_regions_and_collection_set(), certain parameters have been established to govern the
> 
> For the block comment at lines 687-702 (right pane), would it make sense to move it to the spec of `prepare_...` and remove this block comment from here?

In fact, these are already present in the documentation for the method, so we should just remove this and declutter the code here.

> src/hotspot/share/gc/shenandoah/shenandoahScanRemembered.cpp line 91:
> 
>> 89: }
>> 90: 
>> 91: bool ShenandoahDirectCardMarkRememberedSet::is_write_card_dirty(HeapWord* p) const {
> 
> Interesting. Is this new? Is it used somewhere or introduced for the purpose of a more consistent/uniform API?
> 
> (Not requiring any change; just asking. I am all for uniform/consistent APIs.)

Never mind. Found the (new) place where it's now used.

> src/hotspot/share/gc/shenandoah/shenandoahScanRemembered.cpp line 324:
> 
>> 322: }
>> 323: 
>> 324: bool ShenandoahScanRemembered::is_write_card_dirty(HeapWord* p) {
> 
> Same question/remark as I asked/made for the ShenDirectCardMarkRS api above at line 91.

Never mind; found where it's used now.

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

PR Review Comment: https://git.openjdk.org/shenandoah/pull/496#discussion_r1752638441
PR Review Comment: https://git.openjdk.org/shenandoah/pull/496#discussion_r1752690061
PR Review Comment: https://git.openjdk.org/shenandoah/pull/496#discussion_r1752690555

From kdnilsen at openjdk.org  Tue Sep 10 20:46:39 2024
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Tue, 10 Sep 2024 20:46:39 GMT
Subject: RFR: 8339870: Remove yet more stale TODOs
In-Reply-To: <R2zLMF_H62csd-NyxcVPsR9BaqxKlS8t6llk4_p6_hI=.77d6a2aa-6d10-4c6d-8582-ae37dbd78d5f@github.com>
References: <R2zLMF_H62csd-NyxcVPsR9BaqxKlS8t6llk4_p6_hI=.77d6a2aa-6d10-4c6d-8582-ae37dbd78d5f@github.com>
Message-ID: <KvGk1hB9ADYqKvWPVy0aWXJ4ozUxY83ZcmW9NxZV58Y=.e8cfdc13-f9b7-485d-be41-09203efd0fc7@github.com>

On Tue, 10 Sep 2024 17:12:13 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Final round of TODO removal.
> * Move asterisk for pointer next to type, not variable
> * Remembered set verifier uses a small 'scanner' abstraction to simplify reading of read or write card table
> 
> ## Testing
> 
> GHA, Internal pipelines

Marked as reviewed by kdnilsen (Committer).

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

PR Review: https://git.openjdk.org/shenandoah/pull/496#pullrequestreview-2293732714

From gziemski at openjdk.org  Tue Sep 10 20:47:46 2024
From: gziemski at openjdk.org (Gerard Ziemski)
Date: Tue, 10 Sep 2024 20:47:46 GMT
Subject: RFR: 8337563: NMT: rename MEMFLAGS to MemTag [v6]
In-Reply-To: <aQDgRwE-H5U0lz8wooLBAQZsuDnB5zZzjMhheIu3y9Y=.0bae7ae4-062e-47de-b7c3-4fedc5d7e20a@github.com>
References: <aQDgRwE-H5U0lz8wooLBAQZsuDnB5zZzjMhheIu3y9Y=.0bae7ae4-062e-47de-b7c3-4fedc5d7e20a@github.com>
Message-ID: <KrlSbjpoVrGnCGiHPmVQxtxamydQ99upC3uMUsKGJ-E=.23413fc3-bcff-4be1-8d4f-680c5469e079@github.com>

> Please review this cleanup, where we rename `MEMFLAGS` to `MemTag`.
> 
> `MEMFLAGS` implies that we can use more than one at the same time, but those are exclusive values, so `MemTag` is a more suitable name.
> 
> This fix also includes a cleanup of all the related parameter names and local variable names.
> 
> Testing is pending...
> 
> Note: there is more history in old closed PRs [https://github.com/openjdk/jdk/pull/20497](https://github.com/openjdk/jdk/pull/20497) and [https://github.com/openjdk/jdk/pull/20472](https://github.com/openjdk/jdk/pull/20472)

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

  rename MemoryTag template parameter names

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20872/files
  - new: https://git.openjdk.org/jdk/pull/20872/files/7a4f6e01..c779754c

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

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

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

From gziemski at openjdk.org  Tue Sep 10 20:53:46 2024
From: gziemski at openjdk.org (Gerard Ziemski)
Date: Tue, 10 Sep 2024 20:53:46 GMT
Subject: RFR: 8337563: NMT: rename MEMFLAGS to MemTag [v7]
In-Reply-To: <aQDgRwE-H5U0lz8wooLBAQZsuDnB5zZzjMhheIu3y9Y=.0bae7ae4-062e-47de-b7c3-4fedc5d7e20a@github.com>
References: <aQDgRwE-H5U0lz8wooLBAQZsuDnB5zZzjMhheIu3y9Y=.0bae7ae4-062e-47de-b7c3-4fedc5d7e20a@github.com>
Message-ID: <XNRFNQoz26gPhgG5XSzcbcYiC0RlNv6MPdNI1K1hlkI=.f4bd698b-e546-440f-8c50-b8af375526e5@github.com>

> Please review this cleanup, where we rename `MEMFLAGS` to `MemTag`.
> 
> `MEMFLAGS` implies that we can use more than one at the same time, but those are exclusive values, so `MemTag` is a more suitable name.
> 
> This fix also includes a cleanup of all the related parameter names and local variable names.
> 
> Testing is pending...
> 
> Note: there is more history in old closed PRs [https://github.com/openjdk/jdk/pull/20497](https://github.com/openjdk/jdk/pull/20497) and [https://github.com/openjdk/jdk/pull/20472](https://github.com/openjdk/jdk/pull/20472)

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

  Coleen's feedback

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20872/files
  - new: https://git.openjdk.org/jdk/pull/20872/files/c779754c..f1faba35

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

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

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

From gziemski at openjdk.org  Tue Sep 10 20:53:47 2024
From: gziemski at openjdk.org (Gerard Ziemski)
Date: Tue, 10 Sep 2024 20:53:47 GMT
Subject: RFR: 8337563: NMT: rename MEMFLAGS to MemTag [v5]
In-Reply-To: <xVN52cTBy0_c5wniriBzT7ineAKXo1-QdRpPu_jngiI=.db27e8c5-592a-4932-bb74-63fd8aef17fa@github.com>
References: <aQDgRwE-H5U0lz8wooLBAQZsuDnB5zZzjMhheIu3y9Y=.0bae7ae4-062e-47de-b7c3-4fedc5d7e20a@github.com>
 <buLImdLbKR7m3KWE_ELGi9zoSfz4Wy7g-xsjhrVHj3A=.5e18e806-a617-4f2b-8cb4-ddc77ead662a@github.com>
 <xVN52cTBy0_c5wniriBzT7ineAKXo1-QdRpPu_jngiI=.db27e8c5-592a-4932-bb74-63fd8aef17fa@github.com>
Message-ID: <T5u-dwK0HY2el11KF_E8Y3kVYIOhXgG4sCWTJ_n96Eo=.28d11fa2-1063-4d90-b517-4282137191bd@github.com>

On Tue, 10 Sep 2024 20:28:01 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Gerard Ziemski has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix test
>
> src/hotspot/share/nmt/memTracker.hpp line 265:
> 
>> 263: 
>> 264:   // MallocLimt: Given an allocation size s, check if mallocing this much
>> 265:   // under category f would hit either the global limit or the limit for mem_tag.
> 
> I don't know what "category f" is.   Maybe reword as
> 
>     // MallocLimit: Given an allocation size s, check if allocating this much memory would hit the global limit or the
>     // limit tagged with mem_tag.

Fixed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20872#discussion_r1752704620

From gziemski at openjdk.org  Tue Sep 10 20:57:07 2024
From: gziemski at openjdk.org (Gerard Ziemski)
Date: Tue, 10 Sep 2024 20:57:07 GMT
Subject: RFR: 8337563: NMT: rename MEMFLAGS to MemTag [v7]
In-Reply-To: <XNRFNQoz26gPhgG5XSzcbcYiC0RlNv6MPdNI1K1hlkI=.f4bd698b-e546-440f-8c50-b8af375526e5@github.com>
References: <aQDgRwE-H5U0lz8wooLBAQZsuDnB5zZzjMhheIu3y9Y=.0bae7ae4-062e-47de-b7c3-4fedc5d7e20a@github.com>
 <XNRFNQoz26gPhgG5XSzcbcYiC0RlNv6MPdNI1K1hlkI=.f4bd698b-e546-440f-8c50-b8af375526e5@github.com>
Message-ID: <_TKagUmXD-PDlDcJuMltsaJo_MVX4ATgobge0V-RfGE=.28b3d5d3-8a09-444c-8383-54606627d956@github.com>

On Tue, 10 Sep 2024 20:53:46 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

>> Please review this cleanup, where we rename `MEMFLAGS` to `MemTag`.
>> 
>> `MEMFLAGS` implies that we can use more than one at the same time, but those are exclusive values, so `MemTag` is a more suitable name.
>> 
>> This fix also includes a cleanup of all the related parameter names and local variable names.
>> 
>> Testing is pending...
>> 
>> Note: there is more history in old closed PRs [https://github.com/openjdk/jdk/pull/20497](https://github.com/openjdk/jdk/pull/20497) and [https://github.com/openjdk/jdk/pull/20472](https://github.com/openjdk/jdk/pull/20472)
>
> Gerard Ziemski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Coleen's feedback

I went with `MT` throughout the code for all MemTag template parameter names. It will be a nice mental shortcut once we get used to the change...

I did not want to rock the boat too much and decided  not to use `mem_tag` for template parameter names, it just did not look good next to the other names, with all capital letters.

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

PR Comment: https://git.openjdk.org/jdk/pull/20872#issuecomment-2341992426

From gziemski at openjdk.org  Tue Sep 10 21:01:08 2024
From: gziemski at openjdk.org (Gerard Ziemski)
Date: Tue, 10 Sep 2024 21:01:08 GMT
Subject: RFR: 8337563: NMT: rename MEMFLAGS to MemTag [v7]
In-Reply-To: <XNRFNQoz26gPhgG5XSzcbcYiC0RlNv6MPdNI1K1hlkI=.f4bd698b-e546-440f-8c50-b8af375526e5@github.com>
References: <aQDgRwE-H5U0lz8wooLBAQZsuDnB5zZzjMhheIu3y9Y=.0bae7ae4-062e-47de-b7c3-4fedc5d7e20a@github.com>
 <XNRFNQoz26gPhgG5XSzcbcYiC0RlNv6MPdNI1K1hlkI=.f4bd698b-e546-440f-8c50-b8af375526e5@github.com>
Message-ID: <R_gVFUw_p-z7o9ZZkp2ljQVYEb0IKVQV4wHlTciU1c4=.f1f4bb08-148a-405d-bca0-b87a2da440fe@github.com>

On Tue, 10 Sep 2024 20:53:46 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

>> Please review this cleanup, where we rename `MEMFLAGS` to `MemTag`.
>> 
>> `MEMFLAGS` implies that we can use more than one at the same time, but those are exclusive values, so `MemTag` is a more suitable name.
>> 
>> This fix also includes a cleanup of all the related function/template parameter names and local variable names.
>> 
>> Testing is pending...
>> 
>> Note: there is more history in old closed PRs [https://github.com/openjdk/jdk/pull/20497](https://github.com/openjdk/jdk/pull/20497) and [https://github.com/openjdk/jdk/pull/20472](https://github.com/openjdk/jdk/pull/20472)
>
> Gerard Ziemski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Coleen's feedback

Thank you for the feedback Coleen!

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

PR Comment: https://git.openjdk.org/jdk/pull/20872#issuecomment-2341999055

From kbarrett at openjdk.org  Tue Sep 10 22:01:07 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Tue, 10 Sep 2024 22:01:07 GMT
Subject: RFR: 8337563: NMT: rename MEMFLAGS to MemTag
In-Reply-To: <zZ5zl-CqYtuZbIlaKdvguxXDE80NmZnOwPfC3qwvNWU=.c77376d7-450b-44e8-98ef-3affdfee05f4@github.com>
References: <aQDgRwE-H5U0lz8wooLBAQZsuDnB5zZzjMhheIu3y9Y=.0bae7ae4-062e-47de-b7c3-4fedc5d7e20a@github.com>
 <BIDhtI2YAqm9sOWcZX7vweaMXGmK-6v_tPECWHut1xc=.40c48e02-a096-4f9d-929f-69e0fd58f9e5@github.com>
 <PbZQ9H8J5RJFS8ofV__yIPUbkZ_Dvw07mMwi1K0s2zM=.ad5cfaab-240e-40a6-9a33-575458e61787@github.com>
 <zZ5zl-CqYtuZbIlaKdvguxXDE80NmZnOwPfC3qwvNWU=.c77376d7-450b-44e8-98ef-3affdfee05f4@github.com>
Message-ID: <babHY3358jtnOm5SPSBZqwM17LuMVkv1JrFE6lOCtcA=.3c24579b-7244-4caa-bd0c-447879c15952@github.com>

On Tue, 10 Sep 2024 14:15:53 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

> Is everyone OK with `MT` as the template parameter name? Another obvious choice is `MEM_TAG`
> 
> Side note: why are template parameter names all capitals? To help distinguish them from "regular" parameters? Do we still want that naming scheme, or can we switch here to using `mem_tag`?

Type template parameters should follow the style guide rules for type names.  I've not noticed many (any?) cases of
noncompliance.

Non-type template parameters should follow the style guide rules for ordinary local variables, or perhaps local
constants.  The style guide doesn't currently say which, doesn't discuss possible differences between local and
non-local naming, and is also currently loose on constant names.  (The GC team recently discussed constant
naming, strongly preferring MixedCase, and strongly disliking ALL_CAPS.)  I think I've mostly use local variable
style.  Non-type template parameters are sometimes used in non-trivial expressions, so having a more meaningful
name can be helpful.

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

PR Comment: https://git.openjdk.org/jdk/pull/20872#issuecomment-2342079640

From kbarrett at openjdk.org  Tue Sep 10 22:06:06 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Tue, 10 Sep 2024 22:06:06 GMT
Subject: RFR: 8337563: NMT: rename MEMFLAGS to MemTag
In-Reply-To: <babHY3358jtnOm5SPSBZqwM17LuMVkv1JrFE6lOCtcA=.3c24579b-7244-4caa-bd0c-447879c15952@github.com>
References: <aQDgRwE-H5U0lz8wooLBAQZsuDnB5zZzjMhheIu3y9Y=.0bae7ae4-062e-47de-b7c3-4fedc5d7e20a@github.com>
 <BIDhtI2YAqm9sOWcZX7vweaMXGmK-6v_tPECWHut1xc=.40c48e02-a096-4f9d-929f-69e0fd58f9e5@github.com>
 <PbZQ9H8J5RJFS8ofV__yIPUbkZ_Dvw07mMwi1K0s2zM=.ad5cfaab-240e-40a6-9a33-575458e61787@github.com>
 <zZ5zl-CqYtuZbIlaKdvguxXDE80NmZnOwPfC3qwvNWU=.c77376d7-450b-44e8-98ef-3affdfee05f4@github.com>
 <babHY3358jtnOm5SPSBZqwM17LuMVkv1JrFE6lOCtcA=.3c24579b-7244-4caa-bd0c-447879c15952@github.com>
Message-ID: <BhMCt3b9SLUjdWkmQiNp35gEIaFC4uagfTAlIUmmvAg=.051baa99-65a7-4890-ba5a-233f98216c67@github.com>

On Tue, 10 Sep 2024 21:58:39 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Type template parameters should follow the style guide rules for type names. I've not noticed many (any?) cases of noncompliance.

... other than ConcurrentHashTable (sigh!)

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

PR Comment: https://git.openjdk.org/jdk/pull/20872#issuecomment-2342084599

From wkemper at openjdk.org  Tue Sep 10 23:34:35 2024
From: wkemper at openjdk.org (William Kemper)
Date: Tue, 10 Sep 2024 23:34:35 GMT
Subject: RFR: 8339695: GenShen: Concurrent reset performance has regressed
 [v2]
In-Reply-To: <z64_ZOf3eSRw-WFEqNDNDWhqBiVQ_tubeKXVQHaZKTc=.55ebcfb8-4e18-4c46-a8f9-5ae318938156@github.com>
References: <z64_ZOf3eSRw-WFEqNDNDWhqBiVQ_tubeKXVQHaZKTc=.55ebcfb8-4e18-4c46-a8f9-5ae318938156@github.com>
Message-ID: <avrBMqqpdvRBn1PiDifJGwhuLaDUuB3vcjkk4f0ALKM=.ca2a52c6-b89b-4296-8c03-b693a3ab15ec@github.com>

> A misguided optimization inadvertently increased the time to perform the concurrent reset phase of the GC cycle. This "optimization" has been reverted and the time for the phase has returned to normal.

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

  Fix formatting

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

Changes:
  - all: https://git.openjdk.org/shenandoah/pull/495/files
  - new: https://git.openjdk.org/shenandoah/pull/495/files/bd14ca61..9c9215f4

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

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

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

From wkemper at openjdk.org  Tue Sep 10 23:34:35 2024
From: wkemper at openjdk.org (William Kemper)
Date: Tue, 10 Sep 2024 23:34:35 GMT
Subject: Integrated: 8339695: GenShen: Concurrent reset performance has
 regressed
In-Reply-To: <z64_ZOf3eSRw-WFEqNDNDWhqBiVQ_tubeKXVQHaZKTc=.55ebcfb8-4e18-4c46-a8f9-5ae318938156@github.com>
References: <z64_ZOf3eSRw-WFEqNDNDWhqBiVQ_tubeKXVQHaZKTc=.55ebcfb8-4e18-4c46-a8f9-5ae318938156@github.com>
Message-ID: <JM7NX9rZwMS8fkrSxnChu4Ew-zI0ytFWj4c0D9ilgXw=.b82a66d6-5ced-452a-b9da-5c6aca61b610@github.com>

On Fri, 6 Sep 2024 19:47:50 GMT, William Kemper <wkemper at openjdk.org> wrote:

> A misguided optimization inadvertently increased the time to perform the concurrent reset phase of the GC cycle. This "optimization" has been reverted and the time for the phase has returned to normal.

This pull request has now been integrated.

Changeset: 08c64116
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.org/shenandoah/commit/08c64116f1b604b5e0d3e777b83636753282b435
Stats:     34 lines in 1 file changed: 6 ins; 6 del; 22 mod

8339695: GenShen: Concurrent reset performance has regressed

Reviewed-by: shade

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

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

From ysr at openjdk.org  Wed Sep 11 00:02:30 2024
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Wed, 11 Sep 2024 00:02:30 GMT
Subject: RFR: 8339611: GenShen: Simplify
 ShenandoahOldHeuristics::trigger_collection_if_fragmented [v3]
In-Reply-To: <wQ6Yt5q3w1mBNrQ-8C4C64mP4bcjEEni-r9oej4QfD8=.c7ac6c11-2047-4ed6-bf3b-297a56e61313@github.com>
References: <q3WvOqHO5pxBtaFlO2Ep4ZibIB1nyEPyQ-1to21TqS4=.31ba4e8d-2096-4bb4-aad5-902839638ac9@github.com>
 <wQ6Yt5q3w1mBNrQ-8C4C64mP4bcjEEni-r9oej4QfD8=.c7ac6c11-2047-4ed6-bf3b-297a56e61313@github.com>
Message-ID: <Wi4ge37PYbR3VeuNsu9UG1R7c9e4UUyArRbKD2IaqVc=.4251201b-33b2-400c-9b65-01728a481918@github.com>

On Mon, 9 Sep 2024 20:43:39 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> Replace iterative solution with a single mathematical computation, and adjust old-gen defragmentation efforts to be a bit less aggressive.
>
> Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improve comments and clarify intent of old_region_span

Left a few clean up comments to make it more readable and more easily understandable.

src/hotspot/share/gc/shenandoah/heuristics/shenandoahOldHeuristics.cpp line 552:

> 550: // is required to represent the memory currently used within the old generation.  This trigger looks specifically
> 551: // at density of the old-gen spanned region.  A different mechanism triggers old-gen GC if the total number of
> 552: // old-gen regions (regardless of how close the regions are to one another) grows beyond an anticipated growth target.

I realize this is a private API / work method. Would still be good to place the documentation comment in the .hpp file.


// If the old generation is fragmented, set appropriate collection triggering signals.

src/hotspot/share/gc/shenandoah/heuristics/shenandoahOldHeuristics.cpp line 553:

> 551: // at density of the old-gen spanned region.  A different mechanism triggers old-gen GC if the total number of
> 552: // old-gen regions (regardless of how close the regions are to one another) grows beyond an anticipated growth target.
> 553: void ShenandoahOldHeuristics::trigger_collection_if_fragmented(size_t first_old_region, size_t last_old_region,

I'd name this method `set_fragmentation_trigger()`, with the side-effect that the fragmentation measures are recorded for logging, and associated triggers are set which are used later to start an old cycle.

I'd then rename `trigger_maybe()` to `set_triggers()`, and rename `trigger_collection_if_overgrown()` to `set_growth_trigger()`, etc.

src/hotspot/share/gc/shenandoah/heuristics/shenandoahOldHeuristics.cpp line 558:

> 556:     // Our intent is to pack old-gen memory into the highest-numbered regions of the heap.  Count all memory
> 557:     // above first_old_region as the "span" of old generation.
> 558:     size_t old_region_span = (first_old_region <= last_old_region)? (num_regions - first_old_region): 0;

Can it ever be the case that `first_old_region > last_old_region` ? When can that be the case?

Then, `old_region_span = 0`....

src/hotspot/share/gc/shenandoah/heuristics/shenandoahOldHeuristics.cpp line 573:

> 571:     size_t old_words_consumed = old_region_count * region_size_words - old_fragmented_available;
> 572:     size_t old_words_spanned = old_region_span * region_size_words;
> 573:     double old_density = ((double) old_words_consumed) / old_words_spanned;

... and if `old_region_span = 0`, then you end up with line 573 causing a divide-by-zero error.

src/hotspot/share/gc/shenandoah/heuristics/shenandoahOldHeuristics.cpp line 590:

> 588:       //  old_span_percent is  60% and old_density is below 27.0%, or
> 589:       //  old_span_percent is  50% and old_density is below 18.8%.
> 590:       trigger_old_is_fragmented(old_density, first_old_region, last_old_region);

This method seems a bit useless, why not inline the assignment here? I realize you may be trying to make this method span fewer lines, but I think that can be easily achieved by just moving the description of its work out of line from the code into a block comment at the start that describes how fragmentation is computed and what the trigger threshold criteria are.

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

PR Review: https://git.openjdk.org/shenandoah/pull/492#pullrequestreview-2294311123
PR Review Comment: https://git.openjdk.org/shenandoah/pull/492#discussion_r1752935743
PR Review Comment: https://git.openjdk.org/shenandoah/pull/492#discussion_r1752941163
PR Review Comment: https://git.openjdk.org/shenandoah/pull/492#discussion_r1752945550
PR Review Comment: https://git.openjdk.org/shenandoah/pull/492#discussion_r1752946402
PR Review Comment: https://git.openjdk.org/shenandoah/pull/492#discussion_r1752947994

From ysr at openjdk.org  Wed Sep 11 00:02:30 2024
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Wed, 11 Sep 2024 00:02:30 GMT
Subject: RFR: 8339611: GenShen: Simplify
 ShenandoahOldHeuristics::trigger_collection_if_fragmented [v3]
In-Reply-To: <Wi4ge37PYbR3VeuNsu9UG1R7c9e4UUyArRbKD2IaqVc=.4251201b-33b2-400c-9b65-01728a481918@github.com>
References: <q3WvOqHO5pxBtaFlO2Ep4ZibIB1nyEPyQ-1to21TqS4=.31ba4e8d-2096-4bb4-aad5-902839638ac9@github.com>
 <wQ6Yt5q3w1mBNrQ-8C4C64mP4bcjEEni-r9oej4QfD8=.c7ac6c11-2047-4ed6-bf3b-297a56e61313@github.com>
 <Wi4ge37PYbR3VeuNsu9UG1R7c9e4UUyArRbKD2IaqVc=.4251201b-33b2-400c-9b65-01728a481918@github.com>
Message-ID: <T9lK2U_x-oEgeOEKjOAYpnLZoIqdanYEendbPKqJQYM=.68201ccc-d781-4866-b76f-d02f6dbfcbf3@github.com>

On Tue, 10 Sep 2024 23:37:27 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

>> Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Improve comments and clarify intent of old_region_span
>
> src/hotspot/share/gc/shenandoah/heuristics/shenandoahOldHeuristics.cpp line 552:
> 
>> 550: // is required to represent the memory currently used within the old generation.  This trigger looks specifically
>> 551: // at density of the old-gen spanned region.  A different mechanism triggers old-gen GC if the total number of
>> 552: // old-gen regions (regardless of how close the regions are to one another) grows beyond an anticipated growth target.
> 
> I realize this is a private API / work method. Would still be good to place the documentation comment in the .hpp file.
> 
> 
> // If the old generation is fragmented, set appropriate collection triggering signals.

In this implementation, I'd then describe how the fragmentation is computed.

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

PR Review Comment: https://git.openjdk.org/shenandoah/pull/492#discussion_r1752936273

From ysr at openjdk.org  Wed Sep 11 00:02:30 2024
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Wed, 11 Sep 2024 00:02:30 GMT
Subject: RFR: 8339611: GenShen: Simplify
 ShenandoahOldHeuristics::trigger_collection_if_fragmented [v3]
In-Reply-To: <T9lK2U_x-oEgeOEKjOAYpnLZoIqdanYEendbPKqJQYM=.68201ccc-d781-4866-b76f-d02f6dbfcbf3@github.com>
References: <q3WvOqHO5pxBtaFlO2Ep4ZibIB1nyEPyQ-1to21TqS4=.31ba4e8d-2096-4bb4-aad5-902839638ac9@github.com>
 <wQ6Yt5q3w1mBNrQ-8C4C64mP4bcjEEni-r9oej4QfD8=.c7ac6c11-2047-4ed6-bf3b-297a56e61313@github.com>
 <Wi4ge37PYbR3VeuNsu9UG1R7c9e4UUyArRbKD2IaqVc=.4251201b-33b2-400c-9b65-01728a481918@github.com>
 <T9lK2U_x-oEgeOEKjOAYpnLZoIqdanYEendbPKqJQYM=.68201ccc-d781-4866-b76f-d02f6dbfcbf3@github.com>
Message-ID: <29E4D0A6omnZDjMNSMI9gEkoHIMq-XeY2hBLhg8izAI=.a3b6a5bc-8323-4af8-9766-6e7236af30b8@github.com>

On Tue, 10 Sep 2024 23:38:31 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

>> src/hotspot/share/gc/shenandoah/heuristics/shenandoahOldHeuristics.cpp line 552:
>> 
>>> 550: // is required to represent the memory currently used within the old generation.  This trigger looks specifically
>>> 551: // at density of the old-gen spanned region.  A different mechanism triggers old-gen GC if the total number of
>>> 552: // old-gen regions (regardless of how close the regions are to one another) grows beyond an anticipated growth target.
>> 
>> I realize this is a private API / work method. Would still be good to place the documentation comment in the .hpp file.
>> 
>> 
>> // If the old generation is fragmented, set appropriate collection triggering signals.
>
> In this implementation, I'd then describe how the fragmentation is computed.

Also, I'd avoid using "trigger", and instead say "set_trigger", since the actual collection will happen later, as far as I understand.

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

PR Review Comment: https://git.openjdk.org/shenandoah/pull/492#discussion_r1752936935

From dholmes at openjdk.org  Wed Sep 11 01:06:21 2024
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 11 Sep 2024 01:06:21 GMT
Subject: RFR: 8337563: NMT: rename MEMFLAGS to MemTag
In-Reply-To: <babHY3358jtnOm5SPSBZqwM17LuMVkv1JrFE6lOCtcA=.3c24579b-7244-4caa-bd0c-447879c15952@github.com>
References: <aQDgRwE-H5U0lz8wooLBAQZsuDnB5zZzjMhheIu3y9Y=.0bae7ae4-062e-47de-b7c3-4fedc5d7e20a@github.com>
 <BIDhtI2YAqm9sOWcZX7vweaMXGmK-6v_tPECWHut1xc=.40c48e02-a096-4f9d-929f-69e0fd58f9e5@github.com>
 <PbZQ9H8J5RJFS8ofV__yIPUbkZ_Dvw07mMwi1K0s2zM=.ad5cfaab-240e-40a6-9a33-575458e61787@github.com>
 <zZ5zl-CqYtuZbIlaKdvguxXDE80NmZnOwPfC3qwvNWU=.c77376d7-450b-44e8-98ef-3affdfee05f4@github.com>
 <babHY3358jtnOm5SPSBZqwM17LuMVkv1JrFE6lOCtcA=.3c24579b-7244-4caa-bd0c-447879c15952@github.com>
Message-ID: <H3LxCs7HJQAs1d3p2WiU64b_TFeBevVNt5ZiIzy1OPc=.1f5ad333-15f8-494a-8647-42db8d061fd5@github.com>

On Tue, 10 Sep 2024 21:58:39 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Side note: why are template parameter names all capitals?

I think it is an artifact of them usually being a single letter to represent a Type and thus a capital. But then we sometimes use more than a single-letter and decided to capitalize them all. I don't have an issue with things like MT which can be considered an abbreviation and thus okay to capitalize.

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

PR Comment: https://git.openjdk.org/jdk/pull/20872#issuecomment-2342417399

From kdnilsen at openjdk.org  Wed Sep 11 03:33:24 2024
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Wed, 11 Sep 2024 03:33:24 GMT
Subject: RFR: 8339611: GenShen: Simplify
 ShenandoahOldHeuristics::trigger_collection_if_fragmented [v3]
In-Reply-To: <Wi4ge37PYbR3VeuNsu9UG1R7c9e4UUyArRbKD2IaqVc=.4251201b-33b2-400c-9b65-01728a481918@github.com>
References: <q3WvOqHO5pxBtaFlO2Ep4ZibIB1nyEPyQ-1to21TqS4=.31ba4e8d-2096-4bb4-aad5-902839638ac9@github.com>
 <wQ6Yt5q3w1mBNrQ-8C4C64mP4bcjEEni-r9oej4QfD8=.c7ac6c11-2047-4ed6-bf3b-297a56e61313@github.com>
 <Wi4ge37PYbR3VeuNsu9UG1R7c9e4UUyArRbKD2IaqVc=.4251201b-33b2-400c-9b65-01728a481918@github.com>
Message-ID: <8Vj3caoayL8TGXcD44BOOequarQxRdCRf9f4vYFAN7g=.de2fccd7-1997-4101-8317-70742f1c6bdb@github.com>

On Tue, 10 Sep 2024 23:54:22 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

>> Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Improve comments and clarify intent of old_region_span
>
> src/hotspot/share/gc/shenandoah/heuristics/shenandoahOldHeuristics.cpp line 558:
> 
>> 556:     // Our intent is to pack old-gen memory into the highest-numbered regions of the heap.  Count all memory
>> 557:     // above first_old_region as the "span" of old generation.
>> 558:     size_t old_region_span = (first_old_region <= last_old_region)? (num_regions - first_old_region): 0;
> 
> Can it ever be the case that `first_old_region > last_old_region` ? When can that be the case?
> 
> Then, `old_region_span = 0`....

It happens if there are no old regions, i.e. old-gen is empty.  I'll add comments.  (first_old_region == num_regions and last_old_region == -1 implies empty)

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

PR Review Comment: https://git.openjdk.org/shenandoah/pull/492#discussion_r1753071655

From epeter at openjdk.org  Wed Sep 11 08:28:13 2024
From: epeter at openjdk.org (Emanuel Peter)
Date: Wed, 11 Sep 2024 08:28:13 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v11]
In-Reply-To: <DUgk6HT_Zk5KnbmAd_HzrJi4B8D1J-uuoAGzReWyI8s=.6c04f90a-bf1d-49af-a31d-5224973952d4@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <DUgk6HT_Zk5KnbmAd_HzrJi4B8D1J-uuoAGzReWyI8s=.6c04f90a-bf1d-49af-a31d-5224973952d4@github.com>
Message-ID: <YTte6oY9EeAPHxzzOndL8M202wY91SbeaYC4hPva0W0=.caf00270-89c7-44b0-ab88-a970fb8e840d@github.com>

On Tue, 10 Sep 2024 19:11:30 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> This is the main body of the JEP 450: Compact Object Headers (Experimental).
>> 
>> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing.
>> 
>> Main changes:
>>  - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers.
>>  - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded.
>>  - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops).
>>  - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all).
>>  - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16).
>>  - Arrays will now store their length at offset 8.
>>  - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _co...
>
> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix FullGCForwarding initialization

@rkennke Can you please explain the changes in these tests:

test/hotspot/jtreg/compiler/c2/irTests/TestVectorizationMismatchedAccess.java
test/hotspot/jtreg/compiler/c2/irTests/TestVectorizationNotRun.java
test/hotspot/jtreg/compiler/loopopts/superword/TestAlignVector.java
test/hotspot/jtreg/compiler/loopopts/superword/TestIndependentPacksWithCyclicDependency.java
test/hotspot/jtreg/compiler/loopopts/superword/TestMulAddS2I.java


You added these IR rule restriction:
`@IR(applyIf = {"UseCompactObjectHeaders", "false"},`

This means that if `UseCompactObjectHeaders` is enabled, vectorization seems to be impacted - that could be concerning because it has a performance impact.

I have recently changed a few things in SuperWord, so maybe some of them can be removed, because they now vectorize anyway?

Of course some special tests may just rely on `UseCompactObjectHeaders == false` - but I would need some comments in the tests where you added it to justify why we add the restriction.

Please also test this patch with the cross combinations of `UseCompactObjectHeaders` and `AlignVector` enabled and disabled (and add `VerifyAlignVector` as well).

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

PR Comment: https://git.openjdk.org/jdk/pull/20677#issuecomment-2342983487

From adinn at openjdk.org  Wed Sep 11 08:30:39 2024
From: adinn at openjdk.org (Andrew Dinn)
Date: Wed, 11 Sep 2024 08:30:39 GMT
Subject: RFR: 8339849: Enumerate opto and C1 stubs,generate enums, names,
 fields and generator calls
Message-ID: <gmeZu6egkzf71-hoDOcrK8hql0DJ0rdnAr_D0IcE9tc=.7d9cab12-4009-4cf3-8373-dac7eef9f398@github.com>

Systematize handling of Opto and C1 stubs. Generate enum ids, static fields, stub/blob names and generator code from declarations using template macros as previously done with Shared stubs. Systematically reference stubs and stub names using ids.

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

Commit messages:
 - fix missing include
 - fix problems with enum tags
 - enum fixes
 - correct renaming of patchign ids to stub ids
 - 8339849: Enumerate opto and C1 stubs,generate enums, names, fields and generator calls
 - systematize C1 stubs
 - systematize opto stubs

Changes: https://git.openjdk.org/jdk/pull/20936/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20936&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8339849
  Stats: 997 lines in 44 files changed: 229 ins; 80 del; 688 mod
  Patch: https://git.openjdk.org/jdk/pull/20936.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20936/head:pull/20936

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

From adinn at openjdk.org  Wed Sep 11 08:30:39 2024
From: adinn at openjdk.org (Andrew Dinn)
Date: Wed, 11 Sep 2024 08:30:39 GMT
Subject: RFR: 8339849: Enumerate opto and C1 stubs, generate enums, names, 
 fields and generator calls
In-Reply-To: <gmeZu6egkzf71-hoDOcrK8hql0DJ0rdnAr_D0IcE9tc=.7d9cab12-4009-4cf3-8373-dac7eef9f398@github.com>
References: <gmeZu6egkzf71-hoDOcrK8hql0DJ0rdnAr_D0IcE9tc=.7d9cab12-4009-4cf3-8373-dac7eef9f398@github.com>
Message-ID: <IU5y7i0xu_W9xyvxSDlr41rrZ7g7mgxKO4vR50ruq-c=.bc1c1053-4eba-49ca-b4e3-eaf543ff47ab@github.com>

On Tue, 10 Sep 2024 15:27:09 GMT, Andrew Dinn <adinn at openjdk.org> wrote:

> Systematize handling of Opto and C1 stubs. Generate enum ids, static fields, stub/blob names and generator code from declarations using template macros as previously done with Shared stubs. Systematically reference stubs and stub names using ids.

src/hotspot/share/opto/runtime.cpp line 183:

> 181:   OPTO_STUBS_DO(GEN_OPTO_BLOB, GEN_OPTO_STUB, GEN_OPTO_JVMTI_STUB)
> 182: 
> 183:     /*

This old code that has been commented out needs to be removed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20936#discussion_r1753581414

From adinn at openjdk.org  Wed Sep 11 08:41:09 2024
From: adinn at openjdk.org (Andrew Dinn)
Date: Wed, 11 Sep 2024 08:41:09 GMT
Subject: RFR: 8339849: Enumerate opto and C1 stubs, generate enums, names, 
 fields and generator calls
In-Reply-To: <gmeZu6egkzf71-hoDOcrK8hql0DJ0rdnAr_D0IcE9tc=.7d9cab12-4009-4cf3-8373-dac7eef9f398@github.com>
References: <gmeZu6egkzf71-hoDOcrK8hql0DJ0rdnAr_D0IcE9tc=.7d9cab12-4009-4cf3-8373-dac7eef9f398@github.com>
Message-ID: <WG5bj7qJ9ZROdV1L8borG0SX7Ue0ucq4DGW19p0lug4=.211ffa2c-89df-45e6-88a5-50eb2f4b03eb@github.com>

On Tue, 10 Sep 2024 15:27:09 GMT, Andrew Dinn <adinn at openjdk.org> wrote:

> Systematize handling of Opto and C1 stubs. Generate enum ids, static fields, stub/blob names and generator code from declarations using template macros as previously done with Shared stubs. Systematically reference stubs and stub names using ids.

src/hotspot/share/opto/runtime.cpp line 151:

> 149: // defines temporarily rebind the generated names to reference the
> 150: // relevant implementations.
> 151: 

I am not 100% happy about using defines to finesse this problem of common C targets.

One alternative here is to define methods local to class OptoRuntime which fit the generator naming convention and have them forward the call to the SharedRuntime methods. n.b. I used (local) method forwarding to allow blobs to share common typefunc providers.

Another alternative is to declare the C target as a parameter to the opto blob declaration macro. That's more flexible but in almost all cases it repeats information already present and makes understanding and updating the declarations more complex.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20936#discussion_r1753617986

From rkennke at openjdk.org  Wed Sep 11 13:37:16 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Wed, 11 Sep 2024 13:37:16 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v11]
In-Reply-To: <YTte6oY9EeAPHxzzOndL8M202wY91SbeaYC4hPva0W0=.caf00270-89c7-44b0-ab88-a970fb8e840d@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <DUgk6HT_Zk5KnbmAd_HzrJi4B8D1J-uuoAGzReWyI8s=.6c04f90a-bf1d-49af-a31d-5224973952d4@github.com>
 <YTte6oY9EeAPHxzzOndL8M202wY91SbeaYC4hPva0W0=.caf00270-89c7-44b0-ab88-a970fb8e840d@github.com>
Message-ID: <kzodWwxj5qdAqPYcP2s4k2QTXqjju2H6Iftu7dojezk=.1f72fc31-94ba-4017-b330-c8688a8d39a4@github.com>

On Wed, 11 Sep 2024 08:24:16 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

> @rkennke Can you please explain the changes in these tests:
> 
> ```
> test/hotspot/jtreg/compiler/c2/irTests/TestVectorizationMismatchedAccess.java
> test/hotspot/jtreg/compiler/c2/irTests/TestVectorizationNotRun.java
> test/hotspot/jtreg/compiler/loopopts/superword/TestAlignVector.java
> test/hotspot/jtreg/compiler/loopopts/superword/TestIndependentPacksWithCyclicDependency.java
> test/hotspot/jtreg/compiler/loopopts/superword/TestMulAddS2I.java
> ```
> 
> You added these IR rule restriction: `@IR(applyIf = {"UseCompactObjectHeaders", "false"},`
> 
> This means that if `UseCompactObjectHeaders` is enabled, vectorization seems to be impacted - that could be concerning because it has a performance impact.
> 
> I have recently changed a few things in SuperWord, so maybe some of them can be removed, because they now vectorize anyway?
> 
> Of course some special tests may just rely on `UseCompactObjectHeaders == false` - but I would need some comments in the tests where you added it to justify why we add the restriction.
> 
> Please also test this patch with the cross combinations of `UseCompactObjectHeaders` and `AlignVector` enabled and disabled (and add `VerifyAlignVector` as well).

IIRC (it has been a while), the problem is that with Lilliput (and also without compact headers, but disabling compressed class-pointers -UseCompressedClassPointers, but nobody ever does that), byte[] and long[] start at different offsets (12 and 16, respectively). That is because with compact headers, we are using the 4 bytes after the arraylength, but long-arrays cannot do that because of alignment constraints. The impact is that these tests don't work as expected, because vectorization triggers differently. I don't remember the details, TBH, but I believe they would now generate pre-loops, or some might even not vectorize at all. Those seemed to be use-cases that did not look very important, but I may be wrong. It would be nice to properly fix those tests, or make corresponding tests for compact headers, instead, or improve vectorization to better deal with the offset mismatch, if necessary/possible.

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

PR Comment: https://git.openjdk.org/jdk/pull/20677#issuecomment-2343693629

From jsjolen at openjdk.org  Wed Sep 11 14:00:17 2024
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Wed, 11 Sep 2024 14:00:17 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v11]
In-Reply-To: <DUgk6HT_Zk5KnbmAd_HzrJi4B8D1J-uuoAGzReWyI8s=.6c04f90a-bf1d-49af-a31d-5224973952d4@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <DUgk6HT_Zk5KnbmAd_HzrJi4B8D1J-uuoAGzReWyI8s=.6c04f90a-bf1d-49af-a31d-5224973952d4@github.com>
Message-ID: <b8u6PaStO4nt0AGnbZEkmXkzQKzXaB2c4lSiC9JWdTY=.a5805ef2-84d8-44c0-9dc0-3e90da3460aa@github.com>

On Tue, 10 Sep 2024 19:11:30 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> This is the main body of the JEP 450: Compact Object Headers (Experimental).
>> 
>> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing.
>> 
>> Main changes:
>>  - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers.
>>  - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded.
>>  - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops).
>>  - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all).
>>  - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16).
>>  - Arrays will now store their length at offset 8.
>>  - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _co...
>
> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix FullGCForwarding initialization

Hi,

Me and @caspernorrbin are reviewing the Metaspace changes (so anything in the `memory` and `metaspace` folders). We have found minor improvements that can be made and some nits, but the code over all looks OK. We are finishing up a first round of review now, and will have a second one.

Thank you for your hard work and your patience with the review process.

src/hotspot/share/memory/classLoaderMetaspace.cpp line 87:

> 85:         klass_alignment_words,
> 86:         "class arena");
> 87:   }

As per my comment in the header file, change the code to this:

```c++
if (class_context != nullptr) {
  // ... Same as in PR
} else {
  _class_space_arena = _non_class_space_arena;
}

src/hotspot/share/memory/classLoaderMetaspace.cpp line 115:

> 113:   if (wastage.is_nonempty()) {
> 114:     non_class_space_arena()->deallocate(wastage);
> 115:   }

This code reads a bit strangely. I understand *what* it tries to do. It tries to give back any wasted memory from either the class space arena *or* the non class space arena to the non class space arena's freelist. I assume that we do this since any wastage is presumably too small to be used by our new 22-bit class pointers. However, this context will be lost on future readers. It should have at least a comment in the `if (wastage.is_nonempty())` clause explaining what we expect should happen and why. For example:

```c++
// Any wasted memory is presumably too small for any class.
// Therefore, give it back to the non-class space arena's free list.

src/hotspot/share/memory/classLoaderMetaspace.cpp line 118:

> 116: #ifdef ASSERT
> 117:   if (result.is_nonempty()) {
> 118:     const bool in_class_arena = class_space_arena() != nullptr ? class_space_arena()->contains(result) : false;

Unnecessary nullptr check if you take my suggestion, or you should switch to `have_class_space_arena`.

src/hotspot/share/memory/classLoaderMetaspace.cpp line 165:

> 163:   MetaBlock bl(ptr, word_size);
> 164:   // If the block would be reusable for a Klass, add to class arena, otherwise to
> 165:   // then non-class arena.

Nit: spelling, "the"

src/hotspot/share/memory/classLoaderMetaspace.hpp line 81:

> 79:   metaspace::MetaspaceArena* class_space_arena() const       { return _class_space_arena; }
> 80: 
> 81:   bool have_class_space_arena() const { return _class_space_arena != nullptr; }

This is unnecessary. Instead of having this and having to remember to check for nullness each time, just change the `_class_space_arena` to point to the same arena as the `_non_class_space_arena` does when we run with `-XX:-UseCompressedClassPointers`

src/hotspot/share/memory/metaspace.cpp line 656:

> 654:     // Adjust size of the compressed class space.
> 655: 
> 656:     const size_t res_align = reserve_alignment();

Can you change the name to `root_chunk_size`?

src/hotspot/share/memory/metaspace.hpp line 112:

> 110:   static size_t max_allocation_word_size();
> 111: 
> 112:   // Minimum allocation alignment, in bytes. All MetaData shall be aligned correclty

Nit: Spelling, "correctly"

src/hotspot/share/memory/metaspace/metablock.hpp line 48:

> 46: 
> 47:   MetaWord* base() const { return _base; }
> 48:   const MetaWord* end() const { return _base + _word_size; }

`assert(is_nonempty())`

src/hotspot/share/memory/metaspace/metablock.hpp line 51:

> 49:   size_t word_size() const { return _word_size; }
> 50:   bool is_empty() const { return _base == nullptr; }
> 51:   bool is_nonempty() const { return _base != nullptr; }

Can `_base == nullptr` but `_word_size != 0`?

src/hotspot/share/memory/metaspace/metablock.hpp line 52:

> 50:   bool is_empty() const { return _base == nullptr; }
> 51:   bool is_nonempty() const { return _base != nullptr; }
> 52:   void reset() { _base = nullptr; _word_size = 0; }

Is this function really necessary? According to my IDE it's only used in tests and even then the `MetaBlock` isn't used afterwards (so it has no effect).

src/hotspot/share/memory/metaspace/metaspaceArena.hpp line 44:

> 42: class FreeBlocks;
> 43: 
> 44: struct ArenaStats;

Nit: Sort?

src/hotspot/share/memory/metaspace/metaspaceArena.hpp line 84:

> 82:   // between threads and needs to be synchronized in CLMS.
> 83: 
> 84:   const size_t _allocation_alignment_words;

Nit: Document this? All other members are documented.

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

PR Review: https://git.openjdk.org/jdk/pull/20677#pullrequestreview-2296528491
PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1754335269
PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1754398993
PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1754343513
PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1754459464
PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1754330432
PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1754619023
PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1754508321
PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1754142822
PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1754142098
PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1754153662
PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1754192464
PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1754197251

From gziemski at openjdk.org  Wed Sep 11 14:06:06 2024
From: gziemski at openjdk.org (Gerard Ziemski)
Date: Wed, 11 Sep 2024 14:06:06 GMT
Subject: RFR: 8337563: NMT: rename MEMFLAGS to MemTag [v7]
In-Reply-To: <XNRFNQoz26gPhgG5XSzcbcYiC0RlNv6MPdNI1K1hlkI=.f4bd698b-e546-440f-8c50-b8af375526e5@github.com>
References: <aQDgRwE-H5U0lz8wooLBAQZsuDnB5zZzjMhheIu3y9Y=.0bae7ae4-062e-47de-b7c3-4fedc5d7e20a@github.com>
 <XNRFNQoz26gPhgG5XSzcbcYiC0RlNv6MPdNI1K1hlkI=.f4bd698b-e546-440f-8c50-b8af375526e5@github.com>
Message-ID: <ZNoKx37DAFcCS1LgNn4wQO7kwWa16mSfODJKuFcHUl4=.05a1cc8d-f189-4554-8bc0-45744c7aa000@github.com>

On Tue, 10 Sep 2024 20:53:46 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

>> Please review this cleanup, where we rename `MEMFLAGS` to `MemTag`.
>> 
>> `MEMFLAGS` implies that we can use more than one at the same time, but those are exclusive values, so `MemTag` is a more suitable name.
>> 
>> This fix also includes a cleanup of all the related function/template parameter names and local variable names.
>> 
>> Testing is pending...
>> 
>> Note: there is more history in old closed PRs [https://github.com/openjdk/jdk/pull/20497](https://github.com/openjdk/jdk/pull/20497) and [https://github.com/openjdk/jdk/pull/20472](https://github.com/openjdk/jdk/pull/20472)
>
> Gerard Ziemski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Coleen's feedback

Are we sure we want `mt` for non-type parameter name in templates? We have these existing patterns already in our code:


src/hotspot/share/utilities/growableArray.hpp:803:template <typename E, MemTag MT>
src/hotspot/share/utilities/stack.hpp:54:template <class E, MemTag MT> class StackIterator;
src/hotspot/share/utilities/concurrentHashTable.inline.hpp:78:template <typename CONFIG, MemTag MT>
src/hotspot/share/utilities/chunkedList.hpp:31:template <class T, MemTag MT> class ChunkedList : public CHeapObj<MT> 
src/hotspot/share/gc/g1/g1BatchedTask.hpp:32:template <typename E, MemTag MT>
src/hotspot/share/gc/shared/taskqueue.hpp:119:template <unsigned int N, MemTag MT>
src/hotspot/share/gc/shared/taskqueue.hpp:327:template <class E, MemTag MT, unsigned int N = TASKQUEUE_SIZE>
src/hotspot/share/gc/shenandoah/shenandoahTaskqueue.hpp:40:template<class E, MemTag MT, unsigned int N = TASKQUEUE_SIZE>
src/hotspot/share/nmt/arrayWithFreeList.hpp:34:template<typename E, MemTag MT>


With mt they would look like:


src/hotspot/share/utilities/growableArray.hpp:803:template <typename E, MemTag mt>
src/hotspot/share/utilities/stack.hpp:54:template <class E, MemTag mt> class StackIterator;
src/hotspot/share/utilities/concurrentHashTable.inline.hpp:78:template <typename CONFIG, MemTag mt>
src/hotspot/share/utilities/chunkedList.hpp:31:template <class T, MemTag mt> class ChunkedList : public CHeapObj<mt> 
src/hotspot/share/gc/g1/g1BatchedTask.hpp:32:template <typename E, MemTag mt>
src/hotspot/share/gc/shared/taskqueue.hpp:119:template <unsigned int N, MemTag mt>
src/hotspot/share/gc/shared/taskqueue.hpp:327:template <class E, MemTag mt, unsigned int N = TASKQUEUE_SIZE>
src/hotspot/share/gc/shenandoah/shenandoahTaskqueue.hpp:40:template<class E, MemTag mt, unsigned int N = TASKQUEUE_SIZE>
src/hotspot/share/nmt/arrayWithFreeList.hpp:34:template<typename E, MemTag mt>


So `MT` or `mt` for non-type parameter name in templates, or should I punt on this particular change and leave it for a followup?

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

PR Comment: https://git.openjdk.org/jdk/pull/20872#issuecomment-2343769766

From epeter at openjdk.org  Wed Sep 11 14:17:16 2024
From: epeter at openjdk.org (Emanuel Peter)
Date: Wed, 11 Sep 2024 14:17:16 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v11]
In-Reply-To: <kzodWwxj5qdAqPYcP2s4k2QTXqjju2H6Iftu7dojezk=.1f72fc31-94ba-4017-b330-c8688a8d39a4@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <DUgk6HT_Zk5KnbmAd_HzrJi4B8D1J-uuoAGzReWyI8s=.6c04f90a-bf1d-49af-a31d-5224973952d4@github.com>
 <YTte6oY9EeAPHxzzOndL8M202wY91SbeaYC4hPva0W0=.caf00270-89c7-44b0-ab88-a970fb8e840d@github.com>
 <kzodWwxj5qdAqPYcP2s4k2QTXqjju2H6Iftu7dojezk=.1f72fc31-94ba-4017-b330-c8688a8d39a4@github.com>
Message-ID: <oLLd3DTbo5HtVFxXEyY-SSiwwJe6n5q5YMvoSf6xiEE=.6c18ec11-9e51-4635-84e7-5a56e47b0445@github.com>

On Wed, 11 Sep 2024 13:34:28 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> > @rkennke Can you please explain the changes in these tests:
> > ```
> > test/hotspot/jtreg/compiler/c2/irTests/TestVectorizationMismatchedAccess.java
> > test/hotspot/jtreg/compiler/c2/irTests/TestVectorizationNotRun.java
> > test/hotspot/jtreg/compiler/loopopts/superword/TestAlignVector.java
> > test/hotspot/jtreg/compiler/loopopts/superword/TestIndependentPacksWithCyclicDependency.java
> > test/hotspot/jtreg/compiler/loopopts/superword/TestMulAddS2I.java
> > ```
> > 
> > 
> >     
> >       
> >     
> > 
> >       
> >     
> > 
> >     
> >   
> > You added these IR rule restriction: `@IR(applyIf = {"UseCompactObjectHeaders", "false"},`
> > This means that if `UseCompactObjectHeaders` is enabled, vectorization seems to be impacted - that could be concerning because it has a performance impact.
> > I have recently changed a few things in SuperWord, so maybe some of them can be removed, because they now vectorize anyway?
> > Of course some special tests may just rely on `UseCompactObjectHeaders == false` - but I would need some comments in the tests where you added it to justify why we add the restriction.
> > Please also test this patch with the cross combinations of `UseCompactObjectHeaders` and `AlignVector` enabled and disabled (and add `VerifyAlignVector` as well).
> 
> IIRC (it has been a while), the problem is that with Lilliput (and also without compact headers, but disabling compressed class-pointers -UseCompressedClassPointers, but nobody ever does that), byte[] and long[] start at different offsets (12 and 16, respectively). That is because with compact headers, we are using the 4 bytes after the arraylength, but long-arrays cannot do that because of alignment constraints. The impact is that these tests don't work as expected, because vectorization triggers differently. I don't remember the details, TBH, but I believe they would now generate pre-loops, or some might even not vectorize at all. Those seemed to be use-cases that did not look very important, but I may be wrong. It would be nice to properly fix those tests, or make corresponding tests for compact headers, instead, or improve vectorization to better deal with the offset mismatch, if necessary/possible.
> 
> I will re-evaluate those tests, and add comments or remove the restrictions.

If it has indeed been a while, then it might well be that some of them work now, since I did make some improvements to auto-vectorization ;)

My suggestion is this: go over the examples, check which ones are now ok. Those that are not ok, add a comment, and file a bug: I can then analyze those cases later, and see how to write other tests or improve auto-vectorization.

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

PR Comment: https://git.openjdk.org/jdk/pull/20677#issuecomment-2343797957

From rcastanedalo at openjdk.org  Wed Sep 11 14:17:17 2024
From: rcastanedalo at openjdk.org (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Wed, 11 Sep 2024 14:17:17 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v11]
In-Reply-To: <DUgk6HT_Zk5KnbmAd_HzrJi4B8D1J-uuoAGzReWyI8s=.6c04f90a-bf1d-49af-a31d-5224973952d4@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <DUgk6HT_Zk5KnbmAd_HzrJi4B8D1J-uuoAGzReWyI8s=.6c04f90a-bf1d-49af-a31d-5224973952d4@github.com>
Message-ID: <blSYjm8E4iTDbxev4YGU8sm0EFE-dNa87oQYNzneLD8=.9bdad535-f503-443c-b3e6-26899e72b2a7@github.com>

On Tue, 10 Sep 2024 19:11:30 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> This is the main body of the JEP 450: Compact Object Headers (Experimental).
>> 
>> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing.
>> 
>> Main changes:
>>  - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers.
>>  - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded.
>>  - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops).
>>  - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all).
>>  - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16).
>>  - Arrays will now store their length at offset 8.
>>  - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _co...
>
> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix FullGCForwarding initialization

src/hotspot/share/memory/metaspace/binList.hpp line 202:

> 200:         b_last = b;
> 201:       }
> 202:       if (UseNewCode)printf("\n");

I guess this line is a leftover to be removed?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1754702742

From rcastanedalo at openjdk.org  Wed Sep 11 14:50:17 2024
From: rcastanedalo at openjdk.org (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Wed, 11 Sep 2024 14:50:17 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v11]
In-Reply-To: <DUgk6HT_Zk5KnbmAd_HzrJi4B8D1J-uuoAGzReWyI8s=.6c04f90a-bf1d-49af-a31d-5224973952d4@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <DUgk6HT_Zk5KnbmAd_HzrJi4B8D1J-uuoAGzReWyI8s=.6c04f90a-bf1d-49af-a31d-5224973952d4@github.com>
Message-ID: <GQVVR0K-mDh4evKvrKG9eXwwF4j7zAg-8ai4__gWNGE=.3c502820-717b-44b7-b82d-a24dd7fdd9d5@github.com>

On Tue, 10 Sep 2024 19:11:30 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> This is the main body of the JEP 450: Compact Object Headers (Experimental).
>> 
>> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing.
>> 
>> Main changes:
>>  - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers.
>>  - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded.
>>  - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops).
>>  - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all).
>>  - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16).
>>  - Arrays will now store their length at offset 8.
>>  - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _co...
>
> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix FullGCForwarding initialization

src/hotspot/share/opto/machnode.cpp line 390:

> 388:     t = t->make_ptr();
> 389:   }
> 390:   if (t->isa_narrowklass() && CompressedKlassPointers::shift() == 0) {

Does this change have any effect? `UseCompressedClassPointers` should be implied by `t->isa_narrowklass()`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1754813751

From stefank at openjdk.org  Wed Sep 11 15:43:06 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Wed, 11 Sep 2024 15:43:06 GMT
Subject: RFR: 8337563: NMT: rename MEMFLAGS to MemTag
In-Reply-To: <H3LxCs7HJQAs1d3p2WiU64b_TFeBevVNt5ZiIzy1OPc=.1f5ad333-15f8-494a-8647-42db8d061fd5@github.com>
References: <aQDgRwE-H5U0lz8wooLBAQZsuDnB5zZzjMhheIu3y9Y=.0bae7ae4-062e-47de-b7c3-4fedc5d7e20a@github.com>
 <BIDhtI2YAqm9sOWcZX7vweaMXGmK-6v_tPECWHut1xc=.40c48e02-a096-4f9d-929f-69e0fd58f9e5@github.com>
 <PbZQ9H8J5RJFS8ofV__yIPUbkZ_Dvw07mMwi1K0s2zM=.ad5cfaab-240e-40a6-9a33-575458e61787@github.com>
 <zZ5zl-CqYtuZbIlaKdvguxXDE80NmZnOwPfC3qwvNWU=.c77376d7-450b-44e8-98ef-3affdfee05f4@github.com>
 <babHY3358jtnOm5SPSBZqwM17LuMVkv1JrFE6lOCtcA=.3c24579b-7244-4caa-bd0c-447879c15952@github.com>
 <H3LxCs7HJQAs1d3p2WiU64b_TFeBevVNt5ZiIzy1OPc=.1f5ad333-15f8-494a-8647-42db8d061fd5@github.com>
Message-ID: <HWRF9TEr6058xwZnBTWWMmWqCThQKVeTvwWEB3YC4Lc=.127f2f67-3cde-460c-88f8-9cbb38801399@github.com>

On Wed, 11 Sep 2024 01:03:55 GMT, David Holmes <dholmes at openjdk.org> wrote:

> EDIT: Oh dear. I see I have been under a misapprehension about these template parameters, I tend to always thing such things are type parameters but they are not. MT would make sense for a type parameter, but mt would be more sensible for a non-type parameter. The fact the original was F threw me.

I mean, it is still effectively a constant so using CamelCase (or an upper-case abbreviation) isn't really that weird for non-type template parameters, IMHO.

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

PR Comment: https://git.openjdk.org/jdk/pull/20872#issuecomment-2344023396

From coleenp at openjdk.org  Wed Sep 11 16:00:08 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 11 Sep 2024 16:00:08 GMT
Subject: RFR: 8337563: NMT: rename MEMFLAGS to MemTag [v7]
In-Reply-To: <XNRFNQoz26gPhgG5XSzcbcYiC0RlNv6MPdNI1K1hlkI=.f4bd698b-e546-440f-8c50-b8af375526e5@github.com>
References: <aQDgRwE-H5U0lz8wooLBAQZsuDnB5zZzjMhheIu3y9Y=.0bae7ae4-062e-47de-b7c3-4fedc5d7e20a@github.com>
 <XNRFNQoz26gPhgG5XSzcbcYiC0RlNv6MPdNI1K1hlkI=.f4bd698b-e546-440f-8c50-b8af375526e5@github.com>
Message-ID: <V2pDRBhkbW5LmtpzTgdSlY8t93EV7lnX87KK5NGNULQ=.4952d9da-e411-42b7-bfdf-eb08680a6d04@github.com>

On Tue, 10 Sep 2024 20:53:46 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

>> Please review this cleanup, where we rename `MEMFLAGS` to `MemTag`.
>> 
>> `MEMFLAGS` implies that we can use more than one at the same time, but those are exclusive values, so `MemTag` is a more suitable name.
>> 
>> This fix also includes a cleanup of all the related function/template parameter names and local variable names.
>> 
>> Testing is pending...
>> 
>> Note: there is more history in old closed PRs [https://github.com/openjdk/jdk/pull/20497](https://github.com/openjdk/jdk/pull/20497) and [https://github.com/openjdk/jdk/pull/20472](https://github.com/openjdk/jdk/pull/20472)
>
> Gerard Ziemski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Coleen's feedback

No, please use capital MT so it's easy to see it's a template parameter!

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

PR Comment: https://git.openjdk.org/jdk/pull/20872#issuecomment-2344060946

From stuefe at openjdk.org  Wed Sep 11 16:17:16 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Wed, 11 Sep 2024 16:17:16 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v11]
In-Reply-To: <b8u6PaStO4nt0AGnbZEkmXkzQKzXaB2c4lSiC9JWdTY=.a5805ef2-84d8-44c0-9dc0-3e90da3460aa@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <DUgk6HT_Zk5KnbmAd_HzrJi4B8D1J-uuoAGzReWyI8s=.6c04f90a-bf1d-49af-a31d-5224973952d4@github.com>
 <b8u6PaStO4nt0AGnbZEkmXkzQKzXaB2c4lSiC9JWdTY=.a5805ef2-84d8-44c0-9dc0-3e90da3460aa@github.com>
Message-ID: <heQmg7wA6Yrt25T08k27pNGDJ_FAI0c3aGNuqNWt7Qk=.f01b3868-bd28-4635-a3b8-618e93880a91@github.com>

On Wed, 11 Sep 2024 12:47:30 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix FullGCForwarding initialization
>
> src/hotspot/share/memory/classLoaderMetaspace.cpp line 115:
> 
>> 113:   if (wastage.is_nonempty()) {
>> 114:     non_class_space_arena()->deallocate(wastage);
>> 115:   }
> 
> This code reads a bit strangely. I understand *what* it tries to do. It tries to give back any wasted memory from either the class space arena *or* the non class space arena to the non class space arena's freelist. I assume that we do this since any wastage is presumably too small to be used by our new 22-bit class pointers. However, this context will be lost on future readers. It should have at least a comment in the `if (wastage.is_nonempty())` clause explaining what we expect should happen and why. For example:
> 
> ```c++
> // Any wasted memory is presumably too small for any class.
> // Therefore, give it back to the non-class space arena's free list.

Yes. Some background:

- wastage can only occur for larger Klass* alignments (aka class space arena alignment property), so only for +COH (note to self, maybe assert)
- wastage is, by definition, not aligned to the required Klass* alignment, so it cannot be reused. Yes, its probably also too small

Yes, I will write a better comment.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1755111131

From stuefe at openjdk.org  Wed Sep 11 16:17:16 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Wed, 11 Sep 2024 16:17:16 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v11]
In-Reply-To: <blSYjm8E4iTDbxev4YGU8sm0EFE-dNa87oQYNzneLD8=.9bdad535-f503-443c-b3e6-26899e72b2a7@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <DUgk6HT_Zk5KnbmAd_HzrJi4B8D1J-uuoAGzReWyI8s=.6c04f90a-bf1d-49af-a31d-5224973952d4@github.com>
 <blSYjm8E4iTDbxev4YGU8sm0EFE-dNa87oQYNzneLD8=.9bdad535-f503-443c-b3e6-26899e72b2a7@github.com>
Message-ID: <y70DRIqSP00J6AsD0qAUV3Mn6XgMkMzu4s7ZkO2OqZk=.519190f4-7e32-4351-965b-9aaf8781316a@github.com>

On Wed, 11 Sep 2024 14:15:12 GMT, Roberto Casta?eda Lozano <rcastanedalo at openjdk.org> wrote:

>> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix FullGCForwarding initialization
>
> src/hotspot/share/memory/metaspace/binList.hpp line 202:
> 
>> 200:         b_last = b;
>> 201:       }
>> 202:       if (UseNewCode)printf("\n");
> 
> I guess this line is a leftover to be removed?

Yep thanks for spotting

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1755115905

From stuefe at openjdk.org  Wed Sep 11 16:17:17 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Wed, 11 Sep 2024 16:17:17 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v11]
In-Reply-To: <y70DRIqSP00J6AsD0qAUV3Mn6XgMkMzu4s7ZkO2OqZk=.519190f4-7e32-4351-965b-9aaf8781316a@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <DUgk6HT_Zk5KnbmAd_HzrJi4B8D1J-uuoAGzReWyI8s=.6c04f90a-bf1d-49af-a31d-5224973952d4@github.com>
 <blSYjm8E4iTDbxev4YGU8sm0EFE-dNa87oQYNzneLD8=.9bdad535-f503-443c-b3e6-26899e72b2a7@github.com>
 <y70DRIqSP00J6AsD0qAUV3Mn6XgMkMzu4s7ZkO2OqZk=.519190f4-7e32-4351-965b-9aaf8781316a@github.com>
Message-ID: <iLETzB3HhQYtpUGFtQ7MQs8_v-US_YxsaOGNrXS7tE8=.d5301449-6481-4af6-b238-bc717831adf9@github.com>

On Wed, 11 Sep 2024 16:14:39 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> src/hotspot/share/memory/metaspace/binList.hpp line 202:
>> 
>>> 200:         b_last = b;
>>> 201:       }
>>> 202:       if (UseNewCode)printf("\n");
>> 
>> I guess this line is a leftover to be removed?
>
> Yep thanks for spotting

So that was causing the empty lines in my logs (facepalm)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1755116656

From wkemper at openjdk.org  Wed Sep 11 16:32:02 2024
From: wkemper at openjdk.org (William Kemper)
Date: Wed, 11 Sep 2024 16:32:02 GMT
Subject: RFR: 8339870: Remove yet more stale TODOs [v2]
In-Reply-To: <R2zLMF_H62csd-NyxcVPsR9BaqxKlS8t6llk4_p6_hI=.77d6a2aa-6d10-4c6d-8582-ae37dbd78d5f@github.com>
References: <R2zLMF_H62csd-NyxcVPsR9BaqxKlS8t6llk4_p6_hI=.77d6a2aa-6d10-4c6d-8582-ae37dbd78d5f@github.com>
Message-ID: <pbsvXJqFs_FGxlYrA1b8wSU12akLGv7-Z3kH-fsamPA=.dc496714-e723-4b10-9bbb-b40546b527d6@github.com>

> Final round of TODO removal.
> * Move asterisk for pointer next to type, not variable
> * Remembered set verifier uses a small 'scanner' abstraction to simplify reading of read or write card table
> 
> ## Testing
> 
> GHA, Internal pipelines

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

  Move rset scan TODOs into ticket

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

Changes:
  - all: https://git.openjdk.org/shenandoah/pull/496/files
  - new: https://git.openjdk.org/shenandoah/pull/496/files/8719ba9d..135cc5ec

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

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

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

From kdnilsen at openjdk.org  Wed Sep 11 16:46:35 2024
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Wed, 11 Sep 2024 16:46:35 GMT
Subject: RFR: 8339960: GenShen: Fix inconsistencies in generational Shenandoah
 behavior
Message-ID: <jgNu9Ijgc-5vBhFQrcRy-y14tffgH1sqAHlI8byFOJg=.8be61718-9d62-45f3-b55a-375da8ecea54@github.com>

This fixes some bugs found in recent code review and playback of an assertion failure.

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

Commit messages:
 - Use -1 to represent rightmost for empty partitions in find_regions_with_alloc_capacity()
 - Report generation resize and clear region_balance in ShenFreeSet::finish_rebuild()
 - Check available rather than capacity before logging insufficient reserves
 - initialize rightmosts to -1 in find_regions_with_alloc_capacity()
 - Merge branch 'openjdk:master' into master
 - Merge branch 'openjdk:master' into master
 - Merge branch 'openjdk:master' into master
 - Merge branch 'openjdk:master' into master
 - Merge branch 'openjdk:master' into master
 - Merge branch 'openjdk:master' into master
 - ... and 16 more: https://git.openjdk.org/shenandoah/compare/662d146d...e78c7b0d

Changes: https://git.openjdk.org/shenandoah/pull/497/files
  Webrev: https://webrevs.openjdk.org/?repo=shenandoah&pr=497&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8339960
  Stats: 28 lines in 1 file changed: 20 ins; 0 del; 8 mod
  Patch: https://git.openjdk.org/shenandoah/pull/497.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah.git pull/497/head:pull/497

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

From wkemper at openjdk.org  Wed Sep 11 16:46:35 2024
From: wkemper at openjdk.org (William Kemper)
Date: Wed, 11 Sep 2024 16:46:35 GMT
Subject: RFR: 8339960: GenShen: Fix inconsistencies in generational
 Shenandoah behavior
In-Reply-To: <jgNu9Ijgc-5vBhFQrcRy-y14tffgH1sqAHlI8byFOJg=.8be61718-9d62-45f3-b55a-375da8ecea54@github.com>
References: <jgNu9Ijgc-5vBhFQrcRy-y14tffgH1sqAHlI8byFOJg=.8be61718-9d62-45f3-b55a-375da8ecea54@github.com>
Message-ID: <eBdgoNx_fVyiNHmLqHqDkOx-ScPtTwZeM2KNNEXnFkc=.337aabbc-4191-4b82-9db2-14cffb783288@github.com>

On Wed, 11 Sep 2024 16:25:43 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

> This fixes some bugs found in recent code review and playback of an assertion failure.

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

> 1426:                 old_collector_regions, old_collector_used);
> 1427: 
> 1428:   idx_t rightmost_idx = (mutator_leftmost == max_regions)? -1: (idx_t) mutator_rightmost;

Does this also affect upstream? Should we have a non-genshen patch too?

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

PR Review Comment: https://git.openjdk.org/shenandoah/pull/497#discussion_r1755142460

From kdnilsen at openjdk.org  Wed Sep 11 16:46:35 2024
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Wed, 11 Sep 2024 16:46:35 GMT
Subject: RFR: 8339960: GenShen: Fix inconsistencies in generational
 Shenandoah behavior
In-Reply-To: <eBdgoNx_fVyiNHmLqHqDkOx-ScPtTwZeM2KNNEXnFkc=.337aabbc-4191-4b82-9db2-14cffb783288@github.com>
References: <jgNu9Ijgc-5vBhFQrcRy-y14tffgH1sqAHlI8byFOJg=.8be61718-9d62-45f3-b55a-375da8ecea54@github.com>
 <eBdgoNx_fVyiNHmLqHqDkOx-ScPtTwZeM2KNNEXnFkc=.337aabbc-4191-4b82-9db2-14cffb783288@github.com>
Message-ID: <nkTG6LMW3beBVR1J7gAsmKFULB9tbjfvq_5AqgC2Cyc=.5272fcd5-1c94-48eb-bb80-c606662d81a9@github.com>

On Wed, 11 Sep 2024 16:33:08 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> This fixes some bugs found in recent code review and playback of an assertion failure.
>
> src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp line 1428:
> 
>> 1426:                 old_collector_regions, old_collector_used);
>> 1427: 
>> 1428:   idx_t rightmost_idx = (mutator_leftmost == max_regions)? -1: (idx_t) mutator_rightmost;
> 
> Does this also affect upstream? Should we have a non-genshen patch too?

We should do this upstream as well.  (or it will go upstream when we merge, but that might take a while). I wanted to test and integrate "quickly" into our internal test distribution.

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

PR Review Comment: https://git.openjdk.org/shenandoah/pull/497#discussion_r1755147308

From wkemper at openjdk.org  Wed Sep 11 17:12:27 2024
From: wkemper at openjdk.org (William Kemper)
Date: Wed, 11 Sep 2024 17:12:27 GMT
Subject: RFR: 8339870: Remove yet more stale TODOs [v2]
In-Reply-To: <go3oICacztbX2NQEs54XcO-h4pUuN0pLxl0plBS2OxQ=.d1a6614d-7fc0-4297-a69d-70b4222f9f65@github.com>
References: <R2zLMF_H62csd-NyxcVPsR9BaqxKlS8t6llk4_p6_hI=.77d6a2aa-6d10-4c6d-8582-ae37dbd78d5f@github.com>
 <R4_GiNGjfn3lxMJfeJ69JxUf90OjzlrnwK5YDUCQKYE=.261feb1a-f8b4-4ce3-877b-c64fe3c33e88@github.com>
 <go3oICacztbX2NQEs54XcO-h4pUuN0pLxl0plBS2OxQ=.d1a6614d-7fc0-4297-a69d-70b4222f9f65@github.com>
Message-ID: <_9rV3ZhU3rKNfOqVkkMCEcTZOjClPtPpB6ZPhVpsoD4=.d2427731-0b4f-40f6-aab6-d4ad462fb355@github.com>

On Tue, 10 Sep 2024 19:47:40 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

>> src/hotspot/share/gc/shenandoah/shenandoahConcurrentGC.cpp line 687:
>> 
>>> 685:     _generation->prepare_regions_and_collection_set(true /*concurrent*/);
>>> 686: 
>>> 687:     // Upon return from prepare_regions_and_collection_set(), certain parameters have been established to govern the
>> 
>> For the block comment at lines 687-702 (right pane), would it make sense to move it to the spec of `prepare_...` and remove this block comment from here?
>
> In fact, these are already present in the documentation for the method, so we should just remove this and declutter the code here.

Removed the block of comments and improved the comment on promotion reserve in old generation.

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

PR Review Comment: https://git.openjdk.org/shenandoah/pull/496#discussion_r1755187516

From wkemper at openjdk.org  Wed Sep 11 17:12:27 2024
From: wkemper at openjdk.org (William Kemper)
Date: Wed, 11 Sep 2024 17:12:27 GMT
Subject: RFR: 8339870: Remove yet more stale TODOs [v2]
In-Reply-To: <R4_GiNGjfn3lxMJfeJ69JxUf90OjzlrnwK5YDUCQKYE=.261feb1a-f8b4-4ce3-877b-c64fe3c33e88@github.com>
References: <R2zLMF_H62csd-NyxcVPsR9BaqxKlS8t6llk4_p6_hI=.77d6a2aa-6d10-4c6d-8582-ae37dbd78d5f@github.com>
 <R4_GiNGjfn3lxMJfeJ69JxUf90OjzlrnwK5YDUCQKYE=.261feb1a-f8b4-4ce3-877b-c64fe3c33e88@github.com>
Message-ID: <o5y_ttH_LiBNp_RfSWzXirL43z9deY1rMYuTMTvbMMc=.34b5d515-10c3-4753-ba08-58cfa42a3bc1@github.com>

On Tue, 10 Sep 2024 19:38:12 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

>> William Kemper has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Move rset scan TODOs into ticket
>
> src/hotspot/share/gc/shenandoah/shenandoahFullGC.cpp line 736:
> 
>> 734: //  of memory.  As currently implemented, all regions are compacted toward the low-end of memory.  This creates more
>> 735: //  fragmentation of the heap, because old-gen regions get scattered among low-address regions such that it becomes
>> 736: //  more difficult to find contiguous regions for humongous objects.
> 
> Is this covered in a ticket?

Yes, have this in an internal ticket (for now).

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

PR Review Comment: https://git.openjdk.org/shenandoah/pull/496#discussion_r1755188976

From kdnilsen at openjdk.org  Wed Sep 11 17:20:24 2024
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Wed, 11 Sep 2024 17:20:24 GMT
Subject: RFR: 8339611: GenShen: Simplify
 ShenandoahOldHeuristics::trigger_collection_if_fragmented [v3]
In-Reply-To: <29E4D0A6omnZDjMNSMI9gEkoHIMq-XeY2hBLhg8izAI=.a3b6a5bc-8323-4af8-9766-6e7236af30b8@github.com>
References: <q3WvOqHO5pxBtaFlO2Ep4ZibIB1nyEPyQ-1to21TqS4=.31ba4e8d-2096-4bb4-aad5-902839638ac9@github.com>
 <wQ6Yt5q3w1mBNrQ-8C4C64mP4bcjEEni-r9oej4QfD8=.c7ac6c11-2047-4ed6-bf3b-297a56e61313@github.com>
 <Wi4ge37PYbR3VeuNsu9UG1R7c9e4UUyArRbKD2IaqVc=.4251201b-33b2-400c-9b65-01728a481918@github.com>
 <T9lK2U_x-oEgeOEKjOAYpnLZoIqdanYEendbPKqJQYM=.68201ccc-d781-4866-b76f-d02f6dbfcbf3@github.com>
 <29E4D0A6omnZDjMNSMI9gEkoHIMq-XeY2hBLhg8izAI=.a3b6a5bc-8323-4af8-9766-6e7236af30b8@github.com>
Message-ID: <ThjnH7i-rwxIV3x6ia4NVwS349rrspt1n5b3PhZyjNI=.60fe4aca-9ee9-491e-b7bb-ad1bcbce150c@github.com>

On Tue, 10 Sep 2024 23:39:45 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

>> In this implementation, I'd then describe how the fragmentation is computed.
>
> Also, I'd avoid using "trigger", and instead say "set_trigger", since the actual collection will happen later, as far as I understand.

Thanks.  Adding comment and changing name to set_trigger_if_old_is_fragmented().  Also, renaming trigger_collection_if_overgown() to set_trigger_if_old_is_overgrown().

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

PR Review Comment: https://git.openjdk.org/shenandoah/pull/492#discussion_r1755198905

From wkemper at openjdk.org  Wed Sep 11 17:25:09 2024
From: wkemper at openjdk.org (William Kemper)
Date: Wed, 11 Sep 2024 17:25:09 GMT
Subject: RFR: 8339870: Remove yet more stale TODOs [v3]
In-Reply-To: <R2zLMF_H62csd-NyxcVPsR9BaqxKlS8t6llk4_p6_hI=.77d6a2aa-6d10-4c6d-8582-ae37dbd78d5f@github.com>
References: <R2zLMF_H62csd-NyxcVPsR9BaqxKlS8t6llk4_p6_hI=.77d6a2aa-6d10-4c6d-8582-ae37dbd78d5f@github.com>
Message-ID: <UvQevtPbyPbrUByKlzqJPo9Hlo87Xebh6U5ewmVnL1U=.4aa52dac-9c96-4f61-ad32-c944620cf083@github.com>

> Final round of TODO removal.
> * Move asterisk for pointer next to type, not variable
> * Remembered set verifier uses a small 'scanner' abstraction to simplify reading of read or write card table
> 
> ## Testing
> 
> GHA, Internal pipelines

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

 - Fix typo in comment
 - parseable -> parsable (again)
 - Improve comments

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

Changes:
  - all: https://git.openjdk.org/shenandoah/pull/496/files
  - new: https://git.openjdk.org/shenandoah/pull/496/files/135cc5ec..db8a0e95

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

  Stats: 40 lines in 8 files changed: 4 ins; 17 del; 19 mod
  Patch: https://git.openjdk.org/shenandoah/pull/496.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah.git pull/496/head:pull/496

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

From kdnilsen at openjdk.org  Wed Sep 11 17:30:19 2024
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Wed, 11 Sep 2024 17:30:19 GMT
Subject: RFR: 8339611: GenShen: Simplify
 ShenandoahOldHeuristics::trigger_collection_if_fragmented [v3]
In-Reply-To: <Wi4ge37PYbR3VeuNsu9UG1R7c9e4UUyArRbKD2IaqVc=.4251201b-33b2-400c-9b65-01728a481918@github.com>
References: <q3WvOqHO5pxBtaFlO2Ep4ZibIB1nyEPyQ-1to21TqS4=.31ba4e8d-2096-4bb4-aad5-902839638ac9@github.com>
 <wQ6Yt5q3w1mBNrQ-8C4C64mP4bcjEEni-r9oej4QfD8=.c7ac6c11-2047-4ed6-bf3b-297a56e61313@github.com>
 <Wi4ge37PYbR3VeuNsu9UG1R7c9e4UUyArRbKD2IaqVc=.4251201b-33b2-400c-9b65-01728a481918@github.com>
Message-ID: <MM6Fve8NIHQfOFK71jOdnMJZSQN679_iPFzFSYExshA=.4ad5b98a-8ccc-4bd5-a05a-1f367d603a55@github.com>

On Tue, 10 Sep 2024 23:46:49 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

>> Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Improve comments and clarify intent of old_region_span
>
> src/hotspot/share/gc/shenandoah/heuristics/shenandoahOldHeuristics.cpp line 553:
> 
>> 551: // at density of the old-gen spanned region.  A different mechanism triggers old-gen GC if the total number of
>> 552: // old-gen regions (regardless of how close the regions are to one another) grows beyond an anticipated growth target.
>> 553: void ShenandoahOldHeuristics::trigger_collection_if_fragmented(size_t first_old_region, size_t last_old_region,
> 
> I'd name this method `set_fragmentation_trigger()`, with the side-effect that the fragmentation measures are recorded for logging, and associated triggers are set which are used later to start an old cycle.
> 
> I'd then rename `trigger_maybe()` to `set_triggers()`, and rename `trigger_collection_if_overgrown()` to `set_growth_trigger()`, etc.

Thanks.  Renaming trigger_old_has_grown() to set_growth_trigger().  Renaming trigger_old_is_fragmented() to set_fragmentation_trigger().  Ranaming trigger_maybe() to evaluate_triggers().

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

PR Review Comment: https://git.openjdk.org/shenandoah/pull/492#discussion_r1755211471

From rkennke at openjdk.org  Wed Sep 11 17:31:54 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Wed, 11 Sep 2024 17:31:54 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v12]
In-Reply-To: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
Message-ID: <hB5TC1vwu6WY8By-sEZEBpD3j6an9rGBh14Ef3oyv4s=.aedaeb19-5804-458e-aeb6-3bad716477a7@github.com>

> This is the main body of the JEP 450: Compact Object Headers (Experimental).
> 
> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing.
> 
> Main changes:
>  - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers.
>  - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded.
>  - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops).
>  - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all).
>  - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16).
>  - Arrays will now store their length at offset 8.
>  - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _coh variants of CDS archiv...

Roman Kennke has updated the pull request incrementally with two additional commits since the last revision:

 - Make is_oop() MT-safe
 - Re-enable some vectorization tests

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20677/files
  - new: https://git.openjdk.org/jdk/pull/20677/files/6abda7bc..b6c11f74

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20677&range=11
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20677&range=10-11

  Stats: 32 lines in 6 files changed: 7 ins; 8 del; 17 mod
  Patch: https://git.openjdk.org/jdk/pull/20677.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20677/head:pull/20677

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

From kdnilsen at openjdk.org  Wed Sep 11 17:35:27 2024
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Wed, 11 Sep 2024 17:35:27 GMT
Subject: RFR: 8339611: GenShen: Simplify
 ShenandoahOldHeuristics::trigger_collection_if_fragmented [v3]
In-Reply-To: <Wi4ge37PYbR3VeuNsu9UG1R7c9e4UUyArRbKD2IaqVc=.4251201b-33b2-400c-9b65-01728a481918@github.com>
References: <q3WvOqHO5pxBtaFlO2Ep4ZibIB1nyEPyQ-1to21TqS4=.31ba4e8d-2096-4bb4-aad5-902839638ac9@github.com>
 <wQ6Yt5q3w1mBNrQ-8C4C64mP4bcjEEni-r9oej4QfD8=.c7ac6c11-2047-4ed6-bf3b-297a56e61313@github.com>
 <Wi4ge37PYbR3VeuNsu9UG1R7c9e4UUyArRbKD2IaqVc=.4251201b-33b2-400c-9b65-01728a481918@github.com>
Message-ID: <0PauDxcADJfBqs9KSdtpMkiIk3OkB_L1Tr3m8qWaNlQ=.5716c73a-b25c-4b32-8158-bd4deaedf5a4@github.com>

On Tue, 10 Sep 2024 23:56:01 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

>> Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Improve comments and clarify intent of old_region_span
>
> src/hotspot/share/gc/shenandoah/heuristics/shenandoahOldHeuristics.cpp line 573:
> 
>> 571:     size_t old_words_consumed = old_region_count * region_size_words - old_fragmented_available;
>> 572:     size_t old_words_spanned = old_region_span * region_size_words;
>> 573:     double old_density = ((double) old_words_consumed) / old_words_spanned;
> 
> ... and if `old_region_span = 0`, then you end up with line 573 causing a divide-by-zero error.

Good catch.  Thanks.  I'm restructuring the code to only perform this division if old_span_percent > 0.5.  We only compute old_span_percent if ShenandoahGeneratiionalHumongousReserve > 0.

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

PR Review Comment: https://git.openjdk.org/shenandoah/pull/492#discussion_r1755218000

From kdnilsen at openjdk.org  Wed Sep 11 17:38:33 2024
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Wed, 11 Sep 2024 17:38:33 GMT
Subject: RFR: 8339611: GenShen: Simplify
 ShenandoahOldHeuristics::trigger_collection_if_fragmented [v3]
In-Reply-To: <Wi4ge37PYbR3VeuNsu9UG1R7c9e4UUyArRbKD2IaqVc=.4251201b-33b2-400c-9b65-01728a481918@github.com>
References: <q3WvOqHO5pxBtaFlO2Ep4ZibIB1nyEPyQ-1to21TqS4=.31ba4e8d-2096-4bb4-aad5-902839638ac9@github.com>
 <wQ6Yt5q3w1mBNrQ-8C4C64mP4bcjEEni-r9oej4QfD8=.c7ac6c11-2047-4ed6-bf3b-297a56e61313@github.com>
 <Wi4ge37PYbR3VeuNsu9UG1R7c9e4UUyArRbKD2IaqVc=.4251201b-33b2-400c-9b65-01728a481918@github.com>
Message-ID: <uvMVtuwX_7owC7cXO8sqmZTbnGuv1RkR6VrpGE_hvYQ=.125b327c-f660-4c50-860e-981e09c28b47@github.com>

On Tue, 10 Sep 2024 23:58:58 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

>> Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Improve comments and clarify intent of old_region_span
>
> src/hotspot/share/gc/shenandoah/heuristics/shenandoahOldHeuristics.cpp line 590:
> 
>> 588:       //  old_span_percent is  60% and old_density is below 27.0%, or
>> 589:       //  old_span_percent is  50% and old_density is below 18.8%.
>> 590:       trigger_old_is_fragmented(old_density, first_old_region, last_old_region);
> 
> This method seems a bit useless, why not inline the assignment here? I realize you may be trying to make this method span fewer lines, but I think that can be easily achieved by just moving the description of its work out of line from the code into a block comment at the start that describes how fragmentation is computed and what the trigger threshold criteria are.

I'm pulled in both directions on this.  I'll go with your approach, removing both set_fragmentation_trigger() and set_growth_trigger() (renames mentioned in my responses to above comments).

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

PR Review Comment: https://git.openjdk.org/shenandoah/pull/492#discussion_r1755221778

From rkennke at openjdk.org  Wed Sep 11 17:38:57 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Wed, 11 Sep 2024 17:38:57 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v13]
In-Reply-To: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
Message-ID: <4iHDH-GpSa-uPqe0IwwP6notHRyrOTiecqCSX9kYCe0=.d7969fd0-3066-42fa-82d4-842c10baee1c@github.com>

> This is the main body of the JEP 450: Compact Object Headers (Experimental).
> 
> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing.
> 
> Main changes:
>  - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers.
>  - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded.
>  - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops).
>  - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all).
>  - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16).
>  - Arrays will now store their length at offset 8.
>  - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _coh variants of CDS archiv...

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

  Revert accidental change of UCOH default

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20677/files
  - new: https://git.openjdk.org/jdk/pull/20677/files/b6c11f74..9e008ac1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20677&range=12
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20677&range=11-12

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

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

From wkemper at openjdk.org  Wed Sep 11 17:45:26 2024
From: wkemper at openjdk.org (William Kemper)
Date: Wed, 11 Sep 2024 17:45:26 GMT
Subject: Integrated: 8339870: Remove yet more stale TODOs
In-Reply-To: <R2zLMF_H62csd-NyxcVPsR9BaqxKlS8t6llk4_p6_hI=.77d6a2aa-6d10-4c6d-8582-ae37dbd78d5f@github.com>
References: <R2zLMF_H62csd-NyxcVPsR9BaqxKlS8t6llk4_p6_hI=.77d6a2aa-6d10-4c6d-8582-ae37dbd78d5f@github.com>
Message-ID: <4OVsbcP3cZNZh7NgPxwZ8vfzuvjinMxxJ35LJnVZKyo=.526cee44-5994-4e20-9627-cbc24473b67b@github.com>

On Tue, 10 Sep 2024 17:12:13 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Final round of TODO removal.
> * Move asterisk for pointer next to type, not variable
> * Remembered set verifier uses a small 'scanner' abstraction to simplify reading of read or write card table
> 
> ## Testing
> 
> GHA, Internal pipelines

This pull request has now been integrated.

Changeset: b7405b19
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.org/shenandoah/commit/b7405b19d531269ccb611cb5dc6a07f491a7b9de
Stats:     318 lines in 15 files changed: 50 ins; 162 del; 106 mod

8339870: Remove yet more stale TODOs

Reviewed-by: ysr, kdnilsen

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

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

From kdnilsen at openjdk.org  Wed Sep 11 17:54:53 2024
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Wed, 11 Sep 2024 17:54:53 GMT
Subject: RFR: 8339611: GenShen: Simplify
 ShenandoahOldHeuristics::trigger_collection_if_fragmented [v4]
In-Reply-To: <q3WvOqHO5pxBtaFlO2Ep4ZibIB1nyEPyQ-1to21TqS4=.31ba4e8d-2096-4bb4-aad5-902839638ac9@github.com>
References: <q3WvOqHO5pxBtaFlO2Ep4ZibIB1nyEPyQ-1to21TqS4=.31ba4e8d-2096-4bb4-aad5-902839638ac9@github.com>
Message-ID: <FDHtu2l4eaY7n2rtSV5fKKOcPNXmGrtu85d6_0mLRX8=.b7ca12d0-1801-4805-88e8-285f00454442@github.com>

> Replace iterative solution with a single mathematical computation, and adjust old-gen defragmentation efforts to be a bit less aggressive.

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

  Respond to reviewer feedback

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

Changes:
  - all: https://git.openjdk.org/shenandoah/pull/492/files
  - new: https://git.openjdk.org/shenandoah/pull/492/files/327c5009..b9f03090

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

  Stats: 39 lines in 3 files changed: 6 ins; 4 del; 29 mod
  Patch: https://git.openjdk.org/shenandoah/pull/492.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah.git pull/492/head:pull/492

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

From ysr at openjdk.org  Wed Sep 11 20:44:33 2024
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Wed, 11 Sep 2024 20:44:33 GMT
Subject: RFR: 8339611: GenShen: Simplify
 ShenandoahOldHeuristics::trigger_collection_if_fragmented [v3]
In-Reply-To: <0PauDxcADJfBqs9KSdtpMkiIk3OkB_L1Tr3m8qWaNlQ=.5716c73a-b25c-4b32-8158-bd4deaedf5a4@github.com>
References: <q3WvOqHO5pxBtaFlO2Ep4ZibIB1nyEPyQ-1to21TqS4=.31ba4e8d-2096-4bb4-aad5-902839638ac9@github.com>
 <wQ6Yt5q3w1mBNrQ-8C4C64mP4bcjEEni-r9oej4QfD8=.c7ac6c11-2047-4ed6-bf3b-297a56e61313@github.com>
 <Wi4ge37PYbR3VeuNsu9UG1R7c9e4UUyArRbKD2IaqVc=.4251201b-33b2-400c-9b65-01728a481918@github.com>
 <0PauDxcADJfBqs9KSdtpMkiIk3OkB_L1Tr3m8qWaNlQ=.5716c73a-b25c-4b32-8158-bd4deaedf5a4@github.com>
Message-ID: <VZZiJYF1iVbtY844KEdGZeKNQptG5WBwBtLfLILE5Lc=.67c889b8-f11f-4e84-8cdd-aea2cab4647f@github.com>

On Wed, 11 Sep 2024 17:32:50 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> src/hotspot/share/gc/shenandoah/heuristics/shenandoahOldHeuristics.cpp line 573:
>> 
>>> 571:     size_t old_words_consumed = old_region_count * region_size_words - old_fragmented_available;
>>> 572:     size_t old_words_spanned = old_region_span * region_size_words;
>>> 573:     double old_density = ((double) old_words_consumed) / old_words_spanned;
>> 
>> ... and if `old_region_span = 0`, then you end up with line 573 causing a divide-by-zero error.
>
> Good catch.  Thanks.  I'm restructuring the code to only perform this division if old_span_percent > 0.5.  We only compute old_span_percent if ShenandoahGeneratiionalHumongousReserve > 0.

Yes, that should fix the issue. Just ping me for a re-review when that is completed. Thanks!

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

PR Review Comment: https://git.openjdk.org/shenandoah/pull/492#discussion_r1755574909

From coleenp at openjdk.org  Wed Sep 11 21:18:12 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 11 Sep 2024 21:18:12 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v13]
In-Reply-To: <4iHDH-GpSa-uPqe0IwwP6notHRyrOTiecqCSX9kYCe0=.d7969fd0-3066-42fa-82d4-842c10baee1c@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <4iHDH-GpSa-uPqe0IwwP6notHRyrOTiecqCSX9kYCe0=.d7969fd0-3066-42fa-82d4-842c10baee1c@github.com>
Message-ID: <epFrYZqTWD77IySDqJ9fwFiXZKZ_NCuzA-lfPi6TU_4=.d9c5c483-9a6a-4113-9856-cddcae962f33@github.com>

On Wed, 11 Sep 2024 17:38:57 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> This is the main body of the JEP 450: Compact Object Headers (Experimental).
>> 
>> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing.
>> 
>> Main changes:
>>  - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers.
>>  - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded.
>>  - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops).
>>  - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all).
>>  - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16).
>>  - Arrays will now store their length at offset 8.
>>  - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _co...
>
> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert accidental change of UCOH default

I was starting to understand the concerns with having prototype_header in Klass.  It seems like it would simplify encoding the klass for object allocation.  My recent change https://bugs.openjdk.org/browse/JDK-8338526 breaks this.  You need to pass a parameter to Klass() to tell whether to encode the klass pointer or not, and pass this to Klass() constructor.

     diff --git a/src/hotspot/share/oops/instanceKlass.cpp b/src/hotspot/share/oops/instanceKlass.cpp
     index fd198f54fc9..7aa4bd24948 100644
     --- a/src/hotspot/share/oops/instanceKlass.cpp
     +++ b/src/hotspot/share/oops/instanceKlass.cpp
    @@ -511,7 +511,7 @@ InstanceKlass::InstanceKlass() {
     }
     
     InstanceKlass::InstanceKlass(const ClassFileParser& parser, KlassKind kind, ReferenceType reference_type) :
    -  Klass(kind),
    +  Klass(kind, (!parser.is_interface() && !parser.is_abstract())),
       _nest_members(nullptr),
       _nest_host(nullptr),
       _permitted_subclasses(nullptr),

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

PR Comment: https://git.openjdk.org/jdk/pull/20677#issuecomment-2344715540

From dholmes at openjdk.org  Thu Sep 12 00:19:06 2024
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 12 Sep 2024 00:19:06 GMT
Subject: RFR: 8337563: NMT: rename MEMFLAGS to MemTag [v7]
In-Reply-To: <XNRFNQoz26gPhgG5XSzcbcYiC0RlNv6MPdNI1K1hlkI=.f4bd698b-e546-440f-8c50-b8af375526e5@github.com>
References: <aQDgRwE-H5U0lz8wooLBAQZsuDnB5zZzjMhheIu3y9Y=.0bae7ae4-062e-47de-b7c3-4fedc5d7e20a@github.com>
 <XNRFNQoz26gPhgG5XSzcbcYiC0RlNv6MPdNI1K1hlkI=.f4bd698b-e546-440f-8c50-b8af375526e5@github.com>
Message-ID: <pp5u0_Cml2pufn7FzAhUVAQGLDjwP6Xb8xwrXokSfsM=.05374d94-0209-40b1-af6e-d42d073755fa@github.com>

On Tue, 10 Sep 2024 20:53:46 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

>> Please review this cleanup, where we rename `MEMFLAGS` to `MemTag`.
>> 
>> `MEMFLAGS` implies that we can use more than one at the same time, but those are exclusive values, so `MemTag` is a more suitable name.
>> 
>> This fix also includes a cleanup of all the related function/template parameter names and local variable names.
>> 
>> Testing is pending...
>> 
>> Note: there is more history in old closed PRs [https://github.com/openjdk/jdk/pull/20497](https://github.com/openjdk/jdk/pull/20497) and [https://github.com/openjdk/jdk/pull/20472](https://github.com/openjdk/jdk/pull/20472)
>
> Gerard Ziemski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Coleen's feedback

If anything else crops up we can do a follow up. Thanks.

Please leave as-is.

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20872#pullrequestreview-2298985306
PR Comment: https://git.openjdk.org/jdk/pull/20872#issuecomment-2345010450

From kvn at openjdk.org  Thu Sep 12 00:30:08 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Thu, 12 Sep 2024 00:30:08 GMT
Subject: RFR: 8339849: Enumerate opto and C1 stubs, generate enums, names, 
 fields and generator calls
In-Reply-To: <gmeZu6egkzf71-hoDOcrK8hql0DJ0rdnAr_D0IcE9tc=.7d9cab12-4009-4cf3-8373-dac7eef9f398@github.com>
References: <gmeZu6egkzf71-hoDOcrK8hql0DJ0rdnAr_D0IcE9tc=.7d9cab12-4009-4cf3-8373-dac7eef9f398@github.com>
Message-ID: <FBu9IIWJHjdGa-Q43FK_mBAcJ3as4Fl-yQ-8I5fdkAw=.66f05b87-6c5b-4187-b9f1-0ead4fc972b5@github.com>

On Tue, 10 Sep 2024 15:27:09 GMT, Andrew Dinn <adinn at openjdk.org> wrote:

> Systematize handling of Opto and C1 stubs. Generate enum ids, static fields, stub/blob names and generator code from declarations using template macros as previously done with Shared stubs. Systematically reference stubs and stub names using ids.

Few comments

src/hotspot/share/c1/c1_CodeStubs.hpp line 267:

> 265:   LIR_Opr          _result;
> 266:   CodeEmitInfo*    _info;
> 267:   C1StubId _stub_id;

Preserve spacing

src/hotspot/share/c1/c1_CodeStubs.hpp line 518:

> 516:  private:
> 517:   LIR_Opr          _obj;
> 518:   C1StubId _stub;

Spacing.

src/hotspot/share/opto/escape.cpp line 2046:

> 2044:     if (meth == nullptr) {
> 2045:       const char* name = call->as_CallStaticJava()->_name;
> 2046:       assert(strncmp(name, "Opto Runtime multianewarray", 27) == 0, "TODO: add failed case check");

Please use "C2" instead of "Opto" in your changes in C2 code and in tests.

src/hotspot/share/opto/runtime.cpp line 92:

> 90: 
> 91: #define OPTO_BLOB_FIELD_DEFINE(name, type) \
> 92:   type OptoRuntime:: BLOB_FIELD_NAME(name)  = nullptr;

Please use C2 instead of OPTO in macro names.

src/hotspot/share/opto/runtime.cpp line 147:

> 145: // from the stub name by appending suffix '_C'. However, in two cases
> 146: // a common target method also needs to be called from shared runtime
> 147: // stubs. In these two cases the opto stubs rely on method

"opto" -> "C2"

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

PR Review: https://git.openjdk.org/jdk/pull/20936#pullrequestreview-2298980632
PR Review Comment: https://git.openjdk.org/jdk/pull/20936#discussion_r1755886284
PR Review Comment: https://git.openjdk.org/jdk/pull/20936#discussion_r1755888197
PR Review Comment: https://git.openjdk.org/jdk/pull/20936#discussion_r1755890608
PR Review Comment: https://git.openjdk.org/jdk/pull/20936#discussion_r1755895998
PR Review Comment: https://git.openjdk.org/jdk/pull/20936#discussion_r1755901868

From kvn at openjdk.org  Thu Sep 12 00:30:09 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Thu, 12 Sep 2024 00:30:09 GMT
Subject: RFR: 8339849: Enumerate opto and C1 stubs, generate enums, names, 
 fields and generator calls
In-Reply-To: <WG5bj7qJ9ZROdV1L8borG0SX7Ue0ucq4DGW19p0lug4=.211ffa2c-89df-45e6-88a5-50eb2f4b03eb@github.com>
References: <gmeZu6egkzf71-hoDOcrK8hql0DJ0rdnAr_D0IcE9tc=.7d9cab12-4009-4cf3-8373-dac7eef9f398@github.com>
 <WG5bj7qJ9ZROdV1L8borG0SX7Ue0ucq4DGW19p0lug4=.211ffa2c-89df-45e6-88a5-50eb2f4b03eb@github.com>
Message-ID: <VO03CFL5uQXq07SaKoMHekXA3CR7NrkqKV3aEzT5VoM=.e6b04cde-2bd8-46e3-bf11-dd822c9ac31b@github.com>

On Wed, 11 Sep 2024 08:38:19 GMT, Andrew Dinn <adinn at openjdk.org> wrote:

>> Systematize handling of Opto and C1 stubs. Generate enum ids, static fields, stub/blob names and generator code from declarations using template macros as previously done with Shared stubs. Systematically reference stubs and stub names using ids.
>
> src/hotspot/share/opto/runtime.cpp line 151:
> 
>> 149: // defines temporarily rebind the generated names to reference the
>> 150: // relevant implementations.
>> 151: 
> 
> I am not 100% happy about using defines to finesse this problem of common C targets.
> 
> One alternative here is to define methods local to class OptoRuntime which fit the generator naming convention and have them forward the call to the SharedRuntime methods. n.b. I used (local) method forwarding to allow blobs to share common typefunc providers.
> 
> Another alternative is to declare the C target as a parameter to the opto blob declaration macro. That's more flexible but in almost all cases it repeats information already present and makes understanding and updating the declarations more complex.

This is indeed confusing even with comment. 
I prefer your first suggestion: "define methods local to class OptoRuntime which fit the generator naming convention and have them forward the call to the SharedRuntime methods"

> src/hotspot/share/opto/runtime.cpp line 183:
> 
>> 181:   OPTO_STUBS_DO(GEN_OPTO_BLOB, GEN_OPTO_STUB, GEN_OPTO_JVMTI_STUB)
>> 182: 
>> 183:     /*
> 
> This old code that has been commented out needs to be removed.

Then do it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20936#discussion_r1755904699
PR Review Comment: https://git.openjdk.org/jdk/pull/20936#discussion_r1755900111

From jsjolen at openjdk.org  Thu Sep 12 08:49:08 2024
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Thu, 12 Sep 2024 08:49:08 GMT
Subject: RFR: 8337563: NMT: rename MEMFLAGS to MemTag [v7]
In-Reply-To: <XNRFNQoz26gPhgG5XSzcbcYiC0RlNv6MPdNI1K1hlkI=.f4bd698b-e546-440f-8c50-b8af375526e5@github.com>
References: <aQDgRwE-H5U0lz8wooLBAQZsuDnB5zZzjMhheIu3y9Y=.0bae7ae4-062e-47de-b7c3-4fedc5d7e20a@github.com>
 <XNRFNQoz26gPhgG5XSzcbcYiC0RlNv6MPdNI1K1hlkI=.f4bd698b-e546-440f-8c50-b8af375526e5@github.com>
Message-ID: <rZ4cPC-wYedzPN0zvxYYXAsPalIXURfFRvPCxEYy4w0=.31b59b94-e445-4536-be9e-238b19dca091@github.com>

On Tue, 10 Sep 2024 20:53:46 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

>> Please review this cleanup, where we rename `MEMFLAGS` to `MemTag`.
>> 
>> `MEMFLAGS` implies that we can use more than one at the same time, but those are exclusive values, so `MemTag` is a more suitable name.
>> 
>> This fix also includes a cleanup of all the related function/template parameter names and local variable names.
>> 
>> Testing is pending...
>> 
>> Note: there is more history in old closed PRs [https://github.com/openjdk/jdk/pull/20497](https://github.com/openjdk/jdk/pull/20497) and [https://github.com/openjdk/jdk/pull/20472](https://github.com/openjdk/jdk/pull/20472)
>
> Gerard Ziemski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Coleen's feedback

Hi! I went through all of it and LGTM, one question about copyright notices however.

src/hotspot/share/gc/shenandoah/shenandoahTaskqueue.inline.hpp line 2:

> 1: /*
> 2:  * Copyright (c) 2016, 2019, Red Hat, Inc. All rights reserved.

I don't think we're meant to update other companies' copyrights?

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

Marked as reviewed by jsjolen (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20872#pullrequestreview-2299601404
PR Review Comment: https://git.openjdk.org/jdk/pull/20872#discussion_r1756401544

From azafari at openjdk.org  Thu Sep 12 09:18:07 2024
From: azafari at openjdk.org (Afshin Zafari)
Date: Thu, 12 Sep 2024 09:18:07 GMT
Subject: RFR: 8337563: NMT: rename MEMFLAGS to MemTag [v7]
In-Reply-To: <ZNoKx37DAFcCS1LgNn4wQO7kwWa16mSfODJKuFcHUl4=.05a1cc8d-f189-4554-8bc0-45744c7aa000@github.com>
References: <aQDgRwE-H5U0lz8wooLBAQZsuDnB5zZzjMhheIu3y9Y=.0bae7ae4-062e-47de-b7c3-4fedc5d7e20a@github.com>
 <XNRFNQoz26gPhgG5XSzcbcYiC0RlNv6MPdNI1K1hlkI=.f4bd698b-e546-440f-8c50-b8af375526e5@github.com>
 <ZNoKx37DAFcCS1LgNn4wQO7kwWa16mSfODJKuFcHUl4=.05a1cc8d-f189-4554-8bc0-45744c7aa000@github.com>
Message-ID: <Panmi0JJVMuSKUmIfFQ2Dsj521NWg2W15KjHEmt1Igc=.e0fd63a3-c198-43e1-8bc4-e761c2b6dee0@github.com>

On Wed, 11 Sep 2024 14:03:17 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

>> Gerard Ziemski has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Coleen's feedback
>
> Are we sure we want `mt` for non-type parameter name in templates? We have these existing patterns already in our code:
> 
> 
> src/hotspot/share/utilities/growableArray.hpp:803:template <typename E, MemTag MT>
> src/hotspot/share/utilities/stack.hpp:54:template <class E, MemTag MT> class StackIterator;
> src/hotspot/share/utilities/concurrentHashTable.inline.hpp:78:template <typename CONFIG, MemTag MT>
> src/hotspot/share/utilities/chunkedList.hpp:31:template <class T, MemTag MT> class ChunkedList : public CHeapObj<MT> 
> src/hotspot/share/gc/g1/g1BatchedTask.hpp:32:template <typename E, MemTag MT>
> src/hotspot/share/gc/shared/taskqueue.hpp:119:template <unsigned int N, MemTag MT>
> src/hotspot/share/gc/shared/taskqueue.hpp:327:template <class E, MemTag MT, unsigned int N = TASKQUEUE_SIZE>
> src/hotspot/share/gc/shenandoah/shenandoahTaskqueue.hpp:40:template<class E, MemTag MT, unsigned int N = TASKQUEUE_SIZE>
> src/hotspot/share/nmt/arrayWithFreeList.hpp:34:template<typename E, MemTag MT>
> 
> 
> With mt they would look like:
> 
> 
> src/hotspot/share/utilities/growableArray.hpp:803:template <typename E, MemTag mt>
> src/hotspot/share/utilities/stack.hpp:54:template <class E, MemTag mt> class StackIterator;
> src/hotspot/share/utilities/concurrentHashTable.inline.hpp:78:template <typename CONFIG, MemTag mt>
> src/hotspot/share/utilities/chunkedList.hpp:31:template <class T, MemTag mt> class ChunkedList : public CHeapObj<mt> 
> src/hotspot/share/gc/g1/g1BatchedTask.hpp:32:template <typename E, MemTag mt>
> src/hotspot/share/gc/shared/taskqueue.hpp:119:template <unsigned int N, MemTag mt>
> src/hotspot/share/gc/shared/taskqueue.hpp:327:template <class E, MemTag mt, unsigned int N = TASKQUEUE_SIZE>
> src/hotspot/share/gc/shenandoah/shenandoahTaskqueue.hpp:40:template<class E, MemTag mt, unsigned int N = TASKQUEUE_SIZE>
> src/hotspot/share/nmt/arrayWithFreeList.hpp:34:template<typename E, MemTag mt>
> 
> 
> So `MT` or `mt` for non-type parameter name in templates, or should I punt on this particular change and leave it for a followup?

Thank you @gerard-ziemski, for this huge change. After this change, the code looks much more nicer and consistent.

If we are insisting on replacing `flag` with `tag`, I could find these missed ones by regexp search for `mem.*flag`:

---
7 results - 5 files

Source root ? src/hotspot/share/nmt/memMapPrinter.cpp:
  `83: // A Cache that correlates range with MEMFLAG, optimized to be iterated quickly`

Source root ? src/hotspot/share/nmt/memTracker.hpp:
  `208:   //  memory flags of the original region.`

Source root ? src/hotspot/share/nmt/vmatree.hpp:

`97:       assert(!(type == StateType::Released) || data.mem_tag == mtNone, "Released type must have flag mtNone");`

`108:       return static_cast<MemTag>(type_flag[1]);`


Source root ? test/hotspot/gtest/nmt/test_nmt_reserved_region.cpp:
  `50:   ASSERT_EQ(region2.mem_tag(), mtThreadStack); // Should be correct flag`

Source root ? test/hotspot/gtest/nmt/test_vmatree.cpp:
  
`435:   const MemTag candidate_flags[candidates_len_flags] = {`

`459:     const MemTag mem_tag = candidate_flags[os::random() % candidates_len_flags];`

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

PR Comment: https://git.openjdk.org/jdk/pull/20872#issuecomment-2345718458

From rcastanedalo at openjdk.org  Thu Sep 12 10:20:15 2024
From: rcastanedalo at openjdk.org (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Thu, 12 Sep 2024 10:20:15 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v13]
In-Reply-To: <4iHDH-GpSa-uPqe0IwwP6notHRyrOTiecqCSX9kYCe0=.d7969fd0-3066-42fa-82d4-842c10baee1c@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <4iHDH-GpSa-uPqe0IwwP6notHRyrOTiecqCSX9kYCe0=.d7969fd0-3066-42fa-82d4-842c10baee1c@github.com>
Message-ID: <xnL42l4bz2SaiEgSVCDBXXbnZqgnIcYpnSy7tM2WY1w=.094f34bb-4587-4c45-ad44-daf83705515a@github.com>

On Wed, 11 Sep 2024 17:38:57 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> This is the main body of the JEP 450: Compact Object Headers (Experimental).
>> 
>> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing.
>> 
>> Main changes:
>>  - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers.
>>  - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded.
>>  - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops).
>>  - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all).
>>  - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16).
>>  - Arrays will now store their length at offset 8.
>>  - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _co...
>
> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert accidental change of UCOH default

src/hotspot/share/opto/lcm.cpp line 272:

> 270:         const TypePtr* tptr;
> 271:         if ((UseCompressedOops || UseCompressedClassPointers) &&
> 272:             (CompressedOops::shift() == 0 || CompressedKlassPointers::shift() == 0)) {

Could you explain this change? It seems like it may affect C2's implicit null check analysis even for `-XX:-UseCompactObjectHeaders`. In particular, for the following configurations, the changed condition evaluates to true before the change and false after it, regardless of whether `UseCompactObjectHeaders` is enabled:

(!UseCompressedOops,  UseCompressedClassPointers, CompressedKlassPointers::shift() != 0)
( UseCompressedOops, !UseCompressedClassPointers, CompressedOops::shift() != 0)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1756570168

From rcastanedalo at openjdk.org  Thu Sep 12 11:49:15 2024
From: rcastanedalo at openjdk.org (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Thu, 12 Sep 2024 11:49:15 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v13]
In-Reply-To: <4iHDH-GpSa-uPqe0IwwP6notHRyrOTiecqCSX9kYCe0=.d7969fd0-3066-42fa-82d4-842c10baee1c@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <4iHDH-GpSa-uPqe0IwwP6notHRyrOTiecqCSX9kYCe0=.d7969fd0-3066-42fa-82d4-842c10baee1c@github.com>
Message-ID: <s0uUPQ4WJ3JMVQStLUrhTK_Kjn3joFNQOX7Hm_JRbqE=.44a6c8ee-fad6-4aa6-8e95-cd8d23beab60@github.com>

On Wed, 11 Sep 2024 17:38:57 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> This is the main body of the JEP 450: Compact Object Headers (Experimental).
>> 
>> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing.
>> 
>> Main changes:
>>  - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers.
>>  - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded.
>>  - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops).
>>  - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all).
>>  - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16).
>>  - Arrays will now store their length at offset 8.
>>  - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _co...
>
> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert accidental change of UCOH default

src/hotspot/share/cds/filemap.cpp line 2457:

> 2455:                           compressed_oops(), compressed_class_pointers());
> 2456:   if (compressed_oops() != UseCompressedOops || compressed_class_pointers() != UseCompressedClassPointers) {
> 2457:     log_info(cds)("Unable to use shared archive.\nThe saved state of UseCompressedOops and UseCompressedClassPointers is "

The promotion of this CDS log line from `info` to `warning` triggers false failures in the `test/hotspot/jtreg/compiler/intrinsics/bmi` tests when running them with `-XX:-UseCompressedClassPointers`. These tests expect the standard output of different JVM runs to be identical, but the timestamps in the log messages tend to differ. I suggest adjusting the test configuration so that log timestamps are simply omitted, as in [this patch](https://github.com/robcasloz/jdk/commit/48f6e90ef6e0a71b55df536ed04a8b72130b5ea9) (feel free to merge it as-is or with any further changes you may find necessary).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1756699774

From dholmes at openjdk.org  Thu Sep 12 11:57:09 2024
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 12 Sep 2024 11:57:09 GMT
Subject: RFR: 8337563: NMT: rename MEMFLAGS to MemTag [v7]
In-Reply-To: <rZ4cPC-wYedzPN0zvxYYXAsPalIXURfFRvPCxEYy4w0=.31b59b94-e445-4536-be9e-238b19dca091@github.com>
References: <aQDgRwE-H5U0lz8wooLBAQZsuDnB5zZzjMhheIu3y9Y=.0bae7ae4-062e-47de-b7c3-4fedc5d7e20a@github.com>
 <XNRFNQoz26gPhgG5XSzcbcYiC0RlNv6MPdNI1K1hlkI=.f4bd698b-e546-440f-8c50-b8af375526e5@github.com>
 <rZ4cPC-wYedzPN0zvxYYXAsPalIXURfFRvPCxEYy4w0=.31b59b94-e445-4536-be9e-238b19dca091@github.com>
Message-ID: <7JNLDZV1F6_QuMJSq-pu08lFSEULMe41bpQDucXEoEw=.8c051b63-24eb-451d-a2b2-04e8926638c1@github.com>

On Thu, 12 Sep 2024 08:35:16 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> Gerard Ziemski has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Coleen's feedback
>
> src/hotspot/share/gc/shenandoah/shenandoahTaskqueue.inline.hpp line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 2016, 2019, Red Hat, Inc. All rights reserved.
> 
> I don't think we're meant to update other companies' copyrights?

That is correct - unless requested by someone representing that copyright owner.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20872#discussion_r1756711680

From azafari at openjdk.org  Thu Sep 12 12:05:11 2024
From: azafari at openjdk.org (Afshin Zafari)
Date: Thu, 12 Sep 2024 12:05:11 GMT
Subject: RFR: 8337563: NMT: rename MEMFLAGS to MemTag [v7]
In-Reply-To: <XNRFNQoz26gPhgG5XSzcbcYiC0RlNv6MPdNI1K1hlkI=.f4bd698b-e546-440f-8c50-b8af375526e5@github.com>
References: <aQDgRwE-H5U0lz8wooLBAQZsuDnB5zZzjMhheIu3y9Y=.0bae7ae4-062e-47de-b7c3-4fedc5d7e20a@github.com>
 <XNRFNQoz26gPhgG5XSzcbcYiC0RlNv6MPdNI1K1hlkI=.f4bd698b-e546-440f-8c50-b8af375526e5@github.com>
Message-ID: <T27IXF8v5LiQcv8S0INVRF3pXeEfTvMFcxE32OP-FYM=.fd805fe6-85ee-467d-bb68-957ad92ce8ad@github.com>

On Tue, 10 Sep 2024 20:53:46 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

>> Please review this cleanup, where we rename `MEMFLAGS` to `MemTag`.
>> 
>> `MEMFLAGS` implies that we can use more than one at the same time, but those are exclusive values, so `MemTag` is a more suitable name.
>> 
>> This fix also includes a cleanup of all the related function/template parameter names and local variable names.
>> 
>> Testing is pending...
>> 
>> Note: there is more history in old closed PRs [https://github.com/openjdk/jdk/pull/20497](https://github.com/openjdk/jdk/pull/20497) and [https://github.com/openjdk/jdk/pull/20472](https://github.com/openjdk/jdk/pull/20472)
>
> Gerard Ziemski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Coleen's feedback

Thank you @gerard-ziemski, for this huge change. After this change, the code looks much more nicer and consistent.

If we are insisting on replacing `flag` with `tag`, I could find these missed ones by regexp search for `mem.*flag`:

---
7 results - 5 files

Source root ? src/hotspot/share/nmt/memMapPrinter.cpp:
  `83: // A Cache that correlates range with MEMFLAG, optimized to be iterated quickly`

Source root ? src/hotspot/share/nmt/memTracker.hpp:
  `208:   //  memory flags of the original region.`

Source root ? src/hotspot/share/nmt/vmatree.hpp:

`97:       assert(!(type == StateType::Released) || data.mem_tag == mtNone, "Released type must have flag mtNone");`

`108:       return static_cast<MemTag>(type_flag[1]);`


Source root ? test/hotspot/gtest/nmt/test_nmt_reserved_region.cpp:
  `50:   ASSERT_EQ(region2.mem_tag(), mtThreadStack); // Should be correct flag`

Source root ? test/hotspot/gtest/nmt/test_vmatree.cpp:
  
`435:   const MemTag candidate_flags[candidates_len_flags] = {`

`459:     const MemTag mem_tag = candidate_flags[os::random() % candidates_len_flags];`

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

PR Review: https://git.openjdk.org/jdk/pull/20872#pullrequestreview-2300097782

From adinn at openjdk.org  Thu Sep 12 12:40:22 2024
From: adinn at openjdk.org (Andrew Dinn)
Date: Thu, 12 Sep 2024 12:40:22 GMT
Subject: RFR: 8339849: Enumerate opto and C1 stubs, generate enums, names, 
 fields and generator calls [v2]
In-Reply-To: <gmeZu6egkzf71-hoDOcrK8hql0DJ0rdnAr_D0IcE9tc=.7d9cab12-4009-4cf3-8373-dac7eef9f398@github.com>
References: <gmeZu6egkzf71-hoDOcrK8hql0DJ0rdnAr_D0IcE9tc=.7d9cab12-4009-4cf3-8373-dac7eef9f398@github.com>
Message-ID: <hWGtayer3iflHjtiVgTEojbZO4a3yaAHyid1FU3wl4Y=.fdb36ddd-db35-4d40-ab8d-9b4b18f419d9@github.com>

> Systematize handling of Opto and C1 stubs. Generate enum ids, static fields, stub/blob names and generator code from declarations using template macros as previously done with Shared stubs. Systematically reference stubs and stub names using ids.

Andrew Dinn has updated the pull request incrementally with two additional commits since the last revision:

 - Answer review feedback
 - remove commented out old code

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20936/files
  - new: https://git.openjdk.org/jdk/pull/20936/files/f1f7fc28..b2e81b04

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

  Stats: 131 lines in 7 files changed: 20 ins; 37 del; 74 mod
  Patch: https://git.openjdk.org/jdk/pull/20936.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20936/head:pull/20936

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

From adinn at openjdk.org  Thu Sep 12 12:40:22 2024
From: adinn at openjdk.org (Andrew Dinn)
Date: Thu, 12 Sep 2024 12:40:22 GMT
Subject: RFR: 8339849: Enumerate opto and C1 stubs, generate enums, names, 
 fields and generator calls [v2]
In-Reply-To: <VO03CFL5uQXq07SaKoMHekXA3CR7NrkqKV3aEzT5VoM=.e6b04cde-2bd8-46e3-bf11-dd822c9ac31b@github.com>
References: <gmeZu6egkzf71-hoDOcrK8hql0DJ0rdnAr_D0IcE9tc=.7d9cab12-4009-4cf3-8373-dac7eef9f398@github.com>
 <WG5bj7qJ9ZROdV1L8borG0SX7Ue0ucq4DGW19p0lug4=.211ffa2c-89df-45e6-88a5-50eb2f4b03eb@github.com>
 <VO03CFL5uQXq07SaKoMHekXA3CR7NrkqKV3aEzT5VoM=.e6b04cde-2bd8-46e3-bf11-dd822c9ac31b@github.com>
Message-ID: <jLiBbweXXFeLxpNl9B4dqEBYn75a6rRZYJnn5UnlP08=.3245160b-a500-49c1-8128-4676c752c9f2@github.com>

On Thu, 12 Sep 2024 00:27:42 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> src/hotspot/share/opto/runtime.cpp line 151:
>> 
>>> 149: // defines temporarily rebind the generated names to reference the
>>> 150: // relevant implementations.
>>> 151: 
>> 
>> I am not 100% happy about using defines to finesse this problem of common C targets.
>> 
>> One alternative here is to define methods local to class OptoRuntime which fit the generator naming convention and have them forward the call to the SharedRuntime methods. n.b. I used (local) method forwarding to allow blobs to share common typefunc providers.
>> 
>> Another alternative is to declare the C target as a parameter to the opto blob declaration macro. That's more flexible but in almost all cases it repeats information already present and makes understanding and updating the declarations more complex.
>
> This is indeed confusing even with comment. 
> I prefer your first suggestion: "define methods local to class OptoRuntime which fit the generator naming convention and have them forward the call to the SharedRuntime methods"

Done.

>> src/hotspot/share/opto/runtime.cpp line 183:
>> 
>>> 181:   OPTO_STUBS_DO(GEN_OPTO_BLOB, GEN_OPTO_STUB, GEN_OPTO_JVMTI_STUB)
>>> 182: 
>>> 183:     /*
>> 
>> This old code that has been commented out needs to be removed.
>
> Then do it.

Done

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20936#discussion_r1756771514
PR Review Comment: https://git.openjdk.org/jdk/pull/20936#discussion_r1756774703

From rkennke at openjdk.org  Thu Sep 12 13:16:14 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Thu, 12 Sep 2024 13:16:14 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v11]
In-Reply-To: <kzodWwxj5qdAqPYcP2s4k2QTXqjju2H6Iftu7dojezk=.1f72fc31-94ba-4017-b330-c8688a8d39a4@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <DUgk6HT_Zk5KnbmAd_HzrJi4B8D1J-uuoAGzReWyI8s=.6c04f90a-bf1d-49af-a31d-5224973952d4@github.com>
 <YTte6oY9EeAPHxzzOndL8M202wY91SbeaYC4hPva0W0=.caf00270-89c7-44b0-ab88-a970fb8e840d@github.com>
 <kzodWwxj5qdAqPYcP2s4k2QTXqjju2H6Iftu7dojezk=.1f72fc31-94ba-4017-b330-c8688a8d39a4@github.com>
Message-ID: <hkGaBWSugvpV0PgoR9rnutHCgQzkeXv1ctH7QwV3zK0=.204737d5-fadb-410a-8891-7db59d36830f@github.com>

On Wed, 11 Sep 2024 13:34:28 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> @rkennke Can you please explain the changes in these tests:
>> 
>> test/hotspot/jtreg/compiler/c2/irTests/TestVectorizationMismatchedAccess.java
>> test/hotspot/jtreg/compiler/c2/irTests/TestVectorizationNotRun.java
>> test/hotspot/jtreg/compiler/loopopts/superword/TestAlignVector.java
>> test/hotspot/jtreg/compiler/loopopts/superword/TestIndependentPacksWithCyclicDependency.java
>> test/hotspot/jtreg/compiler/loopopts/superword/TestMulAddS2I.java
>> 
>> 
>> You added these IR rule restriction:
>> `@IR(applyIf = {"UseCompactObjectHeaders", "false"},`
>> 
>> This means that if `UseCompactObjectHeaders` is enabled, vectorization seems to be impacted - that could be concerning because it has a performance impact.
>> 
>> I have recently changed a few things in SuperWord, so maybe some of them can be removed, because they now vectorize anyway?
>> 
>> Of course some special tests may just rely on `UseCompactObjectHeaders == false` - but I would need some comments in the tests where you added it to justify why we add the restriction.
>> 
>> Please also test this patch with the cross combinations of `UseCompactObjectHeaders` and `AlignVector` enabled and disabled (and add `VerifyAlignVector` as well).
>
>> @rkennke Can you please explain the changes in these tests:
>> 
>> ```
>> test/hotspot/jtreg/compiler/c2/irTests/TestVectorizationMismatchedAccess.java
>> test/hotspot/jtreg/compiler/c2/irTests/TestVectorizationNotRun.java
>> test/hotspot/jtreg/compiler/loopopts/superword/TestAlignVector.java
>> test/hotspot/jtreg/compiler/loopopts/superword/TestIndependentPacksWithCyclicDependency.java
>> test/hotspot/jtreg/compiler/loopopts/superword/TestMulAddS2I.java
>> ```
>> 
>> You added these IR rule restriction: `@IR(applyIf = {"UseCompactObjectHeaders", "false"},`
>> 
>> This means that if `UseCompactObjectHeaders` is enabled, vectorization seems to be impacted - that could be concerning because it has a performance impact.
>> 
>> I have recently changed a few things in SuperWord, so maybe some of them can be removed, because they now vectorize anyway?
>> 
>> Of course some special tests may just rely on `UseCompactObjectHeaders == false` - but I would need some comments in the tests where you added it to justify why we add the restriction.
>> 
>> Please also test this patch with the cross combinations of `UseCompactObjectHeaders` and `AlignVector` enabled and disabled (and add `VerifyAlignVector` as well).
> 
> IIRC (it has been a while), the problem is that with Lilliput (and also without compact headers, but disabling compressed class-pointers -UseCompressedClassPointers, but nobody ever does that), byte[] and long[] start at different offsets (12 and 16, respectively). That is because with compact headers, we are using the 4 bytes after the arraylength, but long-arrays cannot do that because of alignment constraints. The impact is that these tests don't work as expected, because vectorization triggers differently. I don't remember the details, TBH, but I believe they would now generate pre-loops, or some might even not vectorize at all. Those seemed to be use-cases that did not look very important, but I may be wrong. It would be nice to properly fix those tests, or make corresponding tests for compact headers, instead, or improve vectorization to better deal with the offset mismatch, if necessary/possible.
> 
> I will re-evaluate those tests, and add comments or remove the restrictions.

> > > @rkennke Can you please explain the changes in these tests:
> > > ```
> > > test/hotspot/jtreg/compiler/c2/irTests/TestVectorizationMismatchedAccess.java
> > > test/hotspot/jtreg/compiler/c2/irTests/TestVectorizationNotRun.java
> > > test/hotspot/jtreg/compiler/loopopts/superword/TestAlignVector.java
> > > test/hotspot/jtreg/compiler/loopopts/superword/TestIndependentPacksWithCyclicDependency.java
> > > test/hotspot/jtreg/compiler/loopopts/superword/TestMulAddS2I.java
> > > ```
> > > 
> > > 
> > >     
> > >       
> > >     
> > > 
> > >       
> > >     
> > > 
> > >     
> > >   
> > > You added these IR rule restriction: `@IR(applyIf = {"UseCompactObjectHeaders", "false"},`
> > > This means that if `UseCompactObjectHeaders` is enabled, vectorization seems to be impacted - that could be concerning because it has a performance impact.
> > > I have recently changed a few things in SuperWord, so maybe some of them can be removed, because they now vectorize anyway?
> > > Of course some special tests may just rely on `UseCompactObjectHeaders == false` - but I would need some comments in the tests where you added it to justify why we add the restriction.
> > > Please also test this patch with the cross combinations of `UseCompactObjectHeaders` and `AlignVector` enabled and disabled (and add `VerifyAlignVector` as well).
> > 
> > 
> > IIRC (it has been a while), the problem is that with Lilliput (and also without compact headers, but disabling compressed class-pointers -UseCompressedClassPointers, but nobody ever does that), byte[] and long[] start at different offsets (12 and 16, respectively). That is because with compact headers, we are using the 4 bytes after the arraylength, but long-arrays cannot do that because of alignment constraints. The impact is that these tests don't work as expected, because vectorization triggers differently. I don't remember the details, TBH, but I believe they would now generate pre-loops, or some might even not vectorize at all. Those seemed to be use-cases that did not look very important, but I may be wrong. It would be nice to properly fix those tests, or make corresponding tests for compact headers, instead, or improve vectorization to better deal with the offset mismatch, if necessary/possible.
> > I will re-evaluate those tests, and add comments or remove the restrictions.
> 
> If it has indeed been a while, then it might well be that some of them work now, since I did make some improvements to auto-vectorization ;)
> 
> My suggestion is this: go over the examples, check which ones are now ok. Those that are not ok, add a comment, and file a bug: I can then analyze those cases later, and see how to write other tests or improve auto-vectorization.

Indeed, I could re-enable all tests in:

test/hotspot/jtreg/compiler/c2/irTests/TestVectorizationMismatchedAccess.java
test/hotspot/jtreg/compiler/c2/irTests/TestVectorizationNotRun.java
test/hotspot/jtreg/compiler/loopopts/superword/TestIndependentPacksWithCyclicDependency.java

but unfortunately not those others:

> > > test/hotspot/jtreg/compiler/loopopts/superword/TestAlignVector.java
> > > test/hotspot/jtreg/compiler/loopopts/superword/TestMulAddS2I.java


I think the issue with all of them is that vectorization in those scenarios only works when the operations inside the loop start at an array index that addresses an element at 8-byte-aligned offset.

I have filed https://bugs.openjdk.org/browse/JDK-8340010 to track it.

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

PR Comment: https://git.openjdk.org/jdk/pull/20677#issuecomment-2346250313

From epeter at openjdk.org  Thu Sep 12 13:23:14 2024
From: epeter at openjdk.org (Emanuel Peter)
Date: Thu, 12 Sep 2024 13:23:14 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v11]
In-Reply-To: <hkGaBWSugvpV0PgoR9rnutHCgQzkeXv1ctH7QwV3zK0=.204737d5-fadb-410a-8891-7db59d36830f@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <DUgk6HT_Zk5KnbmAd_HzrJi4B8D1J-uuoAGzReWyI8s=.6c04f90a-bf1d-49af-a31d-5224973952d4@github.com>
 <YTte6oY9EeAPHxzzOndL8M202wY91SbeaYC4hPva0W0=.caf00270-89c7-44b0-ab88-a970fb8e840d@github.com>
 <kzodWwxj5qdAqPYcP2s4k2QTXqjju2H6Iftu7dojezk=.1f72fc31-94ba-4017-b330-c8688a8d39a4@github.com>
 <hkGaBWSugvpV0PgoR9rnutHCgQzkeXv1ctH7QwV3zK0=.204737d5-fadb-410a-8891-7db59d36830f@github.com>
Message-ID: <shoDPnL4nQyaYX4xy-WyzQ7CwsoCbAeCE3c755CkE1o=.caf940aa-5fbb-4cb5-a4a2-68a2452ffe1b@github.com>

On Thu, 12 Sep 2024 13:13:01 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> > > > @rkennke Can you please explain the changes in these tests:
> > > > ```
> > > > test/hotspot/jtreg/compiler/c2/irTests/TestVectorizationMismatchedAccess.java
> > > > test/hotspot/jtreg/compiler/c2/irTests/TestVectorizationNotRun.java
> > > > test/hotspot/jtreg/compiler/loopopts/superword/TestAlignVector.java
> > > > test/hotspot/jtreg/compiler/loopopts/superword/TestIndependentPacksWithCyclicDependency.java
> > > > test/hotspot/jtreg/compiler/loopopts/superword/TestMulAddS2I.java
> > > > ```
> > > > 
> > > > 
> > > >     
> > > >       
> > > >     
> > > > 
> > > >       
> > > >     
> > > > 
> > > >     
> > > >   
> > > > You added these IR rule restriction: `@IR(applyIf = {"UseCompactObjectHeaders", "false"},`
> > > > This means that if `UseCompactObjectHeaders` is enabled, vectorization seems to be impacted - that could be concerning because it has a performance impact.
> > > > I have recently changed a few things in SuperWord, so maybe some of them can be removed, because they now vectorize anyway?
> > > > Of course some special tests may just rely on `UseCompactObjectHeaders == false` - but I would need some comments in the tests where you added it to justify why we add the restriction.
> > > > Please also test this patch with the cross combinations of `UseCompactObjectHeaders` and `AlignVector` enabled and disabled (and add `VerifyAlignVector` as well).
> > > 
> > > 
> > > IIRC (it has been a while), the problem is that with Lilliput (and also without compact headers, but disabling compressed class-pointers -UseCompressedClassPointers, but nobody ever does that), byte[] and long[] start at different offsets (12 and 16, respectively). That is because with compact headers, we are using the 4 bytes after the arraylength, but long-arrays cannot do that because of alignment constraints. The impact is that these tests don't work as expected, because vectorization triggers differently. I don't remember the details, TBH, but I believe they would now generate pre-loops, or some might even not vectorize at all. Those seemed to be use-cases that did not look very important, but I may be wrong. It would be nice to properly fix those tests, or make corresponding tests for compact headers, instead, or improve vectorization to better deal with the offset mismatch, if necessary/possible.
> > > I will re-evaluate those tests, and add comments or remove the restrictions.
> > 
> > 
> > If it has indeed been a while, then it might well be that some of them work now, since I did make some improvements to auto-vectorization ;)
> > My suggestion is this: go over the examples, check which ones are now ok. Those that are not ok, add a comment, and file a bug: I can then analyze those cases later, and see how to write other tests or improve auto-vectorization.
> 
> Indeed, I could re-enable all tests in:
> 
> ```
> test/hotspot/jtreg/compiler/c2/irTests/TestVectorizationMismatchedAccess.java
> test/hotspot/jtreg/compiler/c2/irTests/TestVectorizationNotRun.java
> test/hotspot/jtreg/compiler/loopopts/superword/TestIndependentPacksWithCyclicDependency.java
> ```
> 
> but unfortunately not those others:
> 
> ```
> > > > test/hotspot/jtreg/compiler/loopopts/superword/TestAlignVector.java
> > > > test/hotspot/jtreg/compiler/loopopts/superword/TestMulAddS2I.java
> ```
> 
> I think the issue with all of them is that vectorization in those scenarios only works when the operations inside the loop start at an array index that addresses an element at 8-byte-aligned offset.
> 
> I have filed https://bugs.openjdk.org/browse/JDK-8340010 to track it.

Excellent, that is what I hoped for! Thanks for filing the bug, I'll look into it once this is integrated. You should probably mark it as "blocked by", not "related to" ;)

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

PR Comment: https://git.openjdk.org/jdk/pull/20677#issuecomment-2346266568

From azafari at openjdk.org  Thu Sep 12 13:36:10 2024
From: azafari at openjdk.org (Afshin Zafari)
Date: Thu, 12 Sep 2024 13:36:10 GMT
Subject: RFR: 8337563: NMT: rename MEMFLAGS to MemTag [v7]
In-Reply-To: <XNRFNQoz26gPhgG5XSzcbcYiC0RlNv6MPdNI1K1hlkI=.f4bd698b-e546-440f-8c50-b8af375526e5@github.com>
References: <aQDgRwE-H5U0lz8wooLBAQZsuDnB5zZzjMhheIu3y9Y=.0bae7ae4-062e-47de-b7c3-4fedc5d7e20a@github.com>
 <XNRFNQoz26gPhgG5XSzcbcYiC0RlNv6MPdNI1K1hlkI=.f4bd698b-e546-440f-8c50-b8af375526e5@github.com>
Message-ID: <S4c0iHbwhtK3dst5MjhIA5AdhNMGWPs9BA2IjDcfQj4=.f5e3cad1-b2fb-49f0-91c2-465063295db1@github.com>

On Tue, 10 Sep 2024 20:53:46 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

>> Please review this cleanup, where we rename `MEMFLAGS` to `MemTag`.
>> 
>> `MEMFLAGS` implies that we can use more than one at the same time, but those are exclusive values, so `MemTag` is a more suitable name.
>> 
>> This fix also includes a cleanup of all the related function/template parameter names and local variable names.
>> 
>> Testing is pending...
>> 
>> Note: there is more history in old closed PRs [https://github.com/openjdk/jdk/pull/20497](https://github.com/openjdk/jdk/pull/20497) and [https://github.com/openjdk/jdk/pull/20472](https://github.com/openjdk/jdk/pull/20472)
>
> Gerard Ziemski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Coleen's feedback

Again, if we want to replace mem type with mem tag. The regexp search for mem.*type gives this: 
---
47 results - 19 files

Source root ? src/hotspot/share/gc/shared/oopStorage.hpp:
   92:   // The memory type for allocations.
  276:   // The memory type for allocations.

Source root ? src/hotspot/share/nmt/mallocSiteTable.hpp:
  68:     assert(mem_tag != mtNone, "Expect a real memory type");

Source root ? src/hotspot/share/nmt/memBaseline.cpp:
  64: // Sort into allocation site addresses and memory type order for baseline comparison

Source root ? src/hotspot/share/nmt/memBaseline.hpp:
   56:     by_site_and_type // by call site and memory type
  206:   // Sort allocation sites in call site address and memory type order

Source root ? src/hotspot/share/nmt/memReporter.cpp:
  138: void MemReporterBase::print_virtual_memory_region(const char* type, address base, size_t size) const {
  179:   // Summary by memory type
  191: void MemSummaryReporter::report_summary_of_type(MemTag mem_tag,
  280: void MemSummaryReporter::report_metadata(Metaspace::MetadataType type) const {
  343:       "Must have a valid memory type");
  522:   // Summary diff by memory type
  597: void MemSummaryDiffReporter::diff_summary_of_type(MemTag mem_tag,
  798:   MallocSiteIterator early_itr = _early_baseline.malloc_sites(MemBaseline::by_site_and_type);
  799:   MallocSiteIterator current_itr = _current_baseline.malloc_sites(MemBaseline::by_site_and_type);
  851:         // This site was originally allocated with one memory type, then released,
  852:         // then re-allocated at the same site (as far as we can tell) with a different memory type.

Source root ? src/hotspot/share/nmt/memReporter.hpp:
  141:   // Report summary for each memory type

Source root ? src/hotspot/share/nmt/memTracker.cpp:
  64:   // Memory type is encoded into tracking header as a byte field,

Source root ? src/hotspot/share/nmt/nmtCommon.cpp:
  32: #define MEMORY_TAG_DECLARE_NAME(type, human_readable) \

Source root ? src/hotspot/share/nmt/nmtCommon.hpp:
  91:     assert(tag_is_valid(mem_tag), "Invalid type (%u)", (unsigned)mem_tag);

Source root ? src/hotspot/share/nmt/virtualMemoryTracker.cpp:
  297:          "Overwrite memory type for region [" INTPTR_FORMAT "-" INTPTR_FORMAT "), %u->%u.",
  425:       assert(reserved_rgn->mem_tag() == mtNone, "Overwrite memory type (should be mtNone, is: "%s")",

Source root ? src/hotspot/share/nmt/virtualMemoryTracker.hpp:
  153:   // Move virtual memory from one memory type to another.
  154:   // Virtual memory can be reserved before it is associated with a memory type, and tagged
  156:   // type to specified memory type.
  394:   static bool split_reserved_region(address addr, size_t size, size_t split, MemTag mem_tag, MemTag split_type);

Source root ? src/hotspot/share/nmt/vmatree.hpp:
  97:       assert(!(type == StateType::Released) || data.mem_tag == mtNone, "Released type must have flag mtNone");

Source root ? src/hotspot/share/prims/whitebox.cpp:
  679: // Alloc memory using the test memory type so that we can use that to see if
  695: // Alloc memory with pseudo call stack and specific memory type.

Source root ? src/hotspot/share/runtime/os.cpp:
  725:     assert(mem_tag == header->mem_tag(), "weird NMT type mismatch (new:"%s" != old:"%s")\n",

Source root ? src/hotspot/share/utilities/bitMap.hpp:
  644:   // NMT memory type

Source root ? src/hotspot/share/utilities/debug.cpp:
  714:     MemTracker::record_virtual_memory_type(page, mtInternal);

Source root ? src/hotspot/share/utilities/growableArray.cpp:
  49:   // memory type has to be specified for C heap allocation
  50:   assert(mem_tag != mtNone, "memory type not specified for C heap object");

Source root ? src/hotspot/share/utilities/resizeableResourceHash.hpp:
  33:     MemTag MEM_TYPE>
  55:       table = NEW_C_HEAP_ARRAY(Node*, table_size, MEM_TYPE);
  75:     MemTag MEM_TYPE = mtInternal,
  80:     ResizeableResourceHashtableStorage<K, V, ALLOC_TYPE, MEM_TYPE>,
  81:     K, V, ALLOC_TYPE, MEM_TYPE, HASH, EQUALS> {
  84:   using BASE = ResourceHashtableBase<ResizeableResourceHashtableStorage<K, V, ALLOC_TYPE, MEM_TYPE>,
  85:                                      K, V, ALLOC_TYPE, MEM_TYPE, HASH, EQUALS>;

Source root ? src/hotspot/share/utilities/resourceHash.hpp:
   57:     MemTag MEM_TYPE,
  156:       *ptr = new (MEM_TYPE) Node(hv, key, value, *ptr);
  177:         *ptr = new (MEM_TYPE) Node(hv, key, value);
  196:         *ptr = new (MEM_TYPE) Node(hv, key);
  218:         *ptr = new (MEM_TYPE) Node(hv, key, value);

The `MemTracker::record_virtual_memory_type` can be changed to `MemTracker::record_virtual_memory_tag`

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

PR Review: https://git.openjdk.org/jdk/pull/20872#pullrequestreview-2300326979
PR Review: https://git.openjdk.org/jdk/pull/20872#pullrequestreview-2300332293

From wkemper at openjdk.org  Thu Sep 12 14:26:48 2024
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 12 Sep 2024 14:26:48 GMT
Subject: RFR: Merge openjdk/jdk21u-dev:master
Message-ID: <9NjJjnkifvMcXpl0DxrYaU2oC59ZkIAT98_AG2IB0MU=.4d7c9520-f587-4639-9c67-7ddccade29f2@github.com>

Merges tag jdk-21.0.5+7

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

Commit messages:
 - 8338696: (fs) BasicFileAttributes.creationTime() falls back to epoch if birth time is unavailable (Linux)
 - 8337664: Distrust TLS server certificates issued after Oct 2024 and anchored by Entrust Root CAs
 - 8338139: {ClassLoading,Memory}MXBean::isVerbose methods are inconsistent with their setVerbose methods

The merge commit only contains trivial merges, so no merge-specific webrevs have been generated.

Changes: https://git.openjdk.org/shenandoah-jdk21u/pull/77/files
  Stats: 1328 lines in 20 files changed: 1311 ins; 2 del; 15 mod
  Patch: https://git.openjdk.org/shenandoah-jdk21u/pull/77.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah-jdk21u.git pull/77/head:pull/77

PR: https://git.openjdk.org/shenandoah-jdk21u/pull/77

From gziemski at openjdk.org  Thu Sep 12 15:21:37 2024
From: gziemski at openjdk.org (Gerard Ziemski)
Date: Thu, 12 Sep 2024 15:21:37 GMT
Subject: RFR: 8337563: NMT: rename MEMFLAGS to MemTag [v8]
In-Reply-To: <aQDgRwE-H5U0lz8wooLBAQZsuDnB5zZzjMhheIu3y9Y=.0bae7ae4-062e-47de-b7c3-4fedc5d7e20a@github.com>
References: <aQDgRwE-H5U0lz8wooLBAQZsuDnB5zZzjMhheIu3y9Y=.0bae7ae4-062e-47de-b7c3-4fedc5d7e20a@github.com>
Message-ID: <eokrqjAovPXokoW5OJR2OHXQml4YB5Aqmk6DaOcMoKA=.ccfc0135-cfc3-4c9e-a1b7-811b49966554@github.com>

> Please review this cleanup, where we rename `MEMFLAGS` to `MemTag`.
> 
> `MEMFLAGS` implies that we can use more than one at the same time, but those are exclusive values, so `MemTag` is a more suitable name.
> 
> This fix also includes a cleanup of all the related function/template parameter names and local variable names.
> 
> Testing is pending...
> 
> Note: there is more history in old closed PRs [https://github.com/openjdk/jdk/pull/20497](https://github.com/openjdk/jdk/pull/20497) and [https://github.com/openjdk/jdk/pull/20472](https://github.com/openjdk/jdk/pull/20472)

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

  Johan's feedback

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20872/files
  - new: https://git.openjdk.org/jdk/pull/20872/files/f1faba35..4c7f181d

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

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

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

From gziemski at openjdk.org  Thu Sep 12 15:21:37 2024
From: gziemski at openjdk.org (Gerard Ziemski)
Date: Thu, 12 Sep 2024 15:21:37 GMT
Subject: RFR: 8337563: NMT: rename MEMFLAGS to MemTag [v8]
In-Reply-To: <7JNLDZV1F6_QuMJSq-pu08lFSEULMe41bpQDucXEoEw=.8c051b63-24eb-451d-a2b2-04e8926638c1@github.com>
References: <aQDgRwE-H5U0lz8wooLBAQZsuDnB5zZzjMhheIu3y9Y=.0bae7ae4-062e-47de-b7c3-4fedc5d7e20a@github.com>
 <XNRFNQoz26gPhgG5XSzcbcYiC0RlNv6MPdNI1K1hlkI=.f4bd698b-e546-440f-8c50-b8af375526e5@github.com>
 <rZ4cPC-wYedzPN0zvxYYXAsPalIXURfFRvPCxEYy4w0=.31b59b94-e445-4536-be9e-238b19dca091@github.com>
 <7JNLDZV1F6_QuMJSq-pu08lFSEULMe41bpQDucXEoEw=.8c051b63-24eb-451d-a2b2-04e8926638c1@github.com>
Message-ID: <AIYz3LuairmXPz65uBRKZYFC-GUIx4CvnvlUAV0tRFU=.70708c69-6dcc-418b-85f5-ad29e9ad07fc@github.com>

On Thu, 12 Sep 2024 11:54:49 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> src/hotspot/share/gc/shenandoah/shenandoahTaskqueue.inline.hpp line 2:
>> 
>>> 1: /*
>>> 2:  * Copyright (c) 2016, 2019, Red Hat, Inc. All rights reserved.
>> 
>> I don't think we're meant to update other companies' copyrights?
>
> That is correct - unless requested by someone representing that copyright owner.

Fixed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20872#discussion_r1757091561

From gziemski at openjdk.org  Thu Sep 12 15:27:11 2024
From: gziemski at openjdk.org (Gerard Ziemski)
Date: Thu, 12 Sep 2024 15:27:11 GMT
Subject: RFR: 8337563: NMT: rename MEMFLAGS to MemTag [v7]
In-Reply-To: <ZNoKx37DAFcCS1LgNn4wQO7kwWa16mSfODJKuFcHUl4=.05a1cc8d-f189-4554-8bc0-45744c7aa000@github.com>
References: <aQDgRwE-H5U0lz8wooLBAQZsuDnB5zZzjMhheIu3y9Y=.0bae7ae4-062e-47de-b7c3-4fedc5d7e20a@github.com>
 <XNRFNQoz26gPhgG5XSzcbcYiC0RlNv6MPdNI1K1hlkI=.f4bd698b-e546-440f-8c50-b8af375526e5@github.com>
 <ZNoKx37DAFcCS1LgNn4wQO7kwWa16mSfODJKuFcHUl4=.05a1cc8d-f189-4554-8bc0-45744c7aa000@github.com>
Message-ID: <UkOVJ_b0PI2ZZVnRgxV-Yq09mh5bBEXoysYQPg0aanI=.efaca2ee-ec8f-4fdf-a44d-c849a1846915@github.com>

On Wed, 11 Sep 2024 14:03:17 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

>> Gerard Ziemski has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Coleen's feedback
>
> Are we sure we want `mt` for non-type parameter name in templates? We have these existing patterns already in our code:
> 
> 
> src/hotspot/share/utilities/growableArray.hpp:803:template <typename E, MemTag MT>
> src/hotspot/share/utilities/stack.hpp:54:template <class E, MemTag MT> class StackIterator;
> src/hotspot/share/utilities/concurrentHashTable.inline.hpp:78:template <typename CONFIG, MemTag MT>
> src/hotspot/share/utilities/chunkedList.hpp:31:template <class T, MemTag MT> class ChunkedList : public CHeapObj<MT> 
> src/hotspot/share/gc/g1/g1BatchedTask.hpp:32:template <typename E, MemTag MT>
> src/hotspot/share/gc/shared/taskqueue.hpp:119:template <unsigned int N, MemTag MT>
> src/hotspot/share/gc/shared/taskqueue.hpp:327:template <class E, MemTag MT, unsigned int N = TASKQUEUE_SIZE>
> src/hotspot/share/gc/shenandoah/shenandoahTaskqueue.hpp:40:template<class E, MemTag MT, unsigned int N = TASKQUEUE_SIZE>
> src/hotspot/share/nmt/arrayWithFreeList.hpp:34:template<typename E, MemTag MT>
> 
> 
> With mt they would look like:
> 
> 
> src/hotspot/share/utilities/growableArray.hpp:803:template <typename E, MemTag mt>
> src/hotspot/share/utilities/stack.hpp:54:template <class E, MemTag mt> class StackIterator;
> src/hotspot/share/utilities/concurrentHashTable.inline.hpp:78:template <typename CONFIG, MemTag mt>
> src/hotspot/share/utilities/chunkedList.hpp:31:template <class T, MemTag mt> class ChunkedList : public CHeapObj<mt> 
> src/hotspot/share/gc/g1/g1BatchedTask.hpp:32:template <typename E, MemTag mt>
> src/hotspot/share/gc/shared/taskqueue.hpp:119:template <unsigned int N, MemTag mt>
> src/hotspot/share/gc/shared/taskqueue.hpp:327:template <class E, MemTag mt, unsigned int N = TASKQUEUE_SIZE>
> src/hotspot/share/gc/shenandoah/shenandoahTaskqueue.hpp:40:template<class E, MemTag mt, unsigned int N = TASKQUEUE_SIZE>
> src/hotspot/share/nmt/arrayWithFreeList.hpp:34:template<typename E, MemTag mt>
> 
> 
> So `MT` or `mt` for non-type parameter name in templates, or should I punt on this particular change and leave it for a followup?

> Thank you @gerard-ziemski, for this huge change. After this change, the code looks much more nicer and consistent.
> 
> If we are insisting on replacing `flag` with `tag`, I could find these missed ones by regexp search for `mem.*flag`:
> 
> 7 results - 5 files
> 
> Source root ? src/hotspot/share/nmt/memMapPrinter.cpp: `83: // A Cache that correlates range with MEMFLAG, optimized to be iterated quickly`
> 
> Source root ? src/hotspot/share/nmt/memTracker.hpp: `208: // memory flags of the original region.`
> 
> Source root ? src/hotspot/share/nmt/vmatree.hpp:
> 
> `97: assert(!(type == StateType::Released) || data.mem_tag == mtNone, "Released type must have flag mtNone");`
> 
> `108: return static_cast<MemTag>(type_flag[1]);`
> 
> Source root ? test/hotspot/gtest/nmt/test_nmt_reserved_region.cpp: `50: ASSERT_EQ(region2.mem_tag(), mtThreadStack); // Should be correct flag`
> 
> Source root ? test/hotspot/gtest/nmt/test_vmatree.cpp:
> 
> `435: const MemTag candidate_flags[candidates_len_flags] = {`
> 
> `459: const MemTag mem_tag = candidate_flags[os::random() % candidates_len_flags];`

Thank you Ashfin for laking such a detailed look and providing the feedback.

I fixed the issues, except:

`108:       return static_cast<MemTag>(type_flag[1]);`
This actually has more than just MemTag, it also has StateType, so I left it as is.

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

PR Comment: https://git.openjdk.org/jdk/pull/20872#issuecomment-2346602184

From gziemski at openjdk.org  Thu Sep 12 15:32:57 2024
From: gziemski at openjdk.org (Gerard Ziemski)
Date: Thu, 12 Sep 2024 15:32:57 GMT
Subject: RFR: 8337563: NMT: rename MEMFLAGS to MemTag [v9]
In-Reply-To: <aQDgRwE-H5U0lz8wooLBAQZsuDnB5zZzjMhheIu3y9Y=.0bae7ae4-062e-47de-b7c3-4fedc5d7e20a@github.com>
References: <aQDgRwE-H5U0lz8wooLBAQZsuDnB5zZzjMhheIu3y9Y=.0bae7ae4-062e-47de-b7c3-4fedc5d7e20a@github.com>
Message-ID: <95R2iRDLQWj7eiaXmYoqXFx_I0mDr3ORuQOsb111O6o=.1a5580ec-b6d8-4b3f-b324-141eb843a408@github.com>

> Please review this cleanup, where we rename `MEMFLAGS` to `MemTag`.
> 
> `MEMFLAGS` implies that we can use more than one at the same time, but those are exclusive values, so `MemTag` is a more suitable name.
> 
> This fix also includes a cleanup of all the related function/template parameter names and local variable names.
> 
> Testing is pending...
> 
> Note: there is more history in old closed PRs [https://github.com/openjdk/jdk/pull/20497](https://github.com/openjdk/jdk/pull/20497) and [https://github.com/openjdk/jdk/pull/20472](https://github.com/openjdk/jdk/pull/20472)

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

  Afshin's feedback

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20872/files
  - new: https://git.openjdk.org/jdk/pull/20872/files/4c7f181d..8e576cf1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20872&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20872&range=07-08

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

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

From gziemski at openjdk.org  Thu Sep 12 15:40:35 2024
From: gziemski at openjdk.org (Gerard Ziemski)
Date: Thu, 12 Sep 2024 15:40:35 GMT
Subject: RFR: 8337563: NMT: rename MEMFLAGS to MemTag [v10]
In-Reply-To: <aQDgRwE-H5U0lz8wooLBAQZsuDnB5zZzjMhheIu3y9Y=.0bae7ae4-062e-47de-b7c3-4fedc5d7e20a@github.com>
References: <aQDgRwE-H5U0lz8wooLBAQZsuDnB5zZzjMhheIu3y9Y=.0bae7ae4-062e-47de-b7c3-4fedc5d7e20a@github.com>
Message-ID: <O0OSPCK8ecBblZ3jaOH2VvMVxC9kRgBaumXHBnf7a3Q=.3d1f8c51-de2b-4026-8393-bd6f9659252b@github.com>

> Please review this cleanup, where we rename `MEMFLAGS` to `MemTag`.
> 
> `MEMFLAGS` implies that we can use more than one at the same time, but those are exclusive values, so `MemTag` is a more suitable name.
> 
> This fix also includes a cleanup of all the related function/template parameter names and local variable names.
> 
> Testing is pending...
> 
> Note: there is more history in old closed PRs [https://github.com/openjdk/jdk/pull/20497](https://github.com/openjdk/jdk/pull/20497) and [https://github.com/openjdk/jdk/pull/20472](https://github.com/openjdk/jdk/pull/20472)

Gerard Ziemski has updated the pull request incrementally with two additional commits since the last revision:

 - Afshin's feedback, record_virtual_memory_type -> record_virtual_memory_tag
 - Afshin's feedback

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20872/files
  - new: https://git.openjdk.org/jdk/pull/20872/files/8e576cf1..1765579b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20872&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20872&range=08-09

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

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

From gziemski at openjdk.org  Thu Sep 12 15:40:35 2024
From: gziemski at openjdk.org (Gerard Ziemski)
Date: Thu, 12 Sep 2024 15:40:35 GMT
Subject: RFR: 8337563: NMT: rename MEMFLAGS to MemTag [v7]
In-Reply-To: <S4c0iHbwhtK3dst5MjhIA5AdhNMGWPs9BA2IjDcfQj4=.f5e3cad1-b2fb-49f0-91c2-465063295db1@github.com>
References: <aQDgRwE-H5U0lz8wooLBAQZsuDnB5zZzjMhheIu3y9Y=.0bae7ae4-062e-47de-b7c3-4fedc5d7e20a@github.com>
 <XNRFNQoz26gPhgG5XSzcbcYiC0RlNv6MPdNI1K1hlkI=.f4bd698b-e546-440f-8c50-b8af375526e5@github.com>
 <S4c0iHbwhtK3dst5MjhIA5AdhNMGWPs9BA2IjDcfQj4=.f5e3cad1-b2fb-49f0-91c2-465063295db1@github.com>
Message-ID: <FqF3hy9KJ_mkQhfRtDQ0IprJoFtq5p8b8IOMuXveSuY=.7519cb61-d82e-4aea-afc6-a2f2191bc3a9@github.com>

On Thu, 12 Sep 2024 13:31:28 GMT, Afshin Zafari <azafari at openjdk.org> wrote:

> ## Again, if we want to replace mem type with mem tag. The regexp search for mem.*type gives this:
> 47 results - 19 files

Done.

> The `MemTracker::record_virtual_memory_type` can be changed to `MemTracker::record_virtual_memory_tag`

Done.

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

PR Comment: https://git.openjdk.org/jdk/pull/20872#issuecomment-2346629838
PR Comment: https://git.openjdk.org/jdk/pull/20872#issuecomment-2346630233

From gziemski at openjdk.org  Thu Sep 12 15:40:35 2024
From: gziemski at openjdk.org (Gerard Ziemski)
Date: Thu, 12 Sep 2024 15:40:35 GMT
Subject: RFR: 8337563: NMT: rename MEMFLAGS to MemTag [v9]
In-Reply-To: <95R2iRDLQWj7eiaXmYoqXFx_I0mDr3ORuQOsb111O6o=.1a5580ec-b6d8-4b3f-b324-141eb843a408@github.com>
References: <aQDgRwE-H5U0lz8wooLBAQZsuDnB5zZzjMhheIu3y9Y=.0bae7ae4-062e-47de-b7c3-4fedc5d7e20a@github.com>
 <95R2iRDLQWj7eiaXmYoqXFx_I0mDr3ORuQOsb111O6o=.1a5580ec-b6d8-4b3f-b324-141eb843a408@github.com>
Message-ID: <2CL9dG3e4T5eoAgDFZxD04BewQlYQm8kE5auIOIoewM=.05bef75b-de33-458c-9700-20a2171c5e20@github.com>

On Thu, 12 Sep 2024 15:32:57 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

>> Please review this cleanup, where we rename `MEMFLAGS` to `MemTag`.
>> 
>> `MEMFLAGS` implies that we can use more than one at the same time, but those are exclusive values, so `MemTag` is a more suitable name.
>> 
>> This fix also includes a cleanup of all the related function/template parameter names and local variable names.
>> 
>> Testing is pending...
>> 
>> Note: there is more history in old closed PRs [https://github.com/openjdk/jdk/pull/20497](https://github.com/openjdk/jdk/pull/20497) and [https://github.com/openjdk/jdk/pull/20472](https://github.com/openjdk/jdk/pull/20472)
>
> Gerard Ziemski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Afshin's feedback

Thank you Afshin again for taking detailed look.

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

PR Comment: https://git.openjdk.org/jdk/pull/20872#issuecomment-2346633208

From stuefe at openjdk.org  Thu Sep 12 15:41:22 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 12 Sep 2024 15:41:22 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v13]
In-Reply-To: <xnL42l4bz2SaiEgSVCDBXXbnZqgnIcYpnSy7tM2WY1w=.094f34bb-4587-4c45-ad44-daf83705515a@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <4iHDH-GpSa-uPqe0IwwP6notHRyrOTiecqCSX9kYCe0=.d7969fd0-3066-42fa-82d4-842c10baee1c@github.com>
 <xnL42l4bz2SaiEgSVCDBXXbnZqgnIcYpnSy7tM2WY1w=.094f34bb-4587-4c45-ad44-daf83705515a@github.com>
Message-ID: <jqZ-1tR0WMbnDldGMusdqMnswTGj1hbOIY3JdUFtIsM=.4169760d-d5cf-4335-9e53-baf885d9422f@github.com>

On Thu, 12 Sep 2024 10:17:47 GMT, Roberto Casta?eda Lozano <rcastanedalo at openjdk.org> wrote:

>> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revert accidental change of UCOH default
>
> src/hotspot/share/opto/lcm.cpp line 272:
> 
>> 270:         const TypePtr* tptr;
>> 271:         if ((UseCompressedOops || UseCompressedClassPointers) &&
>> 272:             (CompressedOops::shift() == 0 || CompressedKlassPointers::shift() == 0)) {
> 
> Could you explain this change? It seems like it may affect C2's implicit null check analysis even for `-XX:-UseCompactObjectHeaders`. In particular, for the following configurations, the changed condition evaluates to true before the change and false after it, regardless of whether `UseCompactObjectHeaders` is enabled:
> 
> (!UseCompressedOops,  UseCompressedClassPointers, CompressedKlassPointers::shift() != 0)
> ( UseCompressedOops, !UseCompressedClassPointers, CompressedOops::shift() != 0)

Hi @robcasloz 

The `CompressedKlassPointers` utility class is not usable anymore with `-UseCompressedClassPointers`. One change is that if `UseCompressedClassPointers` is off, `CompressedKlassPointers` stays uninitialized. And that makes more sense then to rely on the static initialization values of `CompressedOops::_shift`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1757126946

From gziemski at openjdk.org  Thu Sep 12 15:45:11 2024
From: gziemski at openjdk.org (Gerard Ziemski)
Date: Thu, 12 Sep 2024 15:45:11 GMT
Subject: RFR: 8337563: NMT: rename MEMFLAGS to MemTag [v9]
In-Reply-To: <95R2iRDLQWj7eiaXmYoqXFx_I0mDr3ORuQOsb111O6o=.1a5580ec-b6d8-4b3f-b324-141eb843a408@github.com>
References: <aQDgRwE-H5U0lz8wooLBAQZsuDnB5zZzjMhheIu3y9Y=.0bae7ae4-062e-47de-b7c3-4fedc5d7e20a@github.com>
 <95R2iRDLQWj7eiaXmYoqXFx_I0mDr3ORuQOsb111O6o=.1a5580ec-b6d8-4b3f-b324-141eb843a408@github.com>
Message-ID: <cqM-GyZsgQaH17Uj1WmShkxW2RCM-oZqH9mLzV71fYk=.15a56ee9-0c88-4738-b148-72bffa651243@github.com>

On Thu, 12 Sep 2024 15:32:57 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

>> Please review this cleanup, where we rename `MEMFLAGS` to `MemTag`.
>> 
>> `MEMFLAGS` implies that we can use more than one at the same time, but those are exclusive values, so `MemTag` is a more suitable name.
>> 
>> This fix also includes a cleanup of all the related function/template parameter names and local variable names.
>> 
>> Testing is pending...
>> 
>> Note: there is more history in old closed PRs [https://github.com/openjdk/jdk/pull/20497](https://github.com/openjdk/jdk/pull/20497) and [https://github.com/openjdk/jdk/pull/20472](https://github.com/openjdk/jdk/pull/20472)
>
> Gerard Ziemski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Afshin's feedback

I have incorporated Afshin feedback, but can revert the changes and punt them to a followup if there is a pushback against doing it right now.

I think that we are now in pretty good shape. I could use final approvals, with anything that's not critical to be done in followup(s) later.

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

PR Comment: https://git.openjdk.org/jdk/pull/20872#issuecomment-2346637453

From gziemski at openjdk.org  Thu Sep 12 15:45:12 2024
From: gziemski at openjdk.org (Gerard Ziemski)
Date: Thu, 12 Sep 2024 15:45:12 GMT
Subject: RFR: 8337563: NMT: rename MEMFLAGS to MemTag [v10]
In-Reply-To: <O0OSPCK8ecBblZ3jaOH2VvMVxC9kRgBaumXHBnf7a3Q=.3d1f8c51-de2b-4026-8393-bd6f9659252b@github.com>
References: <aQDgRwE-H5U0lz8wooLBAQZsuDnB5zZzjMhheIu3y9Y=.0bae7ae4-062e-47de-b7c3-4fedc5d7e20a@github.com>
 <O0OSPCK8ecBblZ3jaOH2VvMVxC9kRgBaumXHBnf7a3Q=.3d1f8c51-de2b-4026-8393-bd6f9659252b@github.com>
Message-ID: <4uTuyYrAIeQPJf1I0_5GPU4-3kAAcKOQdSk3dPrIS6s=.62fd59ea-c1a7-44bd-a4ad-482a9d252cf3@github.com>

On Thu, 12 Sep 2024 15:40:35 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

>> Please review this cleanup, where we rename `MEMFLAGS` to `MemTag`.
>> 
>> `MEMFLAGS` implies that we can use more than one at the same time, but those are exclusive values, so `MemTag` is a more suitable name.
>> 
>> This fix also includes a cleanup of all the related function/template parameter names and local variable names.
>> 
>> Testing is pending...
>> 
>> Note: there is more history in old closed PRs [https://github.com/openjdk/jdk/pull/20497](https://github.com/openjdk/jdk/pull/20497) and [https://github.com/openjdk/jdk/pull/20472](https://github.com/openjdk/jdk/pull/20472)
>
> Gerard Ziemski has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Afshin's feedback, record_virtual_memory_type -> record_virtual_memory_tag
>  - Afshin's feedback

Johan's incremental feedback:

https://openjdk.github.io/cr/?repo=jdk&pr=20872&range=06-07

Afshin's incremental feedback:

https://openjdk.github.io/cr/?repo=jdk&pr=20872&range=07-08
https://openjdk.github.io/cr/?repo=jdk&pr=20872&range=08-09

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

PR Comment: https://git.openjdk.org/jdk/pull/20872#issuecomment-2346643064

From stuefe at openjdk.org  Thu Sep 12 15:46:17 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 12 Sep 2024 15:46:17 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v13]
In-Reply-To: <GQVVR0K-mDh4evKvrKG9eXwwF4j7zAg-8ai4__gWNGE=.3c502820-717b-44b7-b82d-a24dd7fdd9d5@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <DUgk6HT_Zk5KnbmAd_HzrJi4B8D1J-uuoAGzReWyI8s=.6c04f90a-bf1d-49af-a31d-5224973952d4@github.com>
 <GQVVR0K-mDh4evKvrKG9eXwwF4j7zAg-8ai4__gWNGE=.3c502820-717b-44b7-b82d-a24dd7fdd9d5@github.com>
Message-ID: <-CikzUsH1qKbMujGJQFhaPlKaCUDzqH-jEZNM5BZVQQ=.22d236a1-a69a-42e0-86d1-aa738c6e6e6d@github.com>

On Wed, 11 Sep 2024 14:47:07 GMT, Roberto Casta?eda Lozano <rcastanedalo at openjdk.org> wrote:

>> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revert accidental change of UCOH default
>
> src/hotspot/share/opto/machnode.cpp line 390:
> 
>> 388:     t = t->make_ptr();
>> 389:   }
>> 390:   if (t->isa_narrowklass() && CompressedKlassPointers::shift() == 0) {
> 
> Does this change have any effect? `UseCompressedClassPointers` should be implied by `t->isa_narrowklass()`.

I don't remember if this change was a reaction to an error or if I just guarded `CompressedKlassPointers::shift()` with +UseCCP because that is the prerequisite now. Probably the latter. I can remove this. Probably should assert then for +UseCCP.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1757135035

From gziemski at openjdk.org  Thu Sep 12 15:52:41 2024
From: gziemski at openjdk.org (Gerard Ziemski)
Date: Thu, 12 Sep 2024 15:52:41 GMT
Subject: RFR: 8337563: NMT: rename MEMFLAGS to MemTag [v11]
In-Reply-To: <aQDgRwE-H5U0lz8wooLBAQZsuDnB5zZzjMhheIu3y9Y=.0bae7ae4-062e-47de-b7c3-4fedc5d7e20a@github.com>
References: <aQDgRwE-H5U0lz8wooLBAQZsuDnB5zZzjMhheIu3y9Y=.0bae7ae4-062e-47de-b7c3-4fedc5d7e20a@github.com>
Message-ID: <1Io2b9D2fXcUlf-VyTzgeqloWFuGNUh6T1wXzROJHgc=.8373bbd4-3aa9-4865-acc8-5f046607d052@github.com>

> Please review this cleanup, where we rename `MEMFLAGS` to `MemTag`.
> 
> `MEMFLAGS` implies that we can use more than one at the same time, but those are exclusive values, so `MemTag` is a more suitable name.
> 
> This fix also includes a cleanup of all the related function/template parameter names and local variable names.
> 
> Testing is pending...
> 
> Note: there is more history in old closed PRs [https://github.com/openjdk/jdk/pull/20497](https://github.com/openjdk/jdk/pull/20497) and [https://github.com/openjdk/jdk/pull/20472](https://github.com/openjdk/jdk/pull/20472)

Gerard Ziemski has updated the pull request incrementally with two additional commits since the last revision:

 - copyrights
 - Afshin's feedback, tests

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20872/files
  - new: https://git.openjdk.org/jdk/pull/20872/files/1765579b..7db989f3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20872&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20872&range=09-10

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

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

From coleenp at openjdk.org  Thu Sep 12 16:01:15 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 12 Sep 2024 16:01:15 GMT
Subject: RFR: 8337563: NMT: rename MEMFLAGS to MemTag [v11]
In-Reply-To: <1Io2b9D2fXcUlf-VyTzgeqloWFuGNUh6T1wXzROJHgc=.8373bbd4-3aa9-4865-acc8-5f046607d052@github.com>
References: <aQDgRwE-H5U0lz8wooLBAQZsuDnB5zZzjMhheIu3y9Y=.0bae7ae4-062e-47de-b7c3-4fedc5d7e20a@github.com>
 <1Io2b9D2fXcUlf-VyTzgeqloWFuGNUh6T1wXzROJHgc=.8373bbd4-3aa9-4865-acc8-5f046607d052@github.com>
Message-ID: <4rSXUED92zoCWNuvkwpyNsA50elNxX2BquvOmwZf8HA=.5811acf9-38eb-458a-b4bf-02a7176c36bc@github.com>

On Thu, 12 Sep 2024 15:52:41 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

>> Please review this cleanup, where we rename `MEMFLAGS` to `MemTag`.
>> 
>> `MEMFLAGS` implies that we can use more than one at the same time, but those are exclusive values, so `MemTag` is a more suitable name.
>> 
>> This fix also includes a cleanup of all the related function/template parameter names and local variable names.
>> 
>> Testing is pending...
>> 
>> Note: there is more history in old closed PRs [https://github.com/openjdk/jdk/pull/20497](https://github.com/openjdk/jdk/pull/20497) and [https://github.com/openjdk/jdk/pull/20472](https://github.com/openjdk/jdk/pull/20472)
>
> Gerard Ziemski has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - copyrights
>  - Afshin's feedback, tests

This looks good to me. Thanks for finding some additional cases, Afshin.  Thanks also for  updating the copyrights.  Thanks for this effort for consensus and for the change, Gerard.

Edit: please let GHA complete.

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

Marked as reviewed by coleenp (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20872#pullrequestreview-2300775940

From stuefe at openjdk.org  Thu Sep 12 16:08:15 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 12 Sep 2024 16:08:15 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v8]
In-Reply-To: <vt3oD_XW4eFNTnPYoSa0-TZiEsFtBXJKfPdsIoqVuXM=.7e14c4df-4c66-4f52-9a59-e86fbcb6e7d9@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <J0g0PSye768dhN3JoXFsZ6FivocNBLPmHNtRUCOmLTw=.5756c64a-4763-4727-9637-ba3fe7b9b17d@github.com>
 <vt3oD_XW4eFNTnPYoSa0-TZiEsFtBXJKfPdsIoqVuXM=.7e14c4df-4c66-4f52-9a59-e86fbcb6e7d9@github.com>
Message-ID: <N10Px5txoEoXh2oO1BEYEhSY7gysOWtYjuBxFg_DArk=.fad5b9e3-f602-445a-aa34-180ebe1fd52a@github.com>

On Mon, 9 Sep 2024 15:58:29 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Roman Kennke has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Try to avoid lea in loadNklass (aarch64)
>>  - Fix release build error
>
> src/hotspot/cpu/aarch64/compressedKlass_aarch64.cpp line 147:
> 
>> 145: #endif
>> 146: 
>> 147:   return true;
> 
> This should only be in the compressedKlass.cpp file.

Okay. I will remove the whole `CompressedKlassPointers::pd_initialize` logic. We only need it for one architecture (aarch) and one case (+UseCCP -UseCOH), so maybe its not worth fanning out across all platforms, including Zero. Instead, I will add a short `ifdef` section to `CompressedKlassPointers::initialize`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1757169570

From kvn at openjdk.org  Thu Sep 12 16:27:06 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Thu, 12 Sep 2024 16:27:06 GMT
Subject: RFR: 8339849: Enumerate opto and C1 stubs, generate enums, names, 
 fields and generator calls [v2]
In-Reply-To: <hWGtayer3iflHjtiVgTEojbZO4a3yaAHyid1FU3wl4Y=.fdb36ddd-db35-4d40-ab8d-9b4b18f419d9@github.com>
References: <gmeZu6egkzf71-hoDOcrK8hql0DJ0rdnAr_D0IcE9tc=.7d9cab12-4009-4cf3-8373-dac7eef9f398@github.com>
 <hWGtayer3iflHjtiVgTEojbZO4a3yaAHyid1FU3wl4Y=.fdb36ddd-db35-4d40-ab8d-9b4b18f419d9@github.com>
Message-ID: <1vBtvFxhbgRFLjlz9vEpAlZKmWC8fvsj1b7qgjE8300=.b2092892-11fd-46d6-ab8a-7ffaa9d7b7af@github.com>

On Thu, 12 Sep 2024 12:40:22 GMT, Andrew Dinn <adinn at openjdk.org> wrote:

>> Systematize handling of Opto and C1 stubs. Generate enum ids, static fields, stub/blob names and generator code from declarations using template macros as previously done with Shared stubs. Systematically reference stubs and stub names using ids.
>
> Andrew Dinn has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Answer review feedback
>  - remove commented out old code

Good.

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

Marked as reviewed by kvn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20936#pullrequestreview-2300845145

From coleenp at openjdk.org  Thu Sep 12 17:37:15 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 12 Sep 2024 17:37:15 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v8]
In-Reply-To: <N10Px5txoEoXh2oO1BEYEhSY7gysOWtYjuBxFg_DArk=.fad5b9e3-f602-445a-aa34-180ebe1fd52a@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <J0g0PSye768dhN3JoXFsZ6FivocNBLPmHNtRUCOmLTw=.5756c64a-4763-4727-9637-ba3fe7b9b17d@github.com>
 <vt3oD_XW4eFNTnPYoSa0-TZiEsFtBXJKfPdsIoqVuXM=.7e14c4df-4c66-4f52-9a59-e86fbcb6e7d9@github.com>
 <N10Px5txoEoXh2oO1BEYEhSY7gysOWtYjuBxFg_DArk=.fad5b9e3-f602-445a-aa34-180ebe1fd52a@github.com>
Message-ID: <CT8NA5dTl_1inuqDp7v8-SFLzfRqW35LRYMh4FnASnc=.91f561db-d5a7-4f25-bcef-da5a1fb7cb11@github.com>

On Thu, 12 Sep 2024 16:04:45 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> src/hotspot/cpu/aarch64/compressedKlass_aarch64.cpp line 147:
>> 
>>> 145: #endif
>>> 146: 
>>> 147:   return true;
>> 
>> This should only be in the compressedKlass.cpp file.
>
> Okay. I will remove the whole `CompressedKlassPointers::pd_initialize` logic. We only need it for one architecture (aarch) and one case (+UseCCP -UseCOH), so maybe its not worth fanning out across all platforms, including Zero. Instead, I will add a short `ifdef` section to `CompressedKlassPointers::initialize`.

Yes, looking at this further, it does seem like a small amount of conditional compilation that sets all the same values that are set in the architecture independent version.  It seems best to move it there.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1757300544

From kdnilsen at openjdk.org  Thu Sep 12 20:26:25 2024
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Thu, 12 Sep 2024 20:26:25 GMT
Subject: RFR: 8339960: GenShen: Fix inconsistencies in generational
 Shenandoah behavior
In-Reply-To: <nkTG6LMW3beBVR1J7gAsmKFULB9tbjfvq_5AqgC2Cyc=.5272fcd5-1c94-48eb-bb80-c606662d81a9@github.com>
References: <jgNu9Ijgc-5vBhFQrcRy-y14tffgH1sqAHlI8byFOJg=.8be61718-9d62-45f3-b55a-375da8ecea54@github.com>
 <eBdgoNx_fVyiNHmLqHqDkOx-ScPtTwZeM2KNNEXnFkc=.337aabbc-4191-4b82-9db2-14cffb783288@github.com>
 <nkTG6LMW3beBVR1J7gAsmKFULB9tbjfvq_5AqgC2Cyc=.5272fcd5-1c94-48eb-bb80-c606662d81a9@github.com>
Message-ID: <lbCh5rx0-qXdgH7wy0UNlp4-sYfHGyH_isDvI8BFM2k=.bbf3f302-4977-48c9-ab0b-5ee05f1b1b95@github.com>

On Wed, 11 Sep 2024 16:37:02 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp line 1428:
>> 
>>> 1426:                 old_collector_regions, old_collector_used);
>>> 1427: 
>>> 1428:   idx_t rightmost_idx = (mutator_leftmost == max_regions)? -1: (idx_t) mutator_rightmost;
>> 
>> Does this also affect upstream? Should we have a non-genshen patch too?
>
> We should do this upstream as well.  (or it will go upstream when we merge, but that might take a while). I wanted to test and integrate "quickly" into our internal test distribution.

See https://github.com/openjdk/jdk/pull/20974

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

PR Review Comment: https://git.openjdk.org/shenandoah/pull/497#discussion_r1757535526

From wkemper at openjdk.org  Thu Sep 12 20:26:53 2024
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 12 Sep 2024 20:26:53 GMT
Subject: RFR: Merge openjdk/jdk:master
Message-ID: <-xgHZQZ7LpFfBspEVezFI5Lru3TXDxH9M-AExzZPlOs=.17c3a1db-0347-40be-bc04-dba08e5e36b0@github.com>

Merges tag jdk-24+15

## Notes:
* CDS support is disabled for generational mode, pending: https://bugs.openjdk.org/browse/JDK-8339182
* make_regular_bypass has been modified to maintain humongous waste accounting

## Testing
GHA, internal pipelines

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

Commit messages:
 - Merge remote-tracking branch 'shenandoah/master' into merge-jdk-24+N
 - Merge tag 'jdk-24+15' into merge-jdk-24+N
 - 8334165: Remove serialVersionUID compatibility logic from JMX
 - 8339733: C2: some nodes can have incorrect control after do_range_check()
 - 8339731: java.desktop/share/classes/javax/swing/text/html/default.css typo in margin settings
 - 8339159: api/java_rmi/Naming/Rebind.html crashes with SEGV from UTF8::quoted_ascii_length call
 - 8339835: Replace usages of -mx and -ms in some client-libs tests
 - 8339834: Replace usages of -mx and -ms in some tests
 - 8339678: Update runtime/condy tests to be executed with VM flags
 - 8299419: Thread.sleep(millis) may throw OOME
 - ... and 300 more: https://git.openjdk.org/shenandoah/compare/b7405b19...cc04604a

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

Changes: https://git.openjdk.org/shenandoah/pull/498/files
  Stats: 44820 lines in 1351 files changed: 27369 ins; 10467 del; 6984 mod
  Patch: https://git.openjdk.org/shenandoah/pull/498.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah.git pull/498/head:pull/498

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

From wkemper at openjdk.org  Thu Sep 12 20:27:26 2024
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 12 Sep 2024 20:27:26 GMT
Subject: RFR: Merge openjdk/jdk:master
In-Reply-To: <hS4FmVLXJUDz0GxkTfuhAkgzNl3JshEwg5RrnZFplrE=.afc12e77-8ea1-4f6b-80b6-24e8cce28ba2@github.com>
References: <hS4FmVLXJUDz0GxkTfuhAkgzNl3JshEwg5RrnZFplrE=.afc12e77-8ea1-4f6b-80b6-24e8cce28ba2@github.com>
Message-ID: <MKl_pY0YxZ5u21NuFzX54P-BFsH4fFR0zQ6ck0Q_N6k=.cc1cfc37-9a05-4463-9989-92eb6d7d08c1@github.com>

On Fri, 6 Sep 2024 14:11:49 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Merges tag jdk-24+14

Superseded by https://github.com/openjdk/shenandoah/pull/498

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

PR Comment: https://git.openjdk.org/shenandoah/pull/494#issuecomment-2347173338

From wkemper at openjdk.org  Thu Sep 12 20:27:26 2024
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 12 Sep 2024 20:27:26 GMT
Subject: Withdrawn: Merge openjdk/jdk:master
In-Reply-To: <hS4FmVLXJUDz0GxkTfuhAkgzNl3JshEwg5RrnZFplrE=.afc12e77-8ea1-4f6b-80b6-24e8cce28ba2@github.com>
References: <hS4FmVLXJUDz0GxkTfuhAkgzNl3JshEwg5RrnZFplrE=.afc12e77-8ea1-4f6b-80b6-24e8cce28ba2@github.com>
Message-ID: <C1jhFTNEX6-Ug1UQboLK5d2Rfcgk4iNhEWQaWsYdt3I=.ca60ca14-d451-4fe3-8a52-2936799f82ef@github.com>

On Fri, 6 Sep 2024 14:11:49 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Merges tag jdk-24+14

This pull request has been closed without being integrated.

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

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

From wkemper at openjdk.org  Thu Sep 12 20:27:32 2024
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 12 Sep 2024 20:27:32 GMT
Subject: RFR: Merge openjdk/jdk:master [v8]
In-Reply-To: <xI8kOvsvL7Zvb-za3-r-zxYHnzXc7fzSUftacr4t3qo=.7dbc2225-a00f-4bf4-852b-ed1999746813@github.com>
References: <SCP1LsF3csnYVFltdHsYkeTRFauWYtyziukewFh7bio=.f20164ac-6ecb-4a84-bfa4-45969db4145e@github.com>
 <xI8kOvsvL7Zvb-za3-r-zxYHnzXc7fzSUftacr4t3qo=.7dbc2225-a00f-4bf4-852b-ed1999746813@github.com>
Message-ID: <kg4lqjYgzeKbGb9hme-5-aCivRC0KMOzWauCPHKNRR0=.f818434c-8fc9-439a-b627-ea739b75c0da@github.com>

On Fri, 30 Aug 2024 22:30:27 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> Merges tag jdk-24+12
>
> William Kemper has updated the pull request incrementally with 43 additional commits since the last revision:
> 
>  - Merge tag 'jdk-24+13' into merge-jdk-24+12
>    
>    Added tag jdk-24+13 for changeset ff59532d
>  - 8338678: Erroneous parameterized type represented as <any>
>    
>    Reviewed-by: vromero
>  - 8324859: Improve error recovery
>    
>    Reviewed-by: mcimadamore
>  - 8327381: Refactor type-improving transformations in BoolNode::Ideal to BoolNode::Value
>    
>    Reviewed-by: chagedorn, thartmann, jkarthikeyan, epeter
>  - 8336873: BasicSplitPaneDivider:oneTouchExpandableChanged() should mention that implementation depends on SplitPane.supportsOneTouchButtons property
>    
>    Reviewed-by: prr, abhiscxk
>  - 8335120: assert(!target->can_be_statically_bound() || target == cha_monomorphic_target) failed
>    
>    Reviewed-by: kvn, vlivanov
>  - 8338716: Re-visit "interrupt handling" in jdk.internal.loader.Resource
>    
>    Reviewed-by: alanb
>  - 8338888: SystemDictionary::class_name_symbol has incorrect length check
>    
>    Reviewed-by: stuefe, kbarrett, coleenp
>  - 8339126: JNI exception pending in Inflater.c
>    
>    Reviewed-by: lancea, vtewari, jpai, naoto
>  - 8258483: [TESTBUG] gtest CollectorPolicy.young_scaled_initial_ergo_vm fails if heap is too small
>    
>    Reviewed-by: ayang
>  - ... and 33 more: https://git.openjdk.org/shenandoah/compare/61ef37a5...2751b362

Superseded by https://github.com/openjdk/shenandoah/pull/498

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

PR Comment: https://git.openjdk.org/shenandoah/pull/483#issuecomment-2347172401

From wkemper at openjdk.org  Thu Sep 12 20:27:32 2024
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 12 Sep 2024 20:27:32 GMT
Subject: Withdrawn: Merge openjdk/jdk:master
In-Reply-To: <SCP1LsF3csnYVFltdHsYkeTRFauWYtyziukewFh7bio=.f20164ac-6ecb-4a84-bfa4-45969db4145e@github.com>
References: <SCP1LsF3csnYVFltdHsYkeTRFauWYtyziukewFh7bio=.f20164ac-6ecb-4a84-bfa4-45969db4145e@github.com>
Message-ID: <As629oCf61eytFMKysVAu-rgRYqtj9LcDrO6VmgGGFk=.48adecc1-1953-4ba0-b7bb-e05f09a18564@github.com>

On Thu, 22 Aug 2024 16:41:09 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Merges tag jdk-24+12

This pull request has been closed without being integrated.

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

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

From kdnilsen at openjdk.org  Thu Sep 12 20:29:39 2024
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Thu, 12 Sep 2024 20:29:39 GMT
Subject: RFR: 8339960: Shenandoah: Fix inconsistencies in generational
 Shenandoah behaviors
Message-ID: <vzXjdQg2wTPzgTG1aU7_CUnAxtnlt_2o01drZXtI324=.100816d9-1ed5-497c-be51-fd540f496cb7@github.com>

This fixes some bugs found in recent code review and playback of an assertion failure.

See also https://github.com/openjdk/shenandoah/pull/497

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

Commit messages:
 - Use -1 for rightmost interval when range is empty
 - Check available rather than capacity before logging shortfall
 - Merge branch 'openjdk:master' into master
 - Merge branch 'openjdk:master' into master
 - Merge branch 'openjdk:master' into master
 - Revert "Make GC logging less verbose"
 - Make GC logging less verbose
 - Merge branch 'openjdk:master' into master
 - Merge branch 'openjdk:master' into master
 - Merge branch 'openjdk:master' into master
 - ... and 13 more: https://git.openjdk.org/jdk/compare/81ff91ef...f1ba63f4

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

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

From wkemper at openjdk.org  Thu Sep 12 20:55:23 2024
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 12 Sep 2024 20:55:23 GMT
Subject: RFR: 8339643: Port JEP 404 to RISC-V
In-Reply-To: <J3I-KZdj2aYAEN7cFFDkuZEpp6WBM7AFaikL14CDdWM=.5f1201e3-3ca2-426e-b6ce-a4bd9aa9a879@github.com>
References: <J3I-KZdj2aYAEN7cFFDkuZEpp6WBM7AFaikL14CDdWM=.5f1201e3-3ca2-426e-b6ce-a4bd9aa9a879@github.com>
Message-ID: <H3jgfc7mSBRJbKeZM2Ja_2W-GU5NjCsjT0vR4F7TTyc=.c5dc6d6a-a2ce-437b-a1a7-c482aa5e556f@github.com>

On Fri, 6 Sep 2024 11:18:35 GMT, Fei Yang <fyang at openjdk.org> wrote:

> The riscv64 implementation of [JDK-8337511](https://bugs.openjdk.org/browse/JDK-8337511) Implement JEP-404: Generational Shenandoah (Experimental).
> This is mainly adapted from the changes in aarch64.
> 
> Testing
> - [x] Gtest (release & fastdebug)
> - [x] hotspot_gc_shenandoah (release & fastdebug)

Looks good to me. Thank you!

Requesting another reviewer for platform specific code.

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

Marked as reviewed by wkemper (Committer).

PR Review: https://git.openjdk.org/shenandoah/pull/493#pullrequestreview-2301393337
PR Comment: https://git.openjdk.org/shenandoah/pull/493#issuecomment-2347219496

From wkemper at openjdk.org  Thu Sep 12 21:04:25 2024
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 12 Sep 2024 21:04:25 GMT
Subject: RFR: 8339643: Port JEP 404 to RISC-V
In-Reply-To: <J3I-KZdj2aYAEN7cFFDkuZEpp6WBM7AFaikL14CDdWM=.5f1201e3-3ca2-426e-b6ce-a4bd9aa9a879@github.com>
References: <J3I-KZdj2aYAEN7cFFDkuZEpp6WBM7AFaikL14CDdWM=.5f1201e3-3ca2-426e-b6ce-a4bd9aa9a879@github.com>
Message-ID: <t8CzRSlw36j8YKtz4rlwlc4fY-KAGARblVyXqhuYPSU=.0a7c340e-8430-4e1b-8058-fe6c746d583c@github.com>

On Fri, 6 Sep 2024 11:18:35 GMT, Fei Yang <fyang at openjdk.org> wrote:

> The riscv64 implementation of [JDK-8337511](https://bugs.openjdk.org/browse/JDK-8337511) Implement JEP-404: Generational Shenandoah (Experimental).
> This is mainly adapted from the changes in aarch64.
> 
> Testing
> - [x] Gtest (release & fastdebug)
> - [x] hotspot_gc_shenandoah (release & fastdebug)

Could you please enable the github actions for testing in your fork of this repo?

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

PR Comment: https://git.openjdk.org/shenandoah/pull/493#issuecomment-2347233741

From wkemper at openjdk.org  Thu Sep 12 22:36:17 2024
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 12 Sep 2024 22:36:17 GMT
Subject: RFR: Merge openjdk/jdk21u-dev:master [v2]
In-Reply-To: <XqL63Q51AUzRMyWi1Vq4nM46ja1jITkf2TCHXvy9L7A=.81efa703-afc0-46ff-97d8-1fc4bd8efada@github.com>
References: <XqL63Q51AUzRMyWi1Vq4nM46ja1jITkf2TCHXvy9L7A=.81efa703-afc0-46ff-97d8-1fc4bd8efada@github.com>
Message-ID: <cs15vg_WkfytJXlhWhV-4B3bFK1zHABTA1nFSF-kuQI=.f8c4b4dd-cc00-4f13-9748-dc27c3e11a9b@github.com>

> Merges tag jdk-21.0.5+6

William Kemper has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase.

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

Changes:
  - all: https://git.openjdk.org/shenandoah-jdk21u/pull/76/files
  - new: https://git.openjdk.org/shenandoah-jdk21u/pull/76/files/459757e3..459757e3

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

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

PR: https://git.openjdk.org/shenandoah-jdk21u/pull/76

From wkemper at openjdk.org  Thu Sep 12 22:36:18 2024
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 12 Sep 2024 22:36:18 GMT
Subject: RFR: Merge openjdk/jdk21u-dev:master
In-Reply-To: <XqL63Q51AUzRMyWi1Vq4nM46ja1jITkf2TCHXvy9L7A=.81efa703-afc0-46ff-97d8-1fc4bd8efada@github.com>
References: <XqL63Q51AUzRMyWi1Vq4nM46ja1jITkf2TCHXvy9L7A=.81efa703-afc0-46ff-97d8-1fc4bd8efada@github.com>
Message-ID: <lvXz77wBnVGER5gQycCG9DPQSdLtXqWJkNw2pJb6_xQ=.d34288e5-becb-4c61-9b93-937665c10270@github.com>

On Thu, 5 Sep 2024 14:18:37 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Merges tag jdk-21.0.5+6

Superseded by https://github.com/openjdk/shenandoah-jdk21u/pull/77

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

PR Comment: https://git.openjdk.org/shenandoah-jdk21u/pull/76#issuecomment-2347355022

From wkemper at openjdk.org  Thu Sep 12 22:36:18 2024
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 12 Sep 2024 22:36:18 GMT
Subject: Withdrawn: Merge openjdk/jdk21u-dev:master
In-Reply-To: <XqL63Q51AUzRMyWi1Vq4nM46ja1jITkf2TCHXvy9L7A=.81efa703-afc0-46ff-97d8-1fc4bd8efada@github.com>
References: <XqL63Q51AUzRMyWi1Vq4nM46ja1jITkf2TCHXvy9L7A=.81efa703-afc0-46ff-97d8-1fc4bd8efada@github.com>
Message-ID: <0DLAqcyO4cECNKi5JiYIesvhPPxlVz1j6-qYENCAIk4=.8e269261-04d8-4a65-8729-e83ed7775ee8@github.com>

On Thu, 5 Sep 2024 14:18:37 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Merges tag jdk-21.0.5+6

This pull request has been closed without being integrated.

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

PR: https://git.openjdk.org/shenandoah-jdk21u/pull/76

From wkemper at openjdk.org  Thu Sep 12 22:37:11 2024
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 12 Sep 2024 22:37:11 GMT
Subject: RFR: Merge openjdk/jdk21u-dev:master [v2]
In-Reply-To: <9NjJjnkifvMcXpl0DxrYaU2oC59ZkIAT98_AG2IB0MU=.4d7c9520-f587-4639-9c67-7ddccade29f2@github.com>
References: <9NjJjnkifvMcXpl0DxrYaU2oC59ZkIAT98_AG2IB0MU=.4d7c9520-f587-4639-9c67-7ddccade29f2@github.com>
Message-ID: <OmdZulceAltGWGA_K_rrIxc4YtSrnfH4RtJBMiwKkX4=.8c604782-a6fb-4f71-a665-60e51c4d03d1@github.com>

> Merges tag jdk-21.0.5+7

William Kemper has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase.

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

Changes:
  - all: https://git.openjdk.org/shenandoah-jdk21u/pull/77/files
  - new: https://git.openjdk.org/shenandoah-jdk21u/pull/77/files/c4d39f30..c4d39f30

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

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

PR: https://git.openjdk.org/shenandoah-jdk21u/pull/77

From wkemper at openjdk.org  Thu Sep 12 22:37:14 2024
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 12 Sep 2024 22:37:14 GMT
Subject: Integrated: Merge openjdk/jdk21u-dev:master
In-Reply-To: <9NjJjnkifvMcXpl0DxrYaU2oC59ZkIAT98_AG2IB0MU=.4d7c9520-f587-4639-9c67-7ddccade29f2@github.com>
References: <9NjJjnkifvMcXpl0DxrYaU2oC59ZkIAT98_AG2IB0MU=.4d7c9520-f587-4639-9c67-7ddccade29f2@github.com>
Message-ID: <AdRLswFi5RuSgeBagwxLn9YnlHamuNMSZrfXHUE6soI=.cb76fc3c-7f9c-48ba-9cbd-ca4e6b74b76e@github.com>

On Thu, 12 Sep 2024 14:21:04 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Merges tag jdk-21.0.5+7

This pull request has now been integrated.

Changeset: 74740d78
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.org/shenandoah-jdk21u/commit/74740d7815b38f71c908743c3617f594634bfa71
Stats:     1328 lines in 20 files changed: 1311 ins; 2 del; 15 mod

Merge

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

PR: https://git.openjdk.org/shenandoah-jdk21u/pull/77

From wkemper at openjdk.org  Thu Sep 12 23:01:42 2024
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 12 Sep 2024 23:01:42 GMT
Subject: Integrated: 8337242: GenShen: Remove unnecessary copyright changes
Message-ID: <N2w8j2WHunZ_yicDQVi0IXplYnCY9WJ_-Crvg6izzSU=.51c6d5f7-32af-4bd0-b5b6-7ccae1c02c0e@github.com>

Clean backport.

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

Commit messages:
 - Backport 4f96b5d29652c7d24adca6d77804926f2bb5ef55

Changes: https://git.openjdk.org/shenandoah-jdk21u/pull/78/files
  Webrev: https://webrevs.openjdk.org/?repo=shenandoah-jdk21u&pr=78&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8337242
  Stats: 6 lines in 6 files changed: 1 ins; 5 del; 0 mod
  Patch: https://git.openjdk.org/shenandoah-jdk21u/pull/78.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah-jdk21u.git pull/78/head:pull/78

PR: https://git.openjdk.org/shenandoah-jdk21u/pull/78

From wkemper at openjdk.org  Thu Sep 12 23:01:42 2024
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 12 Sep 2024 23:01:42 GMT
Subject: Integrated: 8337242: GenShen: Remove unnecessary copyright changes
In-Reply-To: <N2w8j2WHunZ_yicDQVi0IXplYnCY9WJ_-Crvg6izzSU=.51c6d5f7-32af-4bd0-b5b6-7ccae1c02c0e@github.com>
References: <N2w8j2WHunZ_yicDQVi0IXplYnCY9WJ_-Crvg6izzSU=.51c6d5f7-32af-4bd0-b5b6-7ccae1c02c0e@github.com>
Message-ID: <w-4lIWJ-baAvf33xbunLfgwyxEuG-AQsTImdqa9Ck0g=.c42c1569-de35-4587-883f-195d2ab4d750@github.com>

On Thu, 12 Sep 2024 22:56:42 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Clean backport.

This pull request has now been integrated.

Changeset: ea85cf82
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.org/shenandoah-jdk21u/commit/ea85cf820f3948831167aeab39997c423940cde0
Stats:     6 lines in 6 files changed: 1 ins; 5 del; 0 mod

8337242: GenShen: Remove unnecessary copyright changes

Backport-of: 4f96b5d29652c7d24adca6d77804926f2bb5ef55

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

PR: https://git.openjdk.org/shenandoah-jdk21u/pull/78

From wkemper at openjdk.org  Thu Sep 12 23:17:59 2024
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 12 Sep 2024 23:17:59 GMT
Subject: RFR: 8337847: [GenShen] jdk.test.whitebox.Whitebox.isObjectInOldGen
 misreports
Message-ID: <79y_gcIYrBYLpJFAtHzJRQg5hBR6jZVqojkag7tFwKI=.78f10803-171e-4b5d-92a1-dd1f637d77b0@github.com>

Clean backport. Fix in test code.

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

Commit messages:
 - Backport 44f5995bf87cb2e82176f2393517e4a11447b516

Changes: https://git.openjdk.org/shenandoah-jdk21u/pull/79/files
  Webrev: https://webrevs.openjdk.org/?repo=shenandoah-jdk21u&pr=79&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8337847
  Stats: 11 lines in 2 files changed: 9 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/shenandoah-jdk21u/pull/79.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah-jdk21u.git pull/79/head:pull/79

PR: https://git.openjdk.org/shenandoah-jdk21u/pull/79

From wkemper at openjdk.org  Thu Sep 12 23:32:30 2024
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 12 Sep 2024 23:32:30 GMT
Subject: Integrated: 8337847: [GenShen]
 jdk.test.whitebox.Whitebox.isObjectInOldGen misreports
In-Reply-To: <79y_gcIYrBYLpJFAtHzJRQg5hBR6jZVqojkag7tFwKI=.78f10803-171e-4b5d-92a1-dd1f637d77b0@github.com>
References: <79y_gcIYrBYLpJFAtHzJRQg5hBR6jZVqojkag7tFwKI=.78f10803-171e-4b5d-92a1-dd1f637d77b0@github.com>
Message-ID: <GW4msHgg2AApqeE57UfTTFSlVNv6fpYQ05ulyeAHwr8=.79f70a31-5bae-4992-93b7-d80d34f7e7c2@github.com>

On Thu, 12 Sep 2024 23:12:50 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Clean backport. Fix in test code.

This pull request has now been integrated.

Changeset: c3957e67
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.org/shenandoah-jdk21u/commit/c3957e6716d0b9b633066aeca04adb80dbd4fb02
Stats:     11 lines in 2 files changed: 9 ins; 0 del; 2 mod

8337847: [GenShen] jdk.test.whitebox.Whitebox.isObjectInOldGen misreports

Backport-of: 44f5995bf87cb2e82176f2393517e4a11447b516

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

PR: https://git.openjdk.org/shenandoah-jdk21u/pull/79

From kdnilsen at openjdk.org  Thu Sep 12 23:56:17 2024
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Thu, 12 Sep 2024 23:56:17 GMT
Subject: RFR: 8339643: Port JEP 404 to RISC-V
In-Reply-To: <J3I-KZdj2aYAEN7cFFDkuZEpp6WBM7AFaikL14CDdWM=.5f1201e3-3ca2-426e-b6ce-a4bd9aa9a879@github.com>
References: <J3I-KZdj2aYAEN7cFFDkuZEpp6WBM7AFaikL14CDdWM=.5f1201e3-3ca2-426e-b6ce-a4bd9aa9a879@github.com>
Message-ID: <eZrJyMxkvVjLgFS8loLGEnVYfLqWwNuMsKWog1qpHOw=.055368a5-2712-481c-9e10-8b6e864686d5@github.com>

On Fri, 6 Sep 2024 11:18:35 GMT, Fei Yang <fyang at openjdk.org> wrote:

> The riscv64 implementation of [JDK-8337511](https://bugs.openjdk.org/browse/JDK-8337511) Implement JEP-404: Generational Shenandoah (Experimental).
> This is mainly adapted from the changes in aarch64.
> 
> Testing
> - [x] Gtest (release & fastdebug)
> - [x] hotspot_gc_shenandoah (release & fastdebug)

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

> 577:   __ bind(L_loop);
> 578:   __ add(tmp, start, count);
> 579:   __ sb(zr, Address(tmp));

Do we want to condition behavior on UseCondCardMark?  Other architectures are considering this.

src/hotspot/share/gc/shenandoah/mode/shenandoahGenerationalMode.cpp line 36:

> 34: 
> 35: #if !(defined AARCH64 || defined AMD64 || defined IA32 || defined PPC64 || RISCV64)
> 36:   vm_exit_during_initialization("Shenandoah Generational GC is not supported on this platform.");

Should RISCV64 use the same style of macro test as the other architectures?  "|| defined RISCV64"

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

PR Review Comment: https://git.openjdk.org/shenandoah/pull/493#discussion_r1757726254
PR Review Comment: https://git.openjdk.org/shenandoah/pull/493#discussion_r1757710192

From wkemper at openjdk.org  Fri Sep 13 00:10:50 2024
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 13 Sep 2024 00:10:50 GMT
Subject: RFR: 8338341: GenShen: Cleanup headers,
 unreachable code and unintentional changes
Message-ID: <UCcZFmAbRcrR6h6YloKu1FE5rII5qckL1bOLTXzkAso=.e65411ee-4371-43cc-b06e-7c724793e7ca@github.com>

Conflict in file changed on tip, but doesn't exist in 21.

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

Commit messages:
 - 8338341: GenShen: Cleanup headers, unreachable code and unintentional changes

Changes: https://git.openjdk.org/shenandoah-jdk21u/pull/80/files
  Webrev: https://webrevs.openjdk.org/?repo=shenandoah-jdk21u&pr=80&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8338341
  Stats: 33 lines in 7 files changed: 0 ins; 26 del; 7 mod
  Patch: https://git.openjdk.org/shenandoah-jdk21u/pull/80.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah-jdk21u.git pull/80/head:pull/80

PR: https://git.openjdk.org/shenandoah-jdk21u/pull/80

From kdnilsen at openjdk.org  Fri Sep 13 00:26:22 2024
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Fri, 13 Sep 2024 00:26:22 GMT
Subject: RFR: 8338341: GenShen: Cleanup headers,
 unreachable code and unintentional changes
In-Reply-To: <UCcZFmAbRcrR6h6YloKu1FE5rII5qckL1bOLTXzkAso=.e65411ee-4371-43cc-b06e-7c724793e7ca@github.com>
References: <UCcZFmAbRcrR6h6YloKu1FE5rII5qckL1bOLTXzkAso=.e65411ee-4371-43cc-b06e-7c724793e7ca@github.com>
Message-ID: <6TctzlO6N96k6HRau8rs4fNAVhbrDCekyjy10aoyqFo=.dc8cb0e9-4ed8-4b84-8ca2-107c405f4cc2@github.com>

On Fri, 13 Sep 2024 00:05:57 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Conflict in file changed on tip, but doesn't exist in 21.

Marked as reviewed by kdnilsen (Committer).

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

PR Review: https://git.openjdk.org/shenandoah-jdk21u/pull/80#pullrequestreview-2301618470

From ysr at openjdk.org  Fri Sep 13 00:36:18 2024
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Fri, 13 Sep 2024 00:36:18 GMT
Subject: RFR: 8338341: GenShen: Cleanup headers,
 unreachable code and unintentional changes
In-Reply-To: <UCcZFmAbRcrR6h6YloKu1FE5rII5qckL1bOLTXzkAso=.e65411ee-4371-43cc-b06e-7c724793e7ca@github.com>
References: <UCcZFmAbRcrR6h6YloKu1FE5rII5qckL1bOLTXzkAso=.e65411ee-4371-43cc-b06e-7c724793e7ca@github.com>
Message-ID: <TwTgo920fhRS_WR3iZixgH9ufIFjy8BYjJAa7m-J5RY=.f8dd6adc-f392-467e-84bb-105c242a0aa7@github.com>

On Fri, 13 Sep 2024 00:05:57 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Conflict in file changed on tip, but doesn't exist in 21.

Marked as reviewed by ysr (Committer).

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

PR Review: https://git.openjdk.org/shenandoah-jdk21u/pull/80#pullrequestreview-2301646757

From dholmes at openjdk.org  Fri Sep 13 02:19:07 2024
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 13 Sep 2024 02:19:07 GMT
Subject: RFR: 8337563: NMT: rename MEMFLAGS to MemTag [v11]
In-Reply-To: <1Io2b9D2fXcUlf-VyTzgeqloWFuGNUh6T1wXzROJHgc=.8373bbd4-3aa9-4865-acc8-5f046607d052@github.com>
References: <aQDgRwE-H5U0lz8wooLBAQZsuDnB5zZzjMhheIu3y9Y=.0bae7ae4-062e-47de-b7c3-4fedc5d7e20a@github.com>
 <1Io2b9D2fXcUlf-VyTzgeqloWFuGNUh6T1wXzROJHgc=.8373bbd4-3aa9-4865-acc8-5f046607d052@github.com>
Message-ID: <yJag6O2f7OxJM5sXjfLRwEEhNKpgh1DEWTS2Osp4keU=.0578a00d-e1a1-4a5f-aa74-26143936c6d7@github.com>

On Thu, 12 Sep 2024 15:52:41 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

>> Please review this cleanup, where we rename `MEMFLAGS` to `MemTag`.
>> 
>> `MEMFLAGS` implies that we can use more than one at the same time, but those are exclusive values, so `MemTag` is a more suitable name.
>> 
>> This fix also includes a cleanup of all the related function/template parameter names and local variable names.
>> 
>> Testing is pending...
>> 
>> Note: there is more history in old closed PRs [https://github.com/openjdk/jdk/pull/20497](https://github.com/openjdk/jdk/pull/20497) and [https://github.com/openjdk/jdk/pull/20472](https://github.com/openjdk/jdk/pull/20472)
>
> Gerard Ziemski has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - copyrights
>  - Afshin's feedback, tests

Looks good. I thought those type/tag issues had been pointed out earlier, but good to catch them anyway.

Thanks

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20872#pullrequestreview-2302006352

From fyang at openjdk.org  Fri Sep 13 03:47:46 2024
From: fyang at openjdk.org (Fei Yang)
Date: Fri, 13 Sep 2024 03:47:46 GMT
Subject: RFR: 8339643: Port JEP 404 to RISC-V [v2]
In-Reply-To: <J3I-KZdj2aYAEN7cFFDkuZEpp6WBM7AFaikL14CDdWM=.5f1201e3-3ca2-426e-b6ce-a4bd9aa9a879@github.com>
References: <J3I-KZdj2aYAEN7cFFDkuZEpp6WBM7AFaikL14CDdWM=.5f1201e3-3ca2-426e-b6ce-a4bd9aa9a879@github.com>
Message-ID: <yEiP-f7USvTdorMQHNEIiJuwNgAcf_Gf9uOJvRVA8yk=.5f1e27d8-8e52-47e6-848f-fd9c924cd107@github.com>

> The riscv64 implementation of [JDK-8337511](https://bugs.openjdk.org/browse/JDK-8337511) Implement JEP-404: Generational Shenandoah (Experimental).
> This is mainly adapted from the changes in aarch64.
> 
> Testing
> - [x] Gtest (release & fastdebug)
> - [x] hotspot_gc_shenandoah (release & fastdebug)

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

  Review

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

Changes:
  - all: https://git.openjdk.org/shenandoah/pull/493/files
  - new: https://git.openjdk.org/shenandoah/pull/493/files/ab573a27..9be141c0

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

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

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

From fyang at openjdk.org  Fri Sep 13 03:56:22 2024
From: fyang at openjdk.org (Fei Yang)
Date: Fri, 13 Sep 2024 03:56:22 GMT
Subject: RFR: 8339643: Port JEP 404 to RISC-V
In-Reply-To: <t8CzRSlw36j8YKtz4rlwlc4fY-KAGARblVyXqhuYPSU=.0a7c340e-8430-4e1b-8058-fe6c746d583c@github.com>
References: <J3I-KZdj2aYAEN7cFFDkuZEpp6WBM7AFaikL14CDdWM=.5f1201e3-3ca2-426e-b6ce-a4bd9aa9a879@github.com>
 <t8CzRSlw36j8YKtz4rlwlc4fY-KAGARblVyXqhuYPSU=.0a7c340e-8430-4e1b-8058-fe6c746d583c@github.com>
Message-ID: <x4-kvfCfsylkEmV3oO9tsp57IaWE0W1_d4FB2RERI-g=.58350bdf-cf62-49ff-ab20-d8e98c5ccb0a@github.com>

On Thu, 12 Sep 2024 21:01:41 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Could you please enable the github actions for testing in your fork of this repo?

Done. Thanks for reminding.

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

PR Comment: https://git.openjdk.org/shenandoah/pull/493#issuecomment-2347981115

From fyang at openjdk.org  Fri Sep 13 03:56:22 2024
From: fyang at openjdk.org (Fei Yang)
Date: Fri, 13 Sep 2024 03:56:22 GMT
Subject: RFR: 8339643: Port JEP 404 to RISC-V [v2]
In-Reply-To: <eZrJyMxkvVjLgFS8loLGEnVYfLqWwNuMsKWog1qpHOw=.055368a5-2712-481c-9e10-8b6e864686d5@github.com>
References: <J3I-KZdj2aYAEN7cFFDkuZEpp6WBM7AFaikL14CDdWM=.5f1201e3-3ca2-426e-b6ce-a4bd9aa9a879@github.com>
 <eZrJyMxkvVjLgFS8loLGEnVYfLqWwNuMsKWog1qpHOw=.055368a5-2712-481c-9e10-8b6e864686d5@github.com>
Message-ID: <1VYKIEPGwMhD0q1vaJpvof0g38A6N5ueIRm-c-6tzCE=.73ddff29-f966-426d-ac31-96c8d9befd9f@github.com>

On Thu, 12 Sep 2024 23:50:43 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> Fei Yang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review
>
> src/hotspot/cpu/riscv/gc/shenandoah/shenandoahBarrierSetAssembler_riscv.cpp line 579:
> 
>> 577:   __ bind(L_loop);
>> 578:   __ add(tmp, start, count);
>> 579:   __ sb(zr, Address(tmp));
> 
> Do we want to condition behavior on UseCondCardMark?  Other architectures are considering this.

Seems still under discussion? I will provide further update once it's resolved.

> src/hotspot/share/gc/shenandoah/mode/shenandoahGenerationalMode.cpp line 36:
> 
>> 34: 
>> 35: #if !(defined AARCH64 || defined AMD64 || defined IA32 || defined PPC64 || RISCV64)
>> 36:   vm_exit_during_initialization("Shenandoah Generational GC is not supported on this platform.");
> 
> Should RISCV64 use the same style of macro test as the other architectures?  "|| defined RISCV64"

Good catch. I think it's mis-typed. Fixed. Thank you.

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

PR Review Comment: https://git.openjdk.org/shenandoah/pull/493#discussion_r1758138170
PR Review Comment: https://git.openjdk.org/shenandoah/pull/493#discussion_r1758137439

From adinn at openjdk.org  Fri Sep 13 06:46:12 2024
From: adinn at openjdk.org (Andrew Dinn)
Date: Fri, 13 Sep 2024 06:46:12 GMT
Subject: Integrated: 8339849: Enumerate opto and C1 stubs, generate enums,
 names, fields and generator calls
In-Reply-To: <gmeZu6egkzf71-hoDOcrK8hql0DJ0rdnAr_D0IcE9tc=.7d9cab12-4009-4cf3-8373-dac7eef9f398@github.com>
References: <gmeZu6egkzf71-hoDOcrK8hql0DJ0rdnAr_D0IcE9tc=.7d9cab12-4009-4cf3-8373-dac7eef9f398@github.com>
Message-ID: <BIA8lpR8vORcix6MMrArcR7utBPgud-yXFNS6QGtfbg=.5ef143b4-2f24-4a9a-8a4d-9784fd40c887@github.com>

On Tue, 10 Sep 2024 15:27:09 GMT, Andrew Dinn <adinn at openjdk.org> wrote:

> Systematize handling of Opto and C1 stubs. Generate enum ids, static fields, stub/blob names and generator code from declarations using template macros as previously done with Shared stubs. Systematically reference stubs and stub names using ids.

This pull request has now been integrated.

Changeset: b88ff9c9
Author:    Andrew Dinn <adinn at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b88ff9c986bfe5e14e2ba5803a464fbf6e131df8
Stats:     1033 lines in 44 files changed: 237 ins; 105 del; 691 mod

8339849: Enumerate opto and C1 stubs, generate enums, names, fields and generator calls

Reviewed-by: kvn

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

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

From rcastanedalo at openjdk.org  Fri Sep 13 06:46:15 2024
From: rcastanedalo at openjdk.org (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Fri, 13 Sep 2024 06:46:15 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v13]
In-Reply-To: <-CikzUsH1qKbMujGJQFhaPlKaCUDzqH-jEZNM5BZVQQ=.22d236a1-a69a-42e0-86d1-aa738c6e6e6d@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <DUgk6HT_Zk5KnbmAd_HzrJi4B8D1J-uuoAGzReWyI8s=.6c04f90a-bf1d-49af-a31d-5224973952d4@github.com>
 <GQVVR0K-mDh4evKvrKG9eXwwF4j7zAg-8ai4__gWNGE=.3c502820-717b-44b7-b82d-a24dd7fdd9d5@github.com>
 <-CikzUsH1qKbMujGJQFhaPlKaCUDzqH-jEZNM5BZVQQ=.22d236a1-a69a-42e0-86d1-aa738c6e6e6d@github.com>
Message-ID: <P6u4aaxhJr4zjXT4_J993iocS4F11e7lfHjnnGqIJKc=.1bf65c03-fe7f-4b1a-ba08-26c64dafa3f7@github.com>

On Thu, 12 Sep 2024 15:42:59 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> src/hotspot/share/opto/machnode.cpp line 390:
>> 
>>> 388:     t = t->make_ptr();
>>> 389:   }
>>> 390:   if (t->isa_narrowklass() && CompressedKlassPointers::shift() == 0) {
>> 
>> Does this change have any effect? `UseCompressedClassPointers` should be implied by `t->isa_narrowklass()`.
>
> I don't remember if this change was a reaction to an error or if I just guarded `CompressedKlassPointers::shift()` with +UseCCP because that is the prerequisite now. Probably the latter. I can remove this. Probably should assert then for +UseCCP.

I see, thanks. In that case, I would suggest removing the explicit `UseCompressedClassPointers` test, since it should be implied by `t->isa_narrowklass()`. `check_init()` within `CompressedKlassPointers::shift()` would already fail for the unexpected case where `t->isa_narrowklass() && !UseCompressedClassPointers`, no?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1758270661

From rcastanedalo at openjdk.org  Fri Sep 13 07:49:15 2024
From: rcastanedalo at openjdk.org (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Fri, 13 Sep 2024 07:49:15 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v13]
In-Reply-To: <jqZ-1tR0WMbnDldGMusdqMnswTGj1hbOIY3JdUFtIsM=.4169760d-d5cf-4335-9e53-baf885d9422f@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <4iHDH-GpSa-uPqe0IwwP6notHRyrOTiecqCSX9kYCe0=.d7969fd0-3066-42fa-82d4-842c10baee1c@github.com>
 <xnL42l4bz2SaiEgSVCDBXXbnZqgnIcYpnSy7tM2WY1w=.094f34bb-4587-4c45-ad44-daf83705515a@github.com>
 <jqZ-1tR0WMbnDldGMusdqMnswTGj1hbOIY3JdUFtIsM=.4169760d-d5cf-4335-9e53-baf885d9422f@github.com>
Message-ID: <JNixrGzCB7AoiRE73hQkycIX130qFzKq-ibQFMfsu9c=.e926bacd-33dd-421d-8154-4a88fe3232d9@github.com>

On Thu, 12 Sep 2024 15:38:18 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> src/hotspot/share/opto/lcm.cpp line 272:
>> 
>>> 270:         const TypePtr* tptr;
>>> 271:         if ((UseCompressedOops || UseCompressedClassPointers) &&
>>> 272:             (CompressedOops::shift() == 0 || CompressedKlassPointers::shift() == 0)) {
>> 
>> Could you explain this change? It seems like it may affect C2's implicit null check analysis even for `-XX:-UseCompactObjectHeaders`. In particular, for the following configurations, the changed condition evaluates to true before the change and false after it, regardless of whether `UseCompactObjectHeaders` is enabled:
>> 
>> (!UseCompressedOops,  UseCompressedClassPointers, CompressedKlassPointers::shift() != 0)
>> ( UseCompressedOops, !UseCompressedClassPointers, CompressedOops::shift() != 0)
>
> Hi @robcasloz 
> 
> The `CompressedKlassPointers` utility class is not usable anymore with `-UseCompressedClassPointers`. One change is that if `UseCompressedClassPointers` is off, `CompressedKlassPointers` stays uninitialized. And that makes more sense then to rely on the static initialization values of `CompressedOops::_shift`.

Thanks for the explanation. I wonder if the test is necessary at all, or one could simply use `base->get_ptr_type()` unconditionally, which defaults to `base->bottom_type()->isa_ptr()` anyway for non-compressed pointers. But this simplification would be in any case out of the scope of this changeset.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1758356268

From rcastanedalo at openjdk.org  Fri Sep 13 07:57:15 2024
From: rcastanedalo at openjdk.org (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Fri, 13 Sep 2024 07:57:15 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v13]
In-Reply-To: <s0uUPQ4WJ3JMVQStLUrhTK_Kjn3joFNQOX7Hm_JRbqE=.44a6c8ee-fad6-4aa6-8e95-cd8d23beab60@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <4iHDH-GpSa-uPqe0IwwP6notHRyrOTiecqCSX9kYCe0=.d7969fd0-3066-42fa-82d4-842c10baee1c@github.com>
 <s0uUPQ4WJ3JMVQStLUrhTK_Kjn3joFNQOX7Hm_JRbqE=.44a6c8ee-fad6-4aa6-8e95-cd8d23beab60@github.com>
Message-ID: <lBpTKXccIP3OSowW43K_kl_a_yVs7FoGT_05fJGxDv8=.f720318f-9a1c-497c-9821-866ed35104c4@github.com>

On Thu, 12 Sep 2024 11:46:35 GMT, Roberto Casta?eda Lozano <rcastanedalo at openjdk.org> wrote:

>> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revert accidental change of UCOH default
>
> src/hotspot/share/cds/filemap.cpp line 2457:
> 
>> 2455:                           compressed_oops(), compressed_class_pointers());
>> 2456:   if (compressed_oops() != UseCompressedOops || compressed_class_pointers() != UseCompressedClassPointers) {
>> 2457:     log_info(cds)("Unable to use shared archive.\nThe saved state of UseCompressedOops and UseCompressedClassPointers is "
> 
> The promotion of this CDS log line from `info` to `warning` triggers false failures in the `test/hotspot/jtreg/compiler/intrinsics/bmi` tests when running them with `-XX:-UseCompressedClassPointers`. These tests expect the standard output of different JVM runs to be identical, but the timestamps in the log messages tend to differ. I suggest adjusting the test configuration so that log timestamps are simply omitted, as in [this patch](https://github.com/robcasloz/jdk/commit/48f6e90ef6e0a71b55df536ed04a8b72130b5ea9) (feel free to merge it as-is or with any further changes you may find necessary).

This comment has been marked as "resolved" without any apparent action being taken, is that intentional?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1758369787

From rkennke at openjdk.org  Fri Sep 13 08:21:54 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Fri, 13 Sep 2024 08:21:54 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v14]
In-Reply-To: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
Message-ID: <3-nOaxvBWIcOLzCOlrWPzJtsYRknVz5JIwx21X8xkIg=.6ce32f15-a4d6-44d5-9b9e-c3015de45e66@github.com>

> This is the main body of the JEP 450: Compact Object Headers (Experimental).
> 
> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing.
> 
> Main changes:
>  - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers.
>  - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded.
>  - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops).
>  - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all).
>  - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16).
>  - Arrays will now store their length at offset 8.
>  - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _coh variants of CDS archiv...

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

  Hide log timestamps in test to prevent false failures

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20677/files
  - new: https://git.openjdk.org/jdk/pull/20677/files/9e008ac1..69f1ef1d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20677&range=13
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20677&range=12-13

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

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

From rkennke at openjdk.org  Fri Sep 13 08:21:55 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Fri, 13 Sep 2024 08:21:55 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v14]
In-Reply-To: <lBpTKXccIP3OSowW43K_kl_a_yVs7FoGT_05fJGxDv8=.f720318f-9a1c-497c-9821-866ed35104c4@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <4iHDH-GpSa-uPqe0IwwP6notHRyrOTiecqCSX9kYCe0=.d7969fd0-3066-42fa-82d4-842c10baee1c@github.com>
 <s0uUPQ4WJ3JMVQStLUrhTK_Kjn3joFNQOX7Hm_JRbqE=.44a6c8ee-fad6-4aa6-8e95-cd8d23beab60@github.com>
 <lBpTKXccIP3OSowW43K_kl_a_yVs7FoGT_05fJGxDv8=.f720318f-9a1c-497c-9821-866ed35104c4@github.com>
Message-ID: <99QfaesSJzBLGXsBKOdiSwjAdt18pwNMh62Pyhr-6bk=.b27f001b-e3e3-4826-9542-698eef2a9ee3@github.com>

On Fri, 13 Sep 2024 07:54:30 GMT, Roberto Casta?eda Lozano <rcastanedalo at openjdk.org> wrote:

>> src/hotspot/share/cds/filemap.cpp line 2457:
>> 
>>> 2455:                           compressed_oops(), compressed_class_pointers());
>>> 2456:   if (compressed_oops() != UseCompressedOops || compressed_class_pointers() != UseCompressedClassPointers) {
>>> 2457:     log_info(cds)("Unable to use shared archive.\nThe saved state of UseCompressedOops and UseCompressedClassPointers is "
>> 
>> The promotion of this CDS log line from `info` to `warning` triggers false failures in the `test/hotspot/jtreg/compiler/intrinsics/bmi` tests when running them with `-XX:-UseCompressedClassPointers`. These tests expect the standard output of different JVM runs to be identical, but the timestamps in the log messages tend to differ. I suggest adjusting the test configuration so that log timestamps are simply omitted, as in [this patch](https://github.com/robcasloz/jdk/commit/48f6e90ef6e0a71b55df536ed04a8b72130b5ea9) (feel free to merge it as-is or with any further changes you may find necessary).
>
> This comment has been marked as "resolved" without any apparent action being taken, is that intentional?

I have merged your patch locally but forgot to push it. Sorry.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1758407575

From azafari at openjdk.org  Fri Sep 13 08:45:15 2024
From: azafari at openjdk.org (Afshin Zafari)
Date: Fri, 13 Sep 2024 08:45:15 GMT
Subject: RFR: 8337563: NMT: rename MEMFLAGS to MemTag [v11]
In-Reply-To: <1Io2b9D2fXcUlf-VyTzgeqloWFuGNUh6T1wXzROJHgc=.8373bbd4-3aa9-4865-acc8-5f046607d052@github.com>
References: <aQDgRwE-H5U0lz8wooLBAQZsuDnB5zZzjMhheIu3y9Y=.0bae7ae4-062e-47de-b7c3-4fedc5d7e20a@github.com>
 <1Io2b9D2fXcUlf-VyTzgeqloWFuGNUh6T1wXzROJHgc=.8373bbd4-3aa9-4865-acc8-5f046607d052@github.com>
Message-ID: <3-s8755E5hKSDICVfIfYYa0Tk1FeL5-idsorLOFnqfs=.eda363bc-1d5e-4173-9007-c2d10114e396@github.com>

On Thu, 12 Sep 2024 15:52:41 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

>> Please review this cleanup, where we rename `MEMFLAGS` to `MemTag`.
>> 
>> `MEMFLAGS` implies that we can use more than one at the same time, but those are exclusive values, so `MemTag` is a more suitable name.
>> 
>> This fix also includes a cleanup of all the related function/template parameter names and local variable names.
>> 
>> Testing is pending...
>> 
>> Note: there is more history in old closed PRs [https://github.com/openjdk/jdk/pull/20497](https://github.com/openjdk/jdk/pull/20497) and [https://github.com/openjdk/jdk/pull/20472](https://github.com/openjdk/jdk/pull/20472)
>
> Gerard Ziemski has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - copyrights
>  - Afshin's feedback, tests

Thank you all, for the great work here.

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

PR Comment: https://git.openjdk.org/jdk/pull/20872#issuecomment-2348381372

From stuefe at openjdk.org  Fri Sep 13 09:30:24 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 13 Sep 2024 09:30:24 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v8]
In-Reply-To: <Kr9eGGeMs3LB-ULkPBBkaBBvURU3P7NJItuUR3Gmpmo=.d93bed80-2c06-414d-b8bd-b8f57a4deee3@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <J0g0PSye768dhN3JoXFsZ6FivocNBLPmHNtRUCOmLTw=.5756c64a-4763-4727-9637-ba3fe7b9b17d@github.com>
 <vt3oD_XW4eFNTnPYoSa0-TZiEsFtBXJKfPdsIoqVuXM=.7e14c4df-4c66-4f52-9a59-e86fbcb6e7d9@github.com>
 <sUnwVBIPq6l_4sgw5hOnjU4cP_RL4AM7f9RCFIOK6lc=.cb3e7f4b-e862-48f8-a308-e762ea272294@github.com>
 <Kr9eGGeMs3LB-ULkPBBkaBBvURU3P7NJItuUR3Gmpmo=.d93bed80-2c06-414d-b8bd-b8f57a4deee3@github.com>
Message-ID: <GMDowPeimWiK9fbaAVZsoPsphenfwWpSkMwR2pE0mNw=.818fca12-9537-4ed6-af3b-22ea9c2b5122@github.com>

On Tue, 10 Sep 2024 12:19:32 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This is tricky. We are already deep in initialization and have done a couple of decisions based on +UseCompressedClassPointers (e.g. CDS setup). I *think* we could still go with -UseCCP, but I wonder whether this is wise. 
>> 
>> Note that this error is not new. In the old code, we simply asserted. That left us with UB in release builds, which remains unresolved. I simply made the error explicit in release too.
>
> Ok, in this case, that's fine if we already asserted.  A fatal error is better.

Actually, a lot of the old code had dusty side corners that were UB. Making narrowKlass smaller than 32bit exposed a lot of them, and a lot of the changes in and around CompressedKlassPointers are about cleanly making explicit what before had been implicit or just broken (e.g. a clear distinction between encoding range and Klass range, and a clear handling of narrowKlass bit width as a runtime value).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1758522844

From stuefe at openjdk.org  Fri Sep 13 09:38:15 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 13 Sep 2024 09:38:15 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v8]
In-Reply-To: <Qmq5KYm4QolMsEt29X8lhx1oWSkBEApS-3iaIXd3L7o=.42bba1bc-d795-4712-a1b6-dab2781a60f7@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <J0g0PSye768dhN3JoXFsZ6FivocNBLPmHNtRUCOmLTw=.5756c64a-4763-4727-9637-ba3fe7b9b17d@github.com>
 <vt3oD_XW4eFNTnPYoSa0-TZiEsFtBXJKfPdsIoqVuXM=.7e14c4df-4c66-4f52-9a59-e86fbcb6e7d9@github.com>
 <Qmq5KYm4QolMsEt29X8lhx1oWSkBEApS-3iaIXd3L7o=.42bba1bc-d795-4712-a1b6-dab2781a60f7@github.com>
Message-ID: <JV_wg0xsmPrv_le1MBjFUxg916tpI5jdP46iDhXGua4=.2b073e9a-0ae7-4031-abdf-f937ee8cd2b1@github.com>

On Tue, 10 Sep 2024 12:13:58 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> src/hotspot/share/oops/compressedKlass.cpp line 243:
>> 
>>> 241:   } else {
>>> 242: 
>>> 243:     // In legacy mode, we try, in order of preference:
>> 
>> Can you not use the word 'legacy' here?  Maybe in "non-compact object header mode"...
>
> okay.

I removed all traces of "legacy" and "tiny", reverting to "standard" or "non-coh" vs "coh". I would prefer to use the shorthand "coh" in some places since "compact object header mode" is a mouthful and gives me RSI :)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1758533732

From stefank at openjdk.org  Fri Sep 13 09:44:19 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Fri, 13 Sep 2024 09:44:19 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v14]
In-Reply-To: <3-nOaxvBWIcOLzCOlrWPzJtsYRknVz5JIwx21X8xkIg=.6ce32f15-a4d6-44d5-9b9e-c3015de45e66@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <3-nOaxvBWIcOLzCOlrWPzJtsYRknVz5JIwx21X8xkIg=.6ce32f15-a4d6-44d5-9b9e-c3015de45e66@github.com>
Message-ID: <tiMTCfGoBUlu_Sm2daFxgrO5QLzVXU_jWolWV_Vk7nk=.a9e0ba6e-b436-454d-9a76-173cd1e83639@github.com>

On Fri, 13 Sep 2024 08:21:54 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> This is the main body of the JEP 450: Compact Object Headers (Experimental).
>> 
>> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing.
>> 
>> Main changes:
>>  - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers.
>>  - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded.
>>  - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops).
>>  - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all).
>>  - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16).
>>  - Arrays will now store their length at offset 8.
>>  - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _co...
>
> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Hide log timestamps in test to prevent false failures

I went over the oops/ directory and added a few cleanup requests and comments.

src/hotspot/share/oops/instanceOop.hpp line 43:

> 41:     } else {
> 42:       return sizeof(instanceOopDesc);
> 43:     }

This entire function can be removed. It returns the same value as oopDesc::base_offset_in_bytes(), but in a slightly different way.

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

> 169:     return mask_bits(value(), lock_mask_in_place | self_fwd_mask_in_place) >= static_cast<intptr_t>(marked_value);
> 170:   }
> 171: 

Suggestion to retain code layout.
Suggestion:

src/hotspot/share/oops/markWord.inline.hpp line 29:

> 27: 
> 28: #include "oops/markWord.hpp"
> 29: #include "oops/compressedOops.inline.hpp"

Suggestion:

#include "oops/compressedOops.inline.hpp"
#include "oops/markWord.hpp"

src/hotspot/share/oops/objArrayKlass.cpp line 146:

> 144: 
> 145: size_t ObjArrayKlass::oop_size(oop obj) const {
> 146:   // In this assert, we cannot safely access the Klass* with compact headers.

I would like a comment stating that this assert is turned of because size_give_klass calls oop_size on an object that might be concurrently forwarded.

src/hotspot/share/oops/oop.cpp line 158:

> 156:   // Only has a klass gap when compressed class pointers are used and not
> 157:   // using compact headers.
> 158:   return UseCompressedClassPointers && !UseCompactObjectHeaders;

This comment can just be removed.

src/hotspot/share/oops/oop.hpp line 340:

> 338:       // field offset. Use an offset halfway into the markWord, as the markWord is never
> 339:       // partially loaded from C2.
> 340:       return 4;

I asked around to see what people felt about dropping references to mark_offset_in_bytes(), which we know is 0. There was a request to strive to use mark_offset_in_bytes() for clarity.
Suggestion:

      return mark_offset_in_bytes() + 4;

src/hotspot/share/oops/oop.hpp line 349:

> 347:   static int klass_gap_offset_in_bytes() {
> 348:     assert(has_klass_gap(), "only applicable to compressed klass pointers");
> 349:     assert(!UseCompactObjectHeaders, "don't use klass_gap_offset_in_bytes() with compact headers");

This assert is implied by `has_klass_gap()`. I don't see the need to repeat it here.

src/hotspot/share/oops/oop.hpp line 363:

> 361:       return sizeof(markWord) + sizeof(Klass*);
> 362:     }
> 363:   }

Not a strong request for this PR, but there are many places that calculates almost the same thing, and it might be good to limit the number of places we do similar calculations.

I'm wondering if it wouldn't be better for readability to structure the code as follows:

  static int header_size_in_bytes() {
    if (UseCompactObjectHeaders) {
      return sizeof(markWord);
    } else if (UseCompressedClassPointers) {
      return sizeof(markWord) + sizeof(narrowKlass);
    } else {
      return sizeof(markWord) + sizeof(Klass*);
    }
  }

  // Size of object header, aligned to platform wordSize
  static int header_size() {
    return align_up(header_size_in_bytes(), HeapWordSize) / HeapWordSize;
  }
...  
  static int base_offset_in_bytes() {
    return header_size_in_bytes();
  }

src/hotspot/share/oops/oop.inline.hpp line 161:

> 159: 
> 160: void oopDesc::set_klass_gap(HeapWord* mem, int v) {
> 161:   assert(!UseCompactObjectHeaders, "don't set Klass* gap with compact headers");

We might want to consider just simplifying the function to: 

void oopDesc::set_klass_gap(HeapWord* mem, int v) {
  assert(has_klass_gap(), "precondition");
  *(int*)(((char*)mem) + klass_gap_offset_in_bytes()) = v;
}

src/hotspot/share/oops/oop.inline.hpp line 295:

> 293: // Used by scavengers
> 294: void oopDesc::forward_to(oop p) {
> 295:   assert(cast_from_oop<oopDesc*>(p) != this,

Do we really need the cast here?

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

PR Review: https://git.openjdk.org/jdk/pull/20677#pullrequestreview-2302542279
PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1758503206
PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1758482703
PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1758505713
PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1758479437
PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1758478106
PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1758472909
PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1758474349
PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1758528515
PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1758538380
PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1758540055

From stefank at openjdk.org  Fri Sep 13 09:44:20 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Fri, 13 Sep 2024 09:44:20 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v8]
In-Reply-To: <6usTXIvS83aO2VzX5xu2EnXlpIJ8YbfrWS6b3EI0MhE=.0e8cc603-0cd3-4bd9-b309-55e4dd0f0cb0@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <J0g0PSye768dhN3JoXFsZ6FivocNBLPmHNtRUCOmLTw=.5756c64a-4763-4727-9637-ba3fe7b9b17d@github.com>
 <6usTXIvS83aO2VzX5xu2EnXlpIJ8YbfrWS6b3EI0MhE=.0e8cc603-0cd3-4bd9-b309-55e4dd0f0cb0@github.com>
Message-ID: <ZDRwCJRCHrlH268CzJ4P7VDJXnGar40Fl4t_W28L99Y=.c9ad4810-4040-494b-8d54-96160fcd6046@github.com>

On Mon, 9 Sep 2024 12:17:17 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Roman Kennke has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Try to avoid lea in loadNklass (aarch64)
>>  - Fix release build error
>
> src/hotspot/share/oops/oop.cpp line 230:
> 
>> 228:   // disjunct below to fail if the two comparands are computed across such
>> 229:   // a concurrent change.
>> 230:   return Universe::heap()->is_stw_gc_active() && klass->is_objArray_klass() && is_forwarded() && (UseParallelGC || UseG1GC);
> 
> Is this still true after the recent changes like JDK-8311163? It might be worth waiting for.

That bug doesn't fix all cases where the the length field is modified.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1758477168

From tschatzl at openjdk.org  Fri Sep 13 11:15:15 2024
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Fri, 13 Sep 2024 11:15:15 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v8]
In-Reply-To: <ZDRwCJRCHrlH268CzJ4P7VDJXnGar40Fl4t_W28L99Y=.c9ad4810-4040-494b-8d54-96160fcd6046@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <J0g0PSye768dhN3JoXFsZ6FivocNBLPmHNtRUCOmLTw=.5756c64a-4763-4727-9637-ba3fe7b9b17d@github.com>
 <6usTXIvS83aO2VzX5xu2EnXlpIJ8YbfrWS6b3EI0MhE=.0e8cc603-0cd3-4bd9-b309-55e4dd0f0cb0@github.com>
 <ZDRwCJRCHrlH268CzJ4P7VDJXnGar40Fl4t_W28L99Y=.c9ad4810-4040-494b-8d54-96160fcd6046@github.com>
Message-ID: <Iv-aWPSvR4eZY9bek0msxpkDVQnvT9XyGcXEAhJ6UWo=.6e03e898-cba2-444f-b075-5b5fae3059c5@github.com>

On Fri, 13 Sep 2024 09:00:32 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> src/hotspot/share/oops/oop.cpp line 230:
>> 
>>> 228:   // disjunct below to fail if the two comparands are computed across such
>>> 229:   // a concurrent change.
>>> 230:   return Universe::heap()->is_stw_gc_active() && klass->is_objArray_klass() && is_forwarded() && (UseParallelGC || UseG1GC);
>> 
>> Is this still true after the recent changes like JDK-8311163? It might be worth waiting for.
>
> That bug doesn't fix all cases where the the length field is modified.

Which ones are remaining? JDK-8337709 implemented the same change for G1 GC before JDK-8311163.

The full collectors/g1 marking do not modify the length fields but have multiple separate queues which is a different issue. It will also be handled by the new `PartialArrayTaskStepper`, but should be of no concern here.

If I am not missing some case, this whole method is unnecessary now.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1758672296

From stuefe at openjdk.org  Fri Sep 13 12:51:17 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 13 Sep 2024 12:51:17 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v14]
In-Reply-To: <EZmLU9kQ--5-_Xi99YZG9HsKibIwnot3VcSI50gP6SY=.058873e4-dc41-460f-a5e4-3887d9be9d48@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <6Rant6SjxpFIHHWNthWc_plOdnGpWPvqj3rxRe144po=.bcdbad7a-e93a-41a3-b958-6ae602c7e083@github.com>
 <NR6CKOtdUaVarB7hiAUIAsIMe03qiTQr5VcEOWGt8mA=.164efc10-f0ff-4ddf-80b8-c56599c0ba7d@github.com>
 <EZmLU9kQ--5-_Xi99YZG9HsKibIwnot3VcSI50gP6SY=.058873e4-dc41-460f-a5e4-3887d9be9d48@github.com>
Message-ID: <PNLPNSaq1-U9bu683HGzuoBAyEcmJ4yTVE5CIYVIfFA=.b61fd250-10fa-4299-bb36-c52dd3bbd117@github.com>

On Tue, 10 Sep 2024 12:35:42 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> src/hotspot/share/oops/compressedKlass.cpp line 116:
>> 
>>> 114:   _range = end - _base;
>>> 115: 
>>> 116:   DEBUG_ONLY(assert_is_valid_encoding(addr, len, _base, _shift);)
>> 
>> Can you refactor so the aarch64 path runs this same code without duplication?
>
> In tinycp mode, aarch64 runs this code though? The aarch64 variant of pd_initialize just returns then. In non-COH mode (preexisting, not touched by this patch) Aarch64 needs its own handling.

I refactored: Now we should have no duplication (once my patch hits Romans PR branch)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1758800913

From stefank at openjdk.org  Fri Sep 13 12:51:18 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Fri, 13 Sep 2024 12:51:18 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v8]
In-Reply-To: <Iv-aWPSvR4eZY9bek0msxpkDVQnvT9XyGcXEAhJ6UWo=.6e03e898-cba2-444f-b075-5b5fae3059c5@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <J0g0PSye768dhN3JoXFsZ6FivocNBLPmHNtRUCOmLTw=.5756c64a-4763-4727-9637-ba3fe7b9b17d@github.com>
 <6usTXIvS83aO2VzX5xu2EnXlpIJ8YbfrWS6b3EI0MhE=.0e8cc603-0cd3-4bd9-b309-55e4dd0f0cb0@github.com>
 <ZDRwCJRCHrlH268CzJ4P7VDJXnGar40Fl4t_W28L99Y=.c9ad4810-4040-494b-8d54-96160fcd6046@github.com>
 <Iv-aWPSvR4eZY9bek0msxpkDVQnvT9XyGcXEAhJ6UWo=.6e03e898-cba2-444f-b075-5b5fae3059c5@github.com>
Message-ID: <TSrOBVP-x_1zWFqLynDcmtPSgONPen7W5HZ7bwD4_D4=.406eff89-e0da-40a1-998e-7a77c895fdd9@github.com>

On Fri, 13 Sep 2024 11:10:58 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> That bug doesn't fix all cases where the the length field is modified.
>
> Which ones are remaining? JDK-8337709 implemented the same change for G1 GC before JDK-8311163.
> 
> The full collectors/g1 marking do not modify the length fields but have multiple separate queues which is a different issue. It will also be handled by the new `PartialArrayTaskStepper`, but should be of no concern here.
> 
> If I am not missing some case, this whole method is unnecessary now.

If you've already fixed this for GC then I agree that we could remove this.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1758805418

From stefank at openjdk.org  Fri Sep 13 12:51:18 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Fri, 13 Sep 2024 12:51:18 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v8]
In-Reply-To: <TSrOBVP-x_1zWFqLynDcmtPSgONPen7W5HZ7bwD4_D4=.406eff89-e0da-40a1-998e-7a77c895fdd9@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <J0g0PSye768dhN3JoXFsZ6FivocNBLPmHNtRUCOmLTw=.5756c64a-4763-4727-9637-ba3fe7b9b17d@github.com>
 <6usTXIvS83aO2VzX5xu2EnXlpIJ8YbfrWS6b3EI0MhE=.0e8cc603-0cd3-4bd9-b309-55e4dd0f0cb0@github.com>
 <ZDRwCJRCHrlH268CzJ4P7VDJXnGar40Fl4t_W28L99Y=.c9ad4810-4040-494b-8d54-96160fcd6046@github.com>
 <Iv-aWPSvR4eZY9bek0msxpkDVQnvT9XyGcXEAhJ6UWo=.6e03e898-cba2-444f-b075-5b5fae3059c5@github.com>
 <TSrOBVP-x_1zWFqLynDcmtPSgONPen7W5HZ7bwD4_D4=.406eff89-e0da-40a1-998e-7a77c895fdd9@github.com>
Message-ID: <v0VLG-aoo8NDw4RxMWa66ktvblMg741lPUUEle69V60=.82823ab0-b6f1-4a81-a29b-58be35fca1a0@github.com>

On Fri, 13 Sep 2024 12:47:09 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> Which ones are remaining? JDK-8337709 implemented the same change for G1 GC before JDK-8311163.
>> 
>> The full collectors/g1 marking do not modify the length fields but have multiple separate queues which is a different issue. It will also be handled by the new `PartialArrayTaskStepper`, but should be of no concern here.
>> 
>> If I am not missing some case, this whole method is unnecessary now.
>
> If you've already fixed this for GC then I agree that we could remove this.

This seems like something that should be done as a separate patch that gets pushed before this PR.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1758808115

From rkennke at openjdk.org  Fri Sep 13 12:56:17 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Fri, 13 Sep 2024 12:56:17 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v14]
In-Reply-To: <tiMTCfGoBUlu_Sm2daFxgrO5QLzVXU_jWolWV_Vk7nk=.a9e0ba6e-b436-454d-9a76-173cd1e83639@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <3-nOaxvBWIcOLzCOlrWPzJtsYRknVz5JIwx21X8xkIg=.6ce32f15-a4d6-44d5-9b9e-c3015de45e66@github.com>
 <tiMTCfGoBUlu_Sm2daFxgrO5QLzVXU_jWolWV_Vk7nk=.a9e0ba6e-b436-454d-9a76-173cd1e83639@github.com>
Message-ID: <QHJWe_7rjgKSw78ZIDsmkLL5gZJLzUT2M_lJE2WSSLo=.678f9de1-0cdb-46d9-8dbe-9362aeb494fe@github.com>

On Fri, 13 Sep 2024 09:39:23 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Hide log timestamps in test to prevent false failures
>
> src/hotspot/share/oops/oop.inline.hpp line 295:
> 
>> 293: // Used by scavengers
>> 294: void oopDesc::forward_to(oop p) {
>> 295:   assert(cast_from_oop<oopDesc*>(p) != this,
> 
> Do we really need the cast here?

Yes, otherwise compiler complains about ambiguous != operator.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1758815451

From rkennke at openjdk.org  Fri Sep 13 13:03:16 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Fri, 13 Sep 2024 13:03:16 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v14]
In-Reply-To: <tiMTCfGoBUlu_Sm2daFxgrO5QLzVXU_jWolWV_Vk7nk=.a9e0ba6e-b436-454d-9a76-173cd1e83639@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <3-nOaxvBWIcOLzCOlrWPzJtsYRknVz5JIwx21X8xkIg=.6ce32f15-a4d6-44d5-9b9e-c3015de45e66@github.com>
 <tiMTCfGoBUlu_Sm2daFxgrO5QLzVXU_jWolWV_Vk7nk=.a9e0ba6e-b436-454d-9a76-173cd1e83639@github.com>
Message-ID: <aww1izsoDFzMbpM1_tYL5WqHRfFKqP_q36aCus6Y5CQ=.4289de67-b7c8-4cf1-b897-ebc3eff67224@github.com>

On Fri, 13 Sep 2024 09:31:39 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Hide log timestamps in test to prevent false failures
>
> src/hotspot/share/oops/oop.hpp line 363:
> 
>> 361:       return sizeof(markWord) + sizeof(Klass*);
>> 362:     }
>> 363:   }
> 
> Not a strong request for this PR, but there are many places that calculates almost the same thing, and it might be good to limit the number of places we do similar calculations.
> 
> I'm wondering if it wouldn't be better for readability to structure the code as follows:
> 
>   static int header_size_in_bytes() {
>     if (UseCompactObjectHeaders) {
>       return sizeof(markWord);
>     } else if (UseCompressedClassPointers) {
>       return sizeof(markWord) + sizeof(narrowKlass);
>     } else {
>       return sizeof(markWord) + sizeof(Klass*);
>     }
>   }
> 
>   // Size of object header, aligned to platform wordSize
>   static int header_size() {
>     return align_up(header_size_in_bytes(), HeapWordSize) / HeapWordSize;
>   }
> ...  
>   static int base_offset_in_bytes() {
>     return header_size_in_bytes();
>   }

Ok. I filed: https://bugs.openjdk.org/browse/JDK-8340118 for now, let's see if I can sort this out before integrating this PR.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1758825458

From rkennke at openjdk.org  Fri Sep 13 13:11:45 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Fri, 13 Sep 2024 13:11:45 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v15]
In-Reply-To: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
Message-ID: <CCz9B03dUxzua_YHk9-nyyHS_FTa6axwrwYjACcz4Y0=.6052f53c-9ddb-4868-a817-aff4276a2b6a@github.com>

> This is the main body of the JEP 450: Compact Object Headers (Experimental).
> 
> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing.
> 
> Main changes:
>  - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers.
>  - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded.
>  - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops).
>  - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all).
>  - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16).
>  - Arrays will now store their length at offset 8.
>  - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _coh variants of CDS archiv...

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

  Various touch-ups

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20677/files
  - new: https://git.openjdk.org/jdk/pull/20677/files/69f1ef1d..990926f5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20677&range=14
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20677&range=13-14

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

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

From stefank at openjdk.org  Fri Sep 13 13:18:16 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Fri, 13 Sep 2024 13:18:16 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v14]
In-Reply-To: <QHJWe_7rjgKSw78ZIDsmkLL5gZJLzUT2M_lJE2WSSLo=.678f9de1-0cdb-46d9-8dbe-9362aeb494fe@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <3-nOaxvBWIcOLzCOlrWPzJtsYRknVz5JIwx21X8xkIg=.6ce32f15-a4d6-44d5-9b9e-c3015de45e66@github.com>
 <tiMTCfGoBUlu_Sm2daFxgrO5QLzVXU_jWolWV_Vk7nk=.a9e0ba6e-b436-454d-9a76-173cd1e83639@github.com>
 <QHJWe_7rjgKSw78ZIDsmkLL5gZJLzUT2M_lJE2WSSLo=.678f9de1-0cdb-46d9-8dbe-9362aeb494fe@github.com>
Message-ID: <FVXBfTUdHro_ESmy-NA-ZfkOetfGUrgoEFGysqI5a6k=.27b7179b-14e5-4500-943c-8b160eb5da5b@github.com>

On Fri, 13 Sep 2024 12:53:29 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> src/hotspot/share/oops/oop.inline.hpp line 295:
>> 
>>> 293: // Used by scavengers
>>> 294: void oopDesc::forward_to(oop p) {
>>> 295:   assert(cast_from_oop<oopDesc*>(p) != this,
>> 
>> Do we really need the cast here?
>
> Yes, otherwise compiler complains about ambiguous != operator.

OK, we shouldn't need to. It seems like I can silence the compiler by tweaking oopsHierarchy.hpp. I'll deal with that as a follow-up.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1758853099

From tschatzl at openjdk.org  Fri Sep 13 13:51:16 2024
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Fri, 13 Sep 2024 13:51:16 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v8]
In-Reply-To: <v0VLG-aoo8NDw4RxMWa66ktvblMg741lPUUEle69V60=.82823ab0-b6f1-4a81-a29b-58be35fca1a0@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <J0g0PSye768dhN3JoXFsZ6FivocNBLPmHNtRUCOmLTw=.5756c64a-4763-4727-9637-ba3fe7b9b17d@github.com>
 <6usTXIvS83aO2VzX5xu2EnXlpIJ8YbfrWS6b3EI0MhE=.0e8cc603-0cd3-4bd9-b309-55e4dd0f0cb0@github.com>
 <ZDRwCJRCHrlH268CzJ4P7VDJXnGar40Fl4t_W28L99Y=.c9ad4810-4040-494b-8d54-96160fcd6046@github.com>
 <Iv-aWPSvR4eZY9bek0msxpkDVQnvT9XyGcXEAhJ6UWo=.6e03e898-cba2-444f-b075-5b5fae3059c5@github.com>
 <TSrOBVP-x_1zWFqLynDcmtPSgONPen7W5HZ7bwD4_D4=.406eff89-e0da-40a1-998e-7a77c895fdd9@github.com>
 <v0VLG-aoo8NDw4RxMWa66ktvblMg741lPUUEle69V60=.82823ab0-b6f1-4a81-a29b-58be35fca1a0@github.com>
Message-ID: <HJO2ejuvN1xEutkOZUct_W9ayVEFqSsUt91S1lybKOo=.60019b1c-a1f4-4ce3-b4db-58f0e58e106a@github.com>

On Fri, 13 Sep 2024 12:48:53 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> If you've already fixed this for GC then I agree that we could remove this.
>
> This seems like something that should be done as a separate patch that gets pushed before this PR.

Will remove in JDK-8340119.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1758906485

From wkemper at openjdk.org  Fri Sep 13 14:17:15 2024
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 13 Sep 2024 14:17:15 GMT
Subject: RFR: Merge openjdk/jdk:master
Message-ID: <zppzsQWzZhGwpTxGg1sKzUqbumITN6uvkJtsjrEnW00=.ede73fe9-c3e7-474b-aa83-305561c1585e@github.com>

Merges tag jdk-24+15

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

Commit messages:
 - 8334165: Remove serialVersionUID compatibility logic from JMX
 - 8339733: C2: some nodes can have incorrect control after do_range_check()
 - 8339731: java.desktop/share/classes/javax/swing/text/html/default.css typo in margin settings
 - 8339159: api/java_rmi/Naming/Rebind.html crashes with SEGV from UTF8::quoted_ascii_length call
 - 8339835: Replace usages of -mx and -ms in some client-libs tests
 - 8339834: Replace usages of -mx and -ms in some tests
 - 8339678: Update runtime/condy tests to be executed with VM flags
 - 8299419: Thread.sleep(millis) may throw OOME
 - 8335362: [Windows] Stack pointer increment in _cont_thaw stub can cause program to terminate with exit code 0xc0000005
 - 8339801: Add better test failure diagnostics to vmTestbase/nsk/jdi/EventRequestManager/threadStartRequests/thrstartreq002
 - ... and 290 more: https://git.openjdk.org/shenandoah/compare/4c344335...3c40afa5

The webrev contains the conflicts with master:
 - merge conflicts: https://webrevs.openjdk.org/?repo=shenandoah&pr=499&range=00.conflicts

Changes: https://git.openjdk.org/shenandoah/pull/499/files
  Stats: 44708 lines in 1349 files changed: 27354 ins; 10370 del; 6984 mod
  Patch: https://git.openjdk.org/shenandoah/pull/499.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah.git pull/499/head:pull/499

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

From wkemper at openjdk.org  Fri Sep 13 17:58:11 2024
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 13 Sep 2024 17:58:11 GMT
Subject: RFR: 8340137: GenShen: Reset mark bitmaps when a region is recycled
Message-ID: <Q8VdOP97kNcDMSmE_hHCkFzdX4B8iPxfoGg7tlzVXVI=.38ad995c-f4a3-4153-8061-f706a2aa4983@github.com>

Historically, the concurrent reset phase has reset bitmaps for _all_ committed regions. In the generational mode, however, we wish to reset bitmaps for only the generation being collected. This action was recently made to exclude free regions. This broke an assert for regions that became committed (active) after concurrent reset. To address this, we can reset bitmaps for a region when it is recycled (resets still happen for active regions during concurrent reset).

## Testing
GHA, internal pipelines

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

Commit messages:
 - Clear bitmaps when region is recycled

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

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

From wkemper at openjdk.org  Fri Sep 13 18:14:35 2024
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 13 Sep 2024 18:14:35 GMT
Subject: Integrated: 8338341: GenShen: Cleanup headers,
 unreachable code and unintentional changes
In-Reply-To: <UCcZFmAbRcrR6h6YloKu1FE5rII5qckL1bOLTXzkAso=.e65411ee-4371-43cc-b06e-7c724793e7ca@github.com>
References: <UCcZFmAbRcrR6h6YloKu1FE5rII5qckL1bOLTXzkAso=.e65411ee-4371-43cc-b06e-7c724793e7ca@github.com>
Message-ID: <pyGpdKbMpzW9y6R6l-LQcdH12Gdwyg7abDdXuauuz70=.0b6516d8-96a1-468a-886f-300742395546@github.com>

On Fri, 13 Sep 2024 00:05:57 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Conflict in file changed on tip, but doesn't exist in 21.

This pull request has now been integrated.

Changeset: c108fe53
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.org/shenandoah-jdk21u/commit/c108fe535eb011408c30888ca3165460ac5854c5
Stats:     33 lines in 7 files changed: 0 ins; 26 del; 7 mod

8338341: GenShen: Cleanup headers, unreachable code and unintentional changes

Reviewed-by: kdnilsen, ysr
Backport-of: add6eb6852a0dcfad4502bbe64c9d2b429aa2819

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

PR: https://git.openjdk.org/shenandoah-jdk21u/pull/80

From kdnilsen at openjdk.org  Fri Sep 13 19:23:29 2024
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Fri, 13 Sep 2024 19:23:29 GMT
Subject: RFR: 8340137: GenShen: Reset mark bitmaps when a region is
 recycled
In-Reply-To: <Q8VdOP97kNcDMSmE_hHCkFzdX4B8iPxfoGg7tlzVXVI=.38ad995c-f4a3-4153-8061-f706a2aa4983@github.com>
References: <Q8VdOP97kNcDMSmE_hHCkFzdX4B8iPxfoGg7tlzVXVI=.38ad995c-f4a3-4153-8061-f706a2aa4983@github.com>
Message-ID: <5oY2UjdPgzklKv0Qfhtx668eRUGNYqloYbLk6e4kNa4=.056e3803-ecae-4cf5-a982-1ab70a7694cc@github.com>

On Fri, 13 Sep 2024 17:53:00 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Historically, the concurrent reset phase has reset bitmaps for _all_ committed regions. In the generational mode, however, we wish to reset bitmaps for only the generation being collected. This action was recently made to exclude free regions. This broke an assert for regions that became committed (active) after concurrent reset. To address this, we can reset bitmaps for a region when it is recycled (resets still happen for active regions during concurrent reset).
> 
> ## Testing
> GHA, internal pipelines

Marked as reviewed by kdnilsen (Committer).

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

PR Review: https://git.openjdk.org/shenandoah/pull/500#pullrequestreview-2303929357

From kdnilsen at openjdk.org  Fri Sep 13 19:25:26 2024
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Fri, 13 Sep 2024 19:25:26 GMT
Subject: RFR: 8339643: Port JEP 404 to RISC-V [v2]
In-Reply-To: <yEiP-f7USvTdorMQHNEIiJuwNgAcf_Gf9uOJvRVA8yk=.5f1e27d8-8e52-47e6-848f-fd9c924cd107@github.com>
References: <J3I-KZdj2aYAEN7cFFDkuZEpp6WBM7AFaikL14CDdWM=.5f1201e3-3ca2-426e-b6ce-a4bd9aa9a879@github.com>
 <yEiP-f7USvTdorMQHNEIiJuwNgAcf_Gf9uOJvRVA8yk=.5f1e27d8-8e52-47e6-848f-fd9c924cd107@github.com>
Message-ID: <cGzX3qpHfNz6be7q5uOU210uDl0ruhAEgATNFDGz2-0=.12d3a64d-3ac2-4c4b-894f-9d6cdb800322@github.com>

On Fri, 13 Sep 2024 03:47:46 GMT, Fei Yang <fyang at openjdk.org> wrote:

>> The riscv64 implementation of [JDK-8337511](https://bugs.openjdk.org/browse/JDK-8337511) Implement JEP-404: Generational Shenandoah (Experimental).
>> This is mainly adapted from the changes in aarch64.
>> 
>> Testing
>> - [x] Gtest (release & fastdebug)
>> - [x] hotspot_gc_shenandoah (release & fastdebug)
>
> Fei Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review

Marked as reviewed by kdnilsen (Committer).

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

PR Review: https://git.openjdk.org/shenandoah/pull/493#pullrequestreview-2303934044

From kdnilsen at openjdk.org  Fri Sep 13 19:25:26 2024
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Fri, 13 Sep 2024 19:25:26 GMT
Subject: RFR: 8339643: Port JEP 404 to RISC-V [v2]
In-Reply-To: <1VYKIEPGwMhD0q1vaJpvof0g38A6N5ueIRm-c-6tzCE=.73ddff29-f966-426d-ac31-96c8d9befd9f@github.com>
References: <J3I-KZdj2aYAEN7cFFDkuZEpp6WBM7AFaikL14CDdWM=.5f1201e3-3ca2-426e-b6ce-a4bd9aa9a879@github.com>
 <eZrJyMxkvVjLgFS8loLGEnVYfLqWwNuMsKWog1qpHOw=.055368a5-2712-481c-9e10-8b6e864686d5@github.com>
 <1VYKIEPGwMhD0q1vaJpvof0g38A6N5ueIRm-c-6tzCE=.73ddff29-f966-426d-ac31-96c8d9befd9f@github.com>
Message-ID: <kwD0ssIpIxp7YdrXGX28GVRnlMfneKdnRYuGPiqKugM=.a9bffd0c-12a0-4f3b-b4aa-2279e7f8f084@github.com>

On Fri, 13 Sep 2024 03:53:18 GMT, Fei Yang <fyang at openjdk.org> wrote:

>> src/hotspot/cpu/riscv/gc/shenandoah/shenandoahBarrierSetAssembler_riscv.cpp line 579:
>> 
>>> 577:   __ bind(L_loop);
>>> 578:   __ add(tmp, start, count);
>>> 579:   __ sb(zr, Address(tmp));
>> 
>> Do we want to condition behavior on UseCondCardMark?  Other architectures are considering this.
>
> Seems still under discussion? I will provide further update once it's resolved.

That's fine.  It is an optimization that might perform better when/if implemented.

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

PR Review Comment: https://git.openjdk.org/shenandoah/pull/493#discussion_r1759383061

From ysr at openjdk.org  Fri Sep 13 19:32:28 2024
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Fri, 13 Sep 2024 19:32:28 GMT
Subject: RFR: 8340137: GenShen: Reset mark bitmaps when a region is
 recycled
In-Reply-To: <Q8VdOP97kNcDMSmE_hHCkFzdX4B8iPxfoGg7tlzVXVI=.38ad995c-f4a3-4153-8061-f706a2aa4983@github.com>
References: <Q8VdOP97kNcDMSmE_hHCkFzdX4B8iPxfoGg7tlzVXVI=.38ad995c-f4a3-4153-8061-f706a2aa4983@github.com>
Message-ID: <Q2KoVDX0PxOFv7_-0NU2N9IMQ_Zd4X6y20wmIkQsfG0=.04d161e8-4c5d-46ed-8d2b-6c75ea71af5a@github.com>

On Fri, 13 Sep 2024 17:53:00 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Historically, the concurrent reset phase has reset bitmaps for _all_ committed regions. In the generational mode, however, we wish to reset bitmaps for only the generation being collected. This action was recently made to exclude free regions. This broke an assert for regions that became committed (active) after concurrent reset. To address this, we can reset bitmaps for a region when it is recycled (resets still happen for active regions during concurrent reset).
> 
> ## Testing
> GHA, internal pipelines

Thanks for finding and fixing this issue!

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

Marked as reviewed by ysr (Committer).

PR Review: https://git.openjdk.org/shenandoah/pull/500#pullrequestreview-2303946173

From kdnilsen at openjdk.org  Fri Sep 13 19:39:21 2024
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Fri, 13 Sep 2024 19:39:21 GMT
Subject: RFR: 8339197: GenShen: Adding Generation and Evacuation Information
 JFR Logging
Message-ID: <opdPiC2deogh0GwB9hj9t8BQ5H0nfKoFX19NvpAP61k=.af1900d6-fedb-4448-a662-a7445949ca16@github.com>

This pull request contains a backport of commit 662d146d from the openjdk/shenandoah repository.

The commit being backported was authored by Satyen Subramaniam on 4 Sep 2024 and was reviewed by Kelvin Nilsen,
William Kemper and Y. Srinivas Ramakrishna.

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

Commit messages:
 - Backport 662d146d52dd77d13cfe705a4a4959c5fb2fb5a1

Changes: https://git.openjdk.org/shenandoah-jdk21u/pull/81/files
  Webrev: https://webrevs.openjdk.org/?repo=shenandoah-jdk21u&pr=81&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8339197
  Stats: 323 lines in 10 files changed: 312 ins; 5 del; 6 mod
  Patch: https://git.openjdk.org/shenandoah-jdk21u/pull/81.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah-jdk21u.git pull/81/head:pull/81

PR: https://git.openjdk.org/shenandoah-jdk21u/pull/81

From wkemper at openjdk.org  Fri Sep 13 20:08:00 2024
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 13 Sep 2024 20:08:00 GMT
Subject: RFR: 8338336: GenShen: Cleanup stale TODOs
Message-ID: <khxYuuSktHTC6xn2fHCQ5lgyvos0FeZbZ4826dqk1jE=.9d6261f1-505e-4e34-9b46-e01550ec9a0c@github.com>

Conflict with https://bugs.openjdk.org/browse/JDK-8332082, left barrier code in 21 unchanged.

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

Commit messages:
 - 8338336: GenShen: Cleanup stale TODOs

Changes: https://git.openjdk.org/shenandoah-jdk21u/pull/82/files
  Webrev: https://webrevs.openjdk.org/?repo=shenandoah-jdk21u&pr=82&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8338336
  Stats: 113 lines in 11 files changed: 3 ins; 82 del; 28 mod
  Patch: https://git.openjdk.org/shenandoah-jdk21u/pull/82.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah-jdk21u.git pull/82/head:pull/82

PR: https://git.openjdk.org/shenandoah-jdk21u/pull/82

From wkemper at openjdk.org  Fri Sep 13 20:20:37 2024
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 13 Sep 2024 20:20:37 GMT
Subject: RFR: 8338336: GenShen: Cleanup stale TODOs [v2]
In-Reply-To: <khxYuuSktHTC6xn2fHCQ5lgyvos0FeZbZ4826dqk1jE=.9d6261f1-505e-4e34-9b46-e01550ec9a0c@github.com>
References: <khxYuuSktHTC6xn2fHCQ5lgyvos0FeZbZ4826dqk1jE=.9d6261f1-505e-4e34-9b46-e01550ec9a0c@github.com>
Message-ID: <qw9HSxsQQEVeAMV7kADnRZ4-_LutWCVAXWK2W_XZ99M=.ae9282d8-a43d-4d6c-8ab8-82683a5c9bcc@github.com>

> Conflict with https://bugs.openjdk.org/browse/JDK-8332082, left barrier code in 21 unchanged.

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

  Still have incremental mode in 21

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

Changes:
  - all: https://git.openjdk.org/shenandoah-jdk21u/pull/82/files
  - new: https://git.openjdk.org/shenandoah-jdk21u/pull/82/files/bcefbbf1..6b41045b

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

  Stats: 8 lines in 1 file changed: 8 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/shenandoah-jdk21u/pull/82.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah-jdk21u.git pull/82/head:pull/82

PR: https://git.openjdk.org/shenandoah-jdk21u/pull/82

From kdnilsen at openjdk.org  Fri Sep 13 20:28:26 2024
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Fri, 13 Sep 2024 20:28:26 GMT
Subject: RFR: 8338336: GenShen: Cleanup stale TODOs [v2]
In-Reply-To: <qw9HSxsQQEVeAMV7kADnRZ4-_LutWCVAXWK2W_XZ99M=.ae9282d8-a43d-4d6c-8ab8-82683a5c9bcc@github.com>
References: <khxYuuSktHTC6xn2fHCQ5lgyvos0FeZbZ4826dqk1jE=.9d6261f1-505e-4e34-9b46-e01550ec9a0c@github.com>
 <qw9HSxsQQEVeAMV7kADnRZ4-_LutWCVAXWK2W_XZ99M=.ae9282d8-a43d-4d6c-8ab8-82683a5c9bcc@github.com>
Message-ID: <XNDN_oweC7Cxz87eHsyodHbf-H-KOgwhkZ46tvDE5K8=.cafc4423-7d53-464d-a6f4-6cc400b45750@github.com>

On Fri, 13 Sep 2024 20:20:37 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> Conflict with https://bugs.openjdk.org/browse/JDK-8332082, left barrier code in 21 unchanged.
>
> William Kemper has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Still have incremental mode in 21

Marked as reviewed by kdnilsen (Committer).

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

PR Review: https://git.openjdk.org/shenandoah-jdk21u/pull/82#pullrequestreview-2304063216

From wkemper at openjdk.org  Fri Sep 13 20:45:27 2024
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 13 Sep 2024 20:45:27 GMT
Subject: Integrated: 8338336: GenShen: Cleanup stale TODOs
In-Reply-To: <khxYuuSktHTC6xn2fHCQ5lgyvos0FeZbZ4826dqk1jE=.9d6261f1-505e-4e34-9b46-e01550ec9a0c@github.com>
References: <khxYuuSktHTC6xn2fHCQ5lgyvos0FeZbZ4826dqk1jE=.9d6261f1-505e-4e34-9b46-e01550ec9a0c@github.com>
Message-ID: <UGsIop7ueolC8KYGATG4liE4RnZgMB-J81_s5Z-Efu4=.f494cc0c-9b6c-4135-a34d-66f1aea1d881@github.com>

On Fri, 13 Sep 2024 20:01:51 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Conflict with https://bugs.openjdk.org/browse/JDK-8332082, left barrier code in 21 unchanged.

This pull request has now been integrated.

Changeset: 97ca83b0
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.org/shenandoah-jdk21u/commit/97ca83b08807c01324f7a8a8a1c47dad39cb2b41
Stats:     105 lines in 11 files changed: 3 ins; 74 del; 28 mod

8338336: GenShen: Cleanup stale TODOs

Reviewed-by: kdnilsen
Backport-of: d310008b7874ae6dd4354fb23b8e01fab254038c

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

PR: https://git.openjdk.org/shenandoah-jdk21u/pull/82

From wkemper at openjdk.org  Fri Sep 13 21:18:34 2024
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 13 Sep 2024 21:18:34 GMT
Subject: Integrated: 8338420: GenShen: Forward declare card table for
 Shenandoah barrier set
Message-ID: <kgN__keMhCUFuk8NAKEUPdMZSAYoiAGndQr7rEUJpBk=.c5c6d14b-83c8-4966-83fb-eaa26c75003f@github.com>

Trivial include conflict.

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

Commit messages:
 - Fix include
 - Backport 5c94dd648423351837fd6ebfb4e3fec2f6d79f68

Changes: https://git.openjdk.org/shenandoah-jdk21u/pull/83/files
  Webrev: https://webrevs.openjdk.org/?repo=shenandoah-jdk21u&pr=83&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8338420
  Stats: 12 lines in 6 files changed: 8 ins; 4 del; 0 mod
  Patch: https://git.openjdk.org/shenandoah-jdk21u/pull/83.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah-jdk21u.git pull/83/head:pull/83

PR: https://git.openjdk.org/shenandoah-jdk21u/pull/83

From wkemper at openjdk.org  Fri Sep 13 21:18:34 2024
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 13 Sep 2024 21:18:34 GMT
Subject: Integrated: 8338420: GenShen: Forward declare card table for
 Shenandoah barrier set
In-Reply-To: <kgN__keMhCUFuk8NAKEUPdMZSAYoiAGndQr7rEUJpBk=.c5c6d14b-83c8-4966-83fb-eaa26c75003f@github.com>
References: <kgN__keMhCUFuk8NAKEUPdMZSAYoiAGndQr7rEUJpBk=.c5c6d14b-83c8-4966-83fb-eaa26c75003f@github.com>
Message-ID: <QA3pZ4Q7wytm642IrfO619KsgHneH01wCtmQcR9KpW0=.5f4e1784-6f6d-40e7-b21c-1578d5f028c4@github.com>

On Fri, 13 Sep 2024 21:11:35 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Trivial include conflict.

This pull request has now been integrated.

Changeset: 1eee9202
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.org/shenandoah-jdk21u/commit/1eee9202d63fed7f204502b773a56c36667ca7fb
Stats:     12 lines in 6 files changed: 8 ins; 4 del; 0 mod

8338420: GenShen: Forward declare card table for Shenandoah barrier set

Backport-of: 5c94dd648423351837fd6ebfb4e3fec2f6d79f68

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

PR: https://git.openjdk.org/shenandoah-jdk21u/pull/83

From wkemper at openjdk.org  Fri Sep 13 21:31:01 2024
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 13 Sep 2024 21:31:01 GMT
Subject: RFR: 8338473: GenShen: Cleanup access levels, whitespace,
 typos and unused code
Message-ID: <mjtdSeD-mCZek_A1nqUp3Xw8o4qtx8rKAmU17a94ZzI=.c39f980f-0987-42cb-bf74-62ee4501b5f0@github.com>

Clean backport

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

Commit messages:
 - Backport 7cc63abcb28f5e1db9303fb174be382809387901

Changes: https://git.openjdk.org/shenandoah-jdk21u/pull/84/files
  Webrev: https://webrevs.openjdk.org/?repo=shenandoah-jdk21u&pr=84&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8338473
  Stats: 58 lines in 9 files changed: 3 ins; 45 del; 10 mod
  Patch: https://git.openjdk.org/shenandoah-jdk21u/pull/84.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah-jdk21u.git pull/84/head:pull/84

PR: https://git.openjdk.org/shenandoah-jdk21u/pull/84

From wkemper at openjdk.org  Fri Sep 13 21:48:25 2024
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 13 Sep 2024 21:48:25 GMT
Subject: Integrated: 8338473: GenShen: Cleanup access levels, whitespace,
 typos and unused code
In-Reply-To: <mjtdSeD-mCZek_A1nqUp3Xw8o4qtx8rKAmU17a94ZzI=.c39f980f-0987-42cb-bf74-62ee4501b5f0@github.com>
References: <mjtdSeD-mCZek_A1nqUp3Xw8o4qtx8rKAmU17a94ZzI=.c39f980f-0987-42cb-bf74-62ee4501b5f0@github.com>
Message-ID: <Od2odEjkG0ilTvghwTRYOpPtqpB5Ns0ev2WHd2stvxM=.46f9f636-cb35-42b6-95a0-1e3b4630f8a1@github.com>

On Fri, 13 Sep 2024 21:24:51 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Clean backport

This pull request has now been integrated.

Changeset: eaffb309
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.org/shenandoah-jdk21u/commit/eaffb309faea3cdc4d8d0fed0ebd0a9ba9c27aaa
Stats:     58 lines in 9 files changed: 3 ins; 45 del; 10 mod

8338473: GenShen: Cleanup access levels, whitespace, typos and unused code

Backport-of: 7cc63abcb28f5e1db9303fb174be382809387901

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

PR: https://git.openjdk.org/shenandoah-jdk21u/pull/84

From wkemper at openjdk.org  Fri Sep 13 22:50:07 2024
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 13 Sep 2024 22:50:07 GMT
Subject: RFR: 8338479: GenShen: Detemplatize ShenandoahScanRemembered
Message-ID: <A-iy0g39aaagcdAmZyXNtOMO6cWA7ByamShsp57xIGY=.666e86dc-3816-41e5-954c-fb8dcc5187bf@github.com>

Clean backport

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

Commit messages:
 - Backport 78277f9f6e61ecc61eddd3fa72d963f08d7e754f

Changes: https://git.openjdk.org/shenandoah-jdk21u/pull/85/files
  Webrev: https://webrevs.openjdk.org/?repo=shenandoah-jdk21u&pr=85&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8338479
  Stats: 1216 lines in 10 files changed: 545 ins; 625 del; 46 mod
  Patch: https://git.openjdk.org/shenandoah-jdk21u/pull/85.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah-jdk21u.git pull/85/head:pull/85

PR: https://git.openjdk.org/shenandoah-jdk21u/pull/85

From wkemper at openjdk.org  Fri Sep 13 22:54:50 2024
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 13 Sep 2024 22:54:50 GMT
Subject: RFR: 8339960: GenShen: Fix inconsistencies in generational
 Shenandoah behavior
In-Reply-To: <jgNu9Ijgc-5vBhFQrcRy-y14tffgH1sqAHlI8byFOJg=.8be61718-9d62-45f3-b55a-375da8ecea54@github.com>
References: <jgNu9Ijgc-5vBhFQrcRy-y14tffgH1sqAHlI8byFOJg=.8be61718-9d62-45f3-b55a-375da8ecea54@github.com>
Message-ID: <LUnLe-pWJ4RtrS9rhvul0u74RLZHyzIDLW9IjB41m3A=.8b2682b9-b39a-4956-82ed-06a6490e6a27@github.com>

On Wed, 11 Sep 2024 16:25:43 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

> This fixes some bugs found in recent code review and playback of an assertion failure.

Marked as reviewed by wkemper (Committer).

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

PR Review: https://git.openjdk.org/shenandoah/pull/497#pullrequestreview-2304274268

From wkemper at openjdk.org  Fri Sep 13 22:57:17 2024
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 13 Sep 2024 22:57:17 GMT
Subject: RFR: 8339960: Shenandoah: Fix inconsistencies in generational
 Shenandoah behaviors
In-Reply-To: <vzXjdQg2wTPzgTG1aU7_CUnAxtnlt_2o01drZXtI324=.100816d9-1ed5-497c-be51-fd540f496cb7@github.com>
References: <vzXjdQg2wTPzgTG1aU7_CUnAxtnlt_2o01drZXtI324=.100816d9-1ed5-497c-be51-fd540f496cb7@github.com>
Message-ID: <FpbbX-7rc4IUjBybSWLEsbalDIINOIULk26piRxX8J4=.dbb3df5a-cf37-4cdc-83b0-b3c4af0e3679@github.com>

On Thu, 12 Sep 2024 20:23:36 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

> This fixes some bugs found in recent code review and playback of an assertion failure.
> 
> See also https://github.com/openjdk/shenandoah/pull/497

Looks good to me.

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

Marked as reviewed by wkemper (Committer).

PR Review: https://git.openjdk.org/jdk/pull/20974#pullrequestreview-2304276183

From wkemper at openjdk.org  Fri Sep 13 23:01:39 2024
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 13 Sep 2024 23:01:39 GMT
Subject: RFR: 8339611: GenShen: Simplify
 ShenandoahOldHeuristics::trigger_collection_if_fragmented [v4]
In-Reply-To: <FDHtu2l4eaY7n2rtSV5fKKOcPNXmGrtu85d6_0mLRX8=.b7ca12d0-1801-4805-88e8-285f00454442@github.com>
References: <q3WvOqHO5pxBtaFlO2Ep4ZibIB1nyEPyQ-1to21TqS4=.31ba4e8d-2096-4bb4-aad5-902839638ac9@github.com>
 <FDHtu2l4eaY7n2rtSV5fKKOcPNXmGrtu85d6_0mLRX8=.b7ca12d0-1801-4805-88e8-285f00454442@github.com>
Message-ID: <Bmtfrvk_hj8PizHMYpw2AgKASX0UoM7EfA_zUqlQy2w=.a6f776db-e7be-44ba-ade2-90eb648d3e64@github.com>

On Wed, 11 Sep 2024 17:54:53 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> Replace iterative solution with a single mathematical computation, and adjust old-gen defragmentation efforts to be a bit less aggressive.
>
> Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Respond to reviewer feedback

Marked as reviewed by wkemper (Committer).

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

PR Review: https://git.openjdk.org/shenandoah/pull/492#pullrequestreview-2304278395

From wkemper at openjdk.org  Fri Sep 13 23:03:41 2024
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 13 Sep 2024 23:03:41 GMT
Subject: Integrated: 8338479: GenShen: Detemplatize ShenandoahScanRemembered
In-Reply-To: <A-iy0g39aaagcdAmZyXNtOMO6cWA7ByamShsp57xIGY=.666e86dc-3816-41e5-954c-fb8dcc5187bf@github.com>
References: <A-iy0g39aaagcdAmZyXNtOMO6cWA7ByamShsp57xIGY=.666e86dc-3816-41e5-954c-fb8dcc5187bf@github.com>
Message-ID: <n-ORUFuun98VcOlCiah2d_I92x0b459REQiQjydF3og=.a9551469-6404-487b-9567-41ae83949f24@github.com>

On Fri, 13 Sep 2024 22:44:12 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Clean backport

This pull request has now been integrated.

Changeset: fe6aec1e
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.org/shenandoah-jdk21u/commit/fe6aec1eff4edb67961644b2fb687aee044d0307
Stats:     1216 lines in 10 files changed: 545 ins; 625 del; 46 mod

8338479: GenShen: Detemplatize ShenandoahScanRemembered

Backport-of: 78277f9f6e61ecc61eddd3fa72d963f08d7e754f

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

PR: https://git.openjdk.org/shenandoah-jdk21u/pull/85

From kdnilsen at openjdk.org  Fri Sep 13 23:09:24 2024
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Fri, 13 Sep 2024 23:09:24 GMT
Subject: Integrated: 8339960: GenShen: Fix inconsistencies in generational
 Shenandoah behavior
In-Reply-To: <jgNu9Ijgc-5vBhFQrcRy-y14tffgH1sqAHlI8byFOJg=.8be61718-9d62-45f3-b55a-375da8ecea54@github.com>
References: <jgNu9Ijgc-5vBhFQrcRy-y14tffgH1sqAHlI8byFOJg=.8be61718-9d62-45f3-b55a-375da8ecea54@github.com>
Message-ID: <XG70Zh4ZnrjGvVU131OLwpbTrKUQRtaE4CJzeTYcotg=.97d16b9a-e8c7-4a30-8015-8373a7bac244@github.com>

On Wed, 11 Sep 2024 16:25:43 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

> This fixes some bugs found in recent code review and playback of an assertion failure.

This pull request has now been integrated.

Changeset: 1a7d597d
Author:    Kelvin Nilsen <kdnilsen at openjdk.org>
URL:       https://git.openjdk.org/shenandoah/commit/1a7d597dad0fb3560f88f582ab760cca28cf54fd
Stats:     28 lines in 1 file changed: 20 ins; 0 del; 8 mod

8339960: GenShen: Fix inconsistencies in generational Shenandoah behavior

Reviewed-by: wkemper

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

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

From kdnilsen at openjdk.org  Fri Sep 13 23:10:40 2024
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Fri, 13 Sep 2024 23:10:40 GMT
Subject: Integrated: 8339611: GenShen: Simplify
 ShenandoahOldHeuristics::trigger_collection_if_fragmented
In-Reply-To: <q3WvOqHO5pxBtaFlO2Ep4ZibIB1nyEPyQ-1to21TqS4=.31ba4e8d-2096-4bb4-aad5-902839638ac9@github.com>
References: <q3WvOqHO5pxBtaFlO2Ep4ZibIB1nyEPyQ-1to21TqS4=.31ba4e8d-2096-4bb4-aad5-902839638ac9@github.com>
Message-ID: <zxFw8c6Rezpv80arHR6E7UtyDjsH6QkKic-6e4R9wJ8=.7ca04cff-da4c-42de-b8b9-d95047c6f177@github.com>

On Thu, 5 Sep 2024 23:54:52 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

> Replace iterative solution with a single mathematical computation, and adjust old-gen defragmentation efforts to be a bit less aggressive.

This pull request has now been integrated.

Changeset: c38b31af
Author:    Kelvin Nilsen <kdnilsen at openjdk.org>
URL:       https://git.openjdk.org/shenandoah/commit/c38b31afe8ff4fdcdd27a771e72d38b128273f01
Stats:     72 lines in 3 files changed: 25 ins; 15 del; 32 mod

8339611: GenShen: Simplify ShenandoahOldHeuristics::trigger_collection_if_fragmented

Reviewed-by: wkemper

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

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

From wkemper at openjdk.org  Fri Sep 13 23:22:47 2024
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 13 Sep 2024 23:22:47 GMT
Subject: RFR: 8338477: GenShen: Cleanup generational heap
Message-ID: <Soym16UixLe45LhWuh3b8lh8QuBiglhicsZJxE4a0T4=.2e9ebf30-1179-4a74-8dbc-999e58d5ccc4@github.com>

Clean

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

Commit messages:
 - Backport 1ed7586be1c5271e7a223f1cd14effd2a83b0b84

Changes: https://git.openjdk.org/shenandoah-jdk21u/pull/86/files
  Webrev: https://webrevs.openjdk.org/?repo=shenandoah-jdk21u&pr=86&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8338477
  Stats: 231 lines in 2 files changed: 96 ins; 96 del; 39 mod
  Patch: https://git.openjdk.org/shenandoah-jdk21u/pull/86.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah-jdk21u.git pull/86/head:pull/86

PR: https://git.openjdk.org/shenandoah-jdk21u/pull/86

From wkemper at openjdk.org  Fri Sep 13 23:33:19 2024
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 13 Sep 2024 23:33:19 GMT
Subject: Integrated: 8338477: GenShen: Cleanup generational heap
In-Reply-To: <Soym16UixLe45LhWuh3b8lh8QuBiglhicsZJxE4a0T4=.2e9ebf30-1179-4a74-8dbc-999e58d5ccc4@github.com>
References: <Soym16UixLe45LhWuh3b8lh8QuBiglhicsZJxE4a0T4=.2e9ebf30-1179-4a74-8dbc-999e58d5ccc4@github.com>
Message-ID: <LBY7pZ8bg6vtYZltGTrQExJaeR-lMJChsW_YHRgM7Yo=.a26c46b0-19f8-42b5-8a1d-87d31d573d46@github.com>

On Fri, 13 Sep 2024 23:15:47 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Clean

This pull request has now been integrated.

Changeset: cb900e83
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.org/shenandoah-jdk21u/commit/cb900e837f6f70bb235c84f7062162946bf0ef0b
Stats:     231 lines in 2 files changed: 96 ins; 96 del; 39 mod

8338477: GenShen: Cleanup generational heap

Backport-of: 1ed7586be1c5271e7a223f1cd14effd2a83b0b84

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

PR: https://git.openjdk.org/shenandoah-jdk21u/pull/86

From wkemper at openjdk.org  Fri Sep 13 23:48:46 2024
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 13 Sep 2024 23:48:46 GMT
Subject: RFR: 8338535: GenShen: some style improvements to source code
 implementation
Message-ID: <dayEGkHMbHlb8bi_bGHAnwQvzFhQ2eZuRipBaYKA4UA=.9df02ed4-147b-43c8-90ed-fdd5b3f53f47@github.com>

Clean backport

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

Commit messages:
 - Backport 07c540d96592c150ba99ec8c08d4dbcb85f0c7e0

Changes: https://git.openjdk.org/shenandoah-jdk21u/pull/87/files
  Webrev: https://webrevs.openjdk.org/?repo=shenandoah-jdk21u&pr=87&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8338535
  Stats: 112 lines in 16 files changed: 66 ins; 10 del; 36 mod
  Patch: https://git.openjdk.org/shenandoah-jdk21u/pull/87.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah-jdk21u.git pull/87/head:pull/87

PR: https://git.openjdk.org/shenandoah-jdk21u/pull/87

From wkemper at openjdk.org  Fri Sep 13 23:52:23 2024
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 13 Sep 2024 23:52:23 GMT
Subject: Integrated: 8338535: GenShen: some style improvements to source code
 implementation
In-Reply-To: <dayEGkHMbHlb8bi_bGHAnwQvzFhQ2eZuRipBaYKA4UA=.9df02ed4-147b-43c8-90ed-fdd5b3f53f47@github.com>
References: <dayEGkHMbHlb8bi_bGHAnwQvzFhQ2eZuRipBaYKA4UA=.9df02ed4-147b-43c8-90ed-fdd5b3f53f47@github.com>
Message-ID: <Gbd1LMb0f9avbLw_BS8DvYBFdoq-T66WmK79uqIU4Ng=.4037ccab-d85f-41c4-aee3-77d84cd4c048@github.com>

On Fri, 13 Sep 2024 23:43:26 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Clean backport

This pull request has now been integrated.

Changeset: 77cb7a3a
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.org/shenandoah-jdk21u/commit/77cb7a3ad2db2bd5e475f10142e4ee9a8701b304
Stats:     112 lines in 16 files changed: 66 ins; 10 del; 36 mod

8338535: GenShen: some style improvements to source code implementation

Backport-of: 07c540d96592c150ba99ec8c08d4dbcb85f0c7e0

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

PR: https://git.openjdk.org/shenandoah-jdk21u/pull/87

From kdnilsen at openjdk.org  Sat Sep 14 00:08:52 2024
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Sat, 14 Sep 2024 00:08:52 GMT
Subject: RFR: 8339611: GenShen: Simplify
 ShenandoahOldHeuristics::trigger_collection_if_fragmented
Message-ID: <Wbfv5Hn_mjgJ9Fdy_iOu27bFHMWxjbHyWn_bZ9LbChA=.f20657e9-69e4-4c5d-89e8-f3485101a710@github.com>

This pull request contains a backport of commit c38b31af from the openjdk/shenandoah repository.

The commit being backported was authored by Kelvin Nilsen on 13 Sep 2024 and was reviewed by William Kemper.

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

Commit messages:
 - Backport c38b31afe8ff4fdcdd27a771e72d38b128273f01

Changes: https://git.openjdk.org/shenandoah-jdk21u/pull/89/files
  Webrev: https://webrevs.openjdk.org/?repo=shenandoah-jdk21u&pr=89&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8339611
  Stats: 72 lines in 3 files changed: 25 ins; 15 del; 32 mod
  Patch: https://git.openjdk.org/shenandoah-jdk21u/pull/89.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah-jdk21u.git pull/89/head:pull/89

PR: https://git.openjdk.org/shenandoah-jdk21u/pull/89

From wkemper at openjdk.org  Sat Sep 14 00:10:52 2024
From: wkemper at openjdk.org (William Kemper)
Date: Sat, 14 Sep 2024 00:10:52 GMT
Subject: Integrated: 8338528: GenShen: Cleanup shenandoahHeapRegion
Message-ID: <cDY_Rgydp3QfGk05jCq8C1h8AGoM-a4Ji8jzvggyJvI=.55a05738-0f60-4bca-b8c9-ea1c009814c8@github.com>

Clean backport.

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

Commit messages:
 - Backport 27d0e617f97be03fae0b110ca58a3860c15d5679

Changes: https://git.openjdk.org/shenandoah-jdk21u/pull/88/files
  Webrev: https://webrevs.openjdk.org/?repo=shenandoah-jdk21u&pr=88&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8338528
  Stats: 81 lines in 6 files changed: 31 ins; 28 del; 22 mod
  Patch: https://git.openjdk.org/shenandoah-jdk21u/pull/88.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah-jdk21u.git pull/88/head:pull/88

PR: https://git.openjdk.org/shenandoah-jdk21u/pull/88

From wkemper at openjdk.org  Sat Sep 14 00:10:53 2024
From: wkemper at openjdk.org (William Kemper)
Date: Sat, 14 Sep 2024 00:10:53 GMT
Subject: Integrated: 8338528: GenShen: Cleanup shenandoahHeapRegion
In-Reply-To: <cDY_Rgydp3QfGk05jCq8C1h8AGoM-a4Ji8jzvggyJvI=.55a05738-0f60-4bca-b8c9-ea1c009814c8@github.com>
References: <cDY_Rgydp3QfGk05jCq8C1h8AGoM-a4Ji8jzvggyJvI=.55a05738-0f60-4bca-b8c9-ea1c009814c8@github.com>
Message-ID: <0CgrGRHZFeV_VsKHi_jsz2B0pu6fPLia5X3utuJHTfo=.449982cc-7682-4588-9dc0-2633a1044b42@github.com>

On Sat, 14 Sep 2024 00:01:08 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Clean backport.

This pull request has now been integrated.

Changeset: 3c8cffbb
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.org/shenandoah-jdk21u/commit/3c8cffbbef0a3dab507ed9f2e656c8df3c7ed68a
Stats:     81 lines in 6 files changed: 31 ins; 28 del; 22 mod

8338528: GenShen: Cleanup shenandoahHeapRegion

Backport-of: 27d0e617f97be03fae0b110ca58a3860c15d5679

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

PR: https://git.openjdk.org/shenandoah-jdk21u/pull/88

From kdnilsen at openjdk.org  Sat Sep 14 00:12:47 2024
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Sat, 14 Sep 2024 00:12:47 GMT
Subject: RFR: 8339960: GenShen: Fix inconsistencies in generational Shenandoah
 behavior
Message-ID: <iC_hPGmUdI86hXwB8zZ0TUY18L7lPU1HweCLpEjoEo8=.90c27500-49a4-4ed8-9861-e37c0248ba0c@github.com>

This pull request contains a backport of commit 1a7d597d from the openjdk/shenandoah repository.

The commit being backported was authored by Kelvin Nilsen on 13 Sep 2024 and was reviewed by William Kemper.

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

Commit messages:
 - Backport 1a7d597dad0fb3560f88f582ab760cca28cf54fd

Changes: https://git.openjdk.org/shenandoah-jdk21u/pull/90/files
  Webrev: https://webrevs.openjdk.org/?repo=shenandoah-jdk21u&pr=90&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8339960
  Stats: 28 lines in 1 file changed: 20 ins; 0 del; 8 mod
  Patch: https://git.openjdk.org/shenandoah-jdk21u/pull/90.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah-jdk21u.git pull/90/head:pull/90

PR: https://git.openjdk.org/shenandoah-jdk21u/pull/90

From kdnilsen at openjdk.org  Sun Sep 15 02:43:47 2024
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Sun, 15 Sep 2024 02:43:47 GMT
Subject: RFR: 8339611: GenShen: Simplify
 ShenandoahOldHeuristics::trigger_collection_if_fragmented [v2]
In-Reply-To: <Wbfv5Hn_mjgJ9Fdy_iOu27bFHMWxjbHyWn_bZ9LbChA=.f20657e9-69e4-4c5d-89e8-f3485101a710@github.com>
References: <Wbfv5Hn_mjgJ9Fdy_iOu27bFHMWxjbHyWn_bZ9LbChA=.f20657e9-69e4-4c5d-89e8-f3485101a710@github.com>
Message-ID: <29Vz5DMyRNeJ5GUCizzDZifamn5c_3qt80Jcvk-vQBc=.077aefe4-c868-4813-8aed-9ff6c90a8399@github.com>

> This pull request contains a backport of commit c38b31af from the openjdk/shenandoah repository.
> 
> The commit being backported was authored by Kelvin Nilsen on 13 Sep 2024 and was reviewed by William Kemper.

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

  Remove dependency on checkedCast.hpp

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

Changes:
  - all: https://git.openjdk.org/shenandoah-jdk21u/pull/89/files
  - new: https://git.openjdk.org/shenandoah-jdk21u/pull/89/files/5fffc120..226c30b1

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

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

PR: https://git.openjdk.org/shenandoah-jdk21u/pull/89

From stuefe at openjdk.org  Sun Sep 15 06:17:14 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Sun, 15 Sep 2024 06:17:14 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v13]
In-Reply-To: <epFrYZqTWD77IySDqJ9fwFiXZKZ_NCuzA-lfPi6TU_4=.d9c5c483-9a6a-4113-9856-cddcae962f33@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <4iHDH-GpSa-uPqe0IwwP6notHRyrOTiecqCSX9kYCe0=.d7969fd0-3066-42fa-82d4-842c10baee1c@github.com>
 <epFrYZqTWD77IySDqJ9fwFiXZKZ_NCuzA-lfPi6TU_4=.d9c5c483-9a6a-4113-9856-cddcae962f33@github.com>
Message-ID: <Mti73HI8rw7uN-bgm4CxqMvC714P2vtnQ2prQDQ-HXo=.064603a1-fae7-49d5-bd33-f905ac33a19c@github.com>

On Wed, 11 Sep 2024 21:15:21 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revert accidental change of UCOH default
>
> I was starting to understand the concerns with having prototype_header in Klass.  It seems like it would simplify encoding the klass for object allocation.  My recent change https://bugs.openjdk.org/browse/JDK-8338526 breaks this.  You need to pass a parameter to Klass() to tell whether to encode the klass pointer or not, and pass this to Klass() constructor.
> 
>      diff --git a/src/hotspot/share/oops/instanceKlass.cpp b/src/hotspot/share/oops/instanceKlass.cpp
>      index fd198f54fc9..7aa4bd24948 100644
>      --- a/src/hotspot/share/oops/instanceKlass.cpp
>      +++ b/src/hotspot/share/oops/instanceKlass.cpp
>     @@ -511,7 +511,7 @@ InstanceKlass::InstanceKlass() {
>      }
>      
>      InstanceKlass::InstanceKlass(const ClassFileParser& parser, KlassKind kind, ReferenceType reference_type) :
>     -  Klass(kind),
>     +  Klass(kind, (!parser.is_interface() && !parser.is_abstract())),
>        _nest_members(nullptr),
>        _nest_host(nullptr),
>        _permitted_subclasses(nullptr),

@coleenp 

> I was starting to understand the concerns with having prototype_header in Klass. It seems like it would simplify encoding the klass for object allocation. My recent change https://bugs.openjdk.org/browse/JDK-8338526 breaks this. You need to pass a parameter to Klass() to tell whether to encode the klass pointer or not, and pass this to Klass() constructor.
> 

I solved this differently (Roman will merge this into his PR).


static markWord make_prototype(const Klass* kls) {
  markWord prototype = markWord::prototype();
#ifdef _LP64
  if (UseCompactObjectHeaders) {
    // With compact object headers, the narrow Klass ID is part of the mark word.
    // We therfore seed the mark word with the narrow Klass ID.
    // Note that only those Klass that can be instantiated have a narrow Klass ID.
    // For those who don't, we leave the klass bits empty and assert if someone
    // tries to use those.
    const narrowKlass nk = CompressedKlassPointers::is_encodable(kls) ?
        CompressedKlassPointers::encode(const_cast<Klass*>(kls)) : 0;
    prototype = prototype.set_narrow_klass(nk);
  }
#endif
  return prototype;
}

inline bool CompressedKlassPointers::is_encodable(const void* address) {
  check_init(_base);
  // An address can only be encoded if:
  //
  // 1) the address lies within the klass range.
  // 2) It is suitably aligned to 2^encoding_shift. This only really matters for
  //    +UseCompactObjectHeaders, since the encoding shift can be large (max 10 bits -> 1KB).
  return is_aligned(address, klass_alignment_in_bytes()) &&
      address >= _klass_range_start && address < _klass_range_end;
}


So, we put an nKlass into the prototype if we can. We can, if the Klass address is encodable. It is encodable if it lives in the encoded Klass range and is correctly aligned. No need to pass this information via another channel: its right there, in the Klass address. This works even before Klass is initialized.

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

PR Comment: https://git.openjdk.org/jdk/pull/20677#issuecomment-2351399143

From stuefe at openjdk.org  Sun Sep 15 06:17:15 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Sun, 15 Sep 2024 06:17:15 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v11]
In-Reply-To: <b8u6PaStO4nt0AGnbZEkmXkzQKzXaB2c4lSiC9JWdTY=.a5805ef2-84d8-44c0-9dc0-3e90da3460aa@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <DUgk6HT_Zk5KnbmAd_HzrJi4B8D1J-uuoAGzReWyI8s=.6c04f90a-bf1d-49af-a31d-5224973952d4@github.com>
 <b8u6PaStO4nt0AGnbZEkmXkzQKzXaB2c4lSiC9JWdTY=.a5805ef2-84d8-44c0-9dc0-3e90da3460aa@github.com>
Message-ID: <rJRoSXcS7-_XJVMfJ59GKXjV68j7MBkmecVLjpnq1Ks=.2d534dd5-d7ec-4f72-af63-8ca00a6a7406@github.com>

On Wed, 11 Sep 2024 11:25:41 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix FullGCForwarding initialization
>
> src/hotspot/share/memory/metaspace/metablock.hpp line 51:
> 
>> 49:   size_t word_size() const { return _word_size; }
>> 50:   bool is_empty() const { return _base == nullptr; }
>> 51:   bool is_nonempty() const { return _base != nullptr; }
> 
> Can `_base == nullptr` but `_word_size != 0`?

No

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1759973362

From rcastanedalo at openjdk.org  Mon Sep 16 06:56:18 2024
From: rcastanedalo at openjdk.org (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Mon, 16 Sep 2024 06:56:18 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v15]
In-Reply-To: <CCz9B03dUxzua_YHk9-nyyHS_FTa6axwrwYjACcz4Y0=.6052f53c-9ddb-4868-a817-aff4276a2b6a@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <CCz9B03dUxzua_YHk9-nyyHS_FTa6axwrwYjACcz4Y0=.6052f53c-9ddb-4868-a817-aff4276a2b6a@github.com>
Message-ID: <6UJOrZqmfsJj6pRzMjPdlYt191QgBV6fIv1qJAYsv60=.15284272-464f-4321-b76c-3412dafc6c63@github.com>

On Fri, 13 Sep 2024 13:11:45 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> This is the main body of the JEP 450: Compact Object Headers (Experimental).
>> 
>> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing.
>> 
>> Main changes:
>>  - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers.
>>  - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded.
>>  - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops).
>>  - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all).
>>  - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16).
>>  - Arrays will now store their length at offset 8.
>>  - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _co...
>
> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Various touch-ups

src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.cpp line 2576:

> 2574:   } else {
> 2575:     lea(dst, Address(obj, index, Address::lsl(scale)));
> 2576:     ldr(dst, Address(dst, offset));

Do you have a reproducer (or, better yet, a test case) that exercises this case? I ran Oracle's internal CI tiers 1-5 and could never hit it. Could this happen for x64 as well?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1760617744

From rcastanedalo at openjdk.org  Mon Sep 16 08:07:18 2024
From: rcastanedalo at openjdk.org (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Mon, 16 Sep 2024 08:07:18 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v15]
In-Reply-To: <CCz9B03dUxzua_YHk9-nyyHS_FTa6axwrwYjACcz4Y0=.6052f53c-9ddb-4868-a817-aff4276a2b6a@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <CCz9B03dUxzua_YHk9-nyyHS_FTa6axwrwYjACcz4Y0=.6052f53c-9ddb-4868-a817-aff4276a2b6a@github.com>
Message-ID: <mX0ou3n5MzR_tt1nnuLy-cFYj_85cfCK-LHR6KZ-Uwk=.4fca751d-a06a-4c2d-8bb2-eba51d435ef2@github.com>

On Fri, 13 Sep 2024 13:11:45 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> This is the main body of the JEP 450: Compact Object Headers (Experimental).
>> 
>> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing.
>> 
>> Main changes:
>>  - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers.
>>  - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded.
>>  - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops).
>>  - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all).
>>  - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16).
>>  - Arrays will now store their length at offset 8.
>>  - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _co...
>
> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Various touch-ups

> * Note that oopDesc::klass_offset_in_bytes() is not used by +UCOH paths anymore. The only exception is C2, which uses it as a placeholder/identifier of the special memory slice that only LoadNKlass uses. The backend then extracts the original oop and loads its mark-word and extracts the narrow-Klass* from that.

I agree that this is the simplest and least intrusive way of getting klass loading working in C2 for this experimental version of the feature. However, the approach seems brittle and error-prone, and it may be hard to maintain in the long run. Therefore, I think that a more principled and robust modeling will be needed, after this PR is integrated, in preparation for the non-experimental version.

An alternative that seems promising is to hide the object header klass pointer extraction and make it part of the `LoadNKlass` node semantics, as illustrated in this example:

![alternative-modeling](https://github.com/user-attachments/assets/06243966-3065-4969-a2dd-d05133b36366)

`LoadNKlass` nodes can then be expanded into more primitive operations (load and shift for compact headers, load with `klass_offset_in_bytes()` for original headers) within C2's back-end or even during code emission as sketched [here](https://github.com/robcasloz/jdk/commit/6cb4219f101e3be982264071c2cb1d0af1c6d754). @rkennke is this similar to what you tried out ("Expanding it as a macro")?

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

PR Comment: https://git.openjdk.org/jdk/pull/20677#issuecomment-2352253326

From shade at openjdk.org  Mon Sep 16 10:40:16 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 16 Sep 2024 10:40:16 GMT
Subject: RFR: 8340183: Shenandoah: Incorrect match for clone barrier in
 is_gc_barrier_node
Message-ID: <lMJ7zz1QZt3FMIqVLhEpYe6aqMc_uqU_d0P2mWQI4IY=.136a8eb3-b7ae-43f4-b268-5f7a6d189e09@github.com>

The name of the call we emit is "shenandoah_clone":
https://github.com/openjdk/jdk/blob/545951889c1ea68646be600decaf2bf4c049600b/src/hotspot/share/gc/shenandoah/c2/shenandoahBarrierSetC2.cpp#L806

...yet we test for "shenandoah_clone_barrier" here:
https://github.com/openjdk/jdk/blob/545951889c1ea68646be600decaf2bf4c049600b/src/hotspot/share/gc/shenandoah/c2/shenandoahBarrierSetC2.cpp#L688

I think we are better off polling the call target instead of relying on call name. This change also eliminates `shenandoah_cas_obj` matcher, for which we do not have the emitted call ever since we started doing CAS expansions inline.

Additional testing:
 - [x] Linux x86_64 server fastdebug, `hotspot_gc_shenandoah`
 - [ ] Linux x86_64 server fastdebug, `all` with `-XX:+UseShenandoahGC`

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

Commit messages:
 - Fix

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

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

From shade at openjdk.org  Mon Sep 16 10:44:12 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 16 Sep 2024 10:44:12 GMT
Subject: RFR: 8340186: Shenandoah: Missing
 load_reference_barrier_phantom_narrow match in is_shenandoah_lrb_call
Message-ID: <WKF6HOcWBzpASW2-szk8bk_hZ-DN6CGvX9vwkHPM0x0=.7fb65ec8-d648-4b60-ad73-f9c1e1c1b8ce@github.com>

[JDK-8256999](https://bugs.openjdk.org/browse/JDK-8256999) added `ShenandoahRuntime::load_reference_barrier_phantom_narrow`, but missed adding it to `ShenandoahBarrierSetC2::is_shenandoah_lrb_call`. It is currently innocuous, as there are no users of `is_shenandoah_lrb_call`, but it will be important when [JDK-8340183](https://bugs.openjdk.org/browse/JDK-8340183) lands.

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

Commit messages:
 - Fix

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

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

From shade at openjdk.org  Mon Sep 16 10:48:28 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 16 Sep 2024 10:48:28 GMT
Subject: RFR: 8339611: GenShen: Simplify
 ShenandoahOldHeuristics::trigger_collection_if_fragmented [v2]
In-Reply-To: <29Vz5DMyRNeJ5GUCizzDZifamn5c_3qt80Jcvk-vQBc=.077aefe4-c868-4813-8aed-9ff6c90a8399@github.com>
References: <Wbfv5Hn_mjgJ9Fdy_iOu27bFHMWxjbHyWn_bZ9LbChA=.f20657e9-69e4-4c5d-89e8-f3485101a710@github.com>
 <29Vz5DMyRNeJ5GUCizzDZifamn5c_3qt80Jcvk-vQBc=.077aefe4-c868-4813-8aed-9ff6c90a8399@github.com>
Message-ID: <UAlVkYVhEXOkQ7v0oYjTQn12wZm1VlyzPgdV2p7qh4I=.47af63b3-91ff-4137-891f-79d977d1632f@github.com>

On Sun, 15 Sep 2024 02:43:47 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> This pull request contains a backport of commit c38b31af from the openjdk/shenandoah repository.
>> 
>> The commit being backported was authored by Kelvin Nilsen on 13 Sep 2024 and was reviewed by William Kemper.
>
> Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove dependency on checkedCast.hpp

Marked as reviewed by shade (Committer).

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

PR Review: https://git.openjdk.org/shenandoah-jdk21u/pull/89#pullrequestreview-2306300752

From rkennke at openjdk.org  Mon Sep 16 12:38:00 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Mon, 16 Sep 2024 12:38:00 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v16]
In-Reply-To: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
Message-ID: <BFrQL8ZoZKj-jdrRp_6onv4H7lchv46F6dcQ_vMzYZw=.9bb74940-a2d7-4005-bf25-ae2886c9a119@github.com>

> This is the main body of the JEP 450: Compact Object Headers (Experimental).
> 
> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing.
> 
> Main changes:
>  - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers.
>  - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded.
>  - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops).
>  - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all).
>  - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16).
>  - Arrays will now store their length at offset 8.
>  - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _coh variants of CDS archiv...

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

 - Fix  test/hotspot/jtreg/runtime/CompressedOops/CompressedClassPointersEncodingScheme.java
 - Fix loop on aarch64
 - clarify obscure assert in metasapce setup
 - Rework compressedklass encoding
 - remove stray debug output
 - Fixes post 8338526
 - Merge commit '597788850041e7272a23714c05ba546ee6080856' into JDK-8305895-v4
 - Various touch-ups
 - Hide log timestamps in test to prevent false failures
 - Revert accidental change of UCOH default
 - ... and 43 more: https://git.openjdk.org/jdk/compare/59778885...49c87547

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

Changes: https://git.openjdk.org/jdk/pull/20677/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20677&range=15
  Stats: 4605 lines in 190 files changed: 3252 ins; 724 del; 629 mod
  Patch: https://git.openjdk.org/jdk/pull/20677.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20677/head:pull/20677

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

From rkennke at openjdk.org  Mon Sep 16 13:28:00 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Mon, 16 Sep 2024 13:28:00 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v17]
In-Reply-To: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
Message-ID: <_5gI7i33xrOgXMTI_04oX9UDGwhVTtSNWoSiNfM3FOM=.b24979b3-dcde-401f-b2d8-9b201d303f57@github.com>

> This is the main body of the JEP 450: Compact Object Headers (Experimental).
> 
> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing.
> 
> Main changes:
>  - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers.
>  - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded.
>  - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops).
>  - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all).
>  - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16).
>  - Arrays will now store their length at offset 8.
>  - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _coh variants of CDS archiv...

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

 - Merge remote-tracking branch 'origin/master' into JDK-8305895-v4
 - Fix  test/hotspot/jtreg/runtime/CompressedOops/CompressedClassPointersEncodingScheme.java
 - Fix loop on aarch64
 - clarify obscure assert in metasapce setup
 - Rework compressedklass encoding
 - remove stray debug output
 - Fixes post 8338526
 - Merge commit '597788850041e7272a23714c05ba546ee6080856' into JDK-8305895-v4
 - Various touch-ups
 - Hide log timestamps in test to prevent false failures
 - ... and 44 more: https://git.openjdk.org/jdk/compare/54595188...2125cd81

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

Changes: https://git.openjdk.org/jdk/pull/20677/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20677&range=16
  Stats: 4598 lines in 190 files changed: 3245 ins; 719 del; 634 mod
  Patch: https://git.openjdk.org/jdk/pull/20677.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20677/head:pull/20677

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

From rkennke at openjdk.org  Mon Sep 16 13:31:17 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Mon, 16 Sep 2024 13:31:17 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v11]
In-Reply-To: <hkGaBWSugvpV0PgoR9rnutHCgQzkeXv1ctH7QwV3zK0=.204737d5-fadb-410a-8891-7db59d36830f@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <DUgk6HT_Zk5KnbmAd_HzrJi4B8D1J-uuoAGzReWyI8s=.6c04f90a-bf1d-49af-a31d-5224973952d4@github.com>
 <YTte6oY9EeAPHxzzOndL8M202wY91SbeaYC4hPva0W0=.caf00270-89c7-44b0-ab88-a970fb8e840d@github.com>
 <kzodWwxj5qdAqPYcP2s4k2QTXqjju2H6Iftu7dojezk=.1f72fc31-94ba-4017-b330-c8688a8d39a4@github.com>
 <hkGaBWSugvpV0PgoR9rnutHCgQzkeXv1ctH7QwV3zK0=.204737d5-fadb-410a-8891-7db59d36830f@github.com>
Message-ID: <cjnJhjaNZpKO7F4Tx0zQEnBuJ_vWFxddjqXrwS35Sx8=.43a14afb-8f60-496b-866b-fac5e6d38ca2@github.com>

On Thu, 12 Sep 2024 13:13:01 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>>> @rkennke Can you please explain the changes in these tests:
>>> 
>>> ```
>>> test/hotspot/jtreg/compiler/c2/irTests/TestVectorizationMismatchedAccess.java
>>> test/hotspot/jtreg/compiler/c2/irTests/TestVectorizationNotRun.java
>>> test/hotspot/jtreg/compiler/loopopts/superword/TestAlignVector.java
>>> test/hotspot/jtreg/compiler/loopopts/superword/TestIndependentPacksWithCyclicDependency.java
>>> test/hotspot/jtreg/compiler/loopopts/superword/TestMulAddS2I.java
>>> ```
>>> 
>>> You added these IR rule restriction: `@IR(applyIf = {"UseCompactObjectHeaders", "false"},`
>>> 
>>> This means that if `UseCompactObjectHeaders` is enabled, vectorization seems to be impacted - that could be concerning because it has a performance impact.
>>> 
>>> I have recently changed a few things in SuperWord, so maybe some of them can be removed, because they now vectorize anyway?
>>> 
>>> Of course some special tests may just rely on `UseCompactObjectHeaders == false` - but I would need some comments in the tests where you added it to justify why we add the restriction.
>>> 
>>> Please also test this patch with the cross combinations of `UseCompactObjectHeaders` and `AlignVector` enabled and disabled (and add `VerifyAlignVector` as well).
>> 
>> IIRC (it has been a while), the problem is that with Lilliput (and also without compact headers, but disabling compressed class-pointers -UseCompressedClassPointers, but nobody ever does that), byte[] and long[] start at different offsets (12 and 16, respectively). That is because with compact headers, we are using the 4 bytes after the arraylength, but long-arrays cannot do that because of alignment constraints. The impact is that these tests don't work as expected, because vectorization triggers differently. I don't remember the details, TBH, but I believe they would now generate pre-loops, or some might even not vectorize at all. Those seemed to be use-cases that did not look very important, but I may be wrong. It would be nice to properly fix those tests, or make corresponding tests for compact headers, instead, or improve vectorization to better deal with the offset mismatch, if necessary/possible.
>> 
>> I will re-evaluate those tests, and add comments or remove the restrictions.
>
>> > > @rkennke Can you please explain the changes in these tests:
>> > > ```
>> > > test/hotspot/jtreg/compiler/c2/irTests/TestVectorizationMismatchedAccess.java
>> > > test/hotspot/jtreg/compiler/c2/irTests/TestVectorizationNotRun.java
>> > > test/hotspot/jtreg/compiler/loopopts/superword/TestAlignVector.java
>> > > test/hotspot/jtreg/compiler/loopopts/superword/TestIndependentPacksWithCyclicDependency.java
>> > > test/hotspot/jtreg/compiler/loopopts/superword/TestMulAddS2I.java
>> > > ```
>> > > 
>> > > 
>> > >     
>> > >       
>> > >     
>> > > 
>> > >       
>> > >     
>> > > 
>> > >     
>> > >   
>> > > You added these IR rule restriction: `@IR(applyIf = {"UseCompactObjectHeaders", "false"},`
>> > > This means that if `UseCompactObjectHeaders` is enabled, vectorization seems to be impacted - that could be concerning because it has a performance impact.
>> > > I have recently changed a few things in SuperWord, so maybe some of them can be removed, because they now vectorize anyway?
>> > > Of course some special tests may just rely on `UseCompactObjectHeaders == false` - but I would need some comments in the tests where you added it to justify why we add the restriction.
>> > > Please also test this patch with the cross combinations of `UseCompactObjectHeaders` and `AlignVector` enabled and disabled (and add `VerifyAlignVector` as well).
>> > 
>> > 
>> > IIRC (it has been a while), the problem is that with Lilliput (and also without compact headers, but disabling compressed class-pointers -UseCompressedClassPointers, but nobody ever does that), byte[] and long[] start at different offsets (12 and 16, respectively). That is because with compact headers, we are using the 4 bytes after the arraylength, but long-arrays cannot do that because of alignment constraints. The impact is that these tests don't work as expected, because vectorization triggers differently. I don't remember the details, TBH, but I believe they would now generate pre-loops, or some might even not vectorize at all. Those seemed to be use-cases that did not look very important, but I may be wrong. It would be nice to properly fix those tests, or make corresponding tests for compact headers, instead, or improve vectorization to better deal with the offset mismatch, if necessary/possible.
>> > I will re-evaluate those tests, and add comments or remove the restrictions.
>> 
>> If it has indeed been a while, then it might well be that some of them work now, since I did make some improvements to auto-vectorization ...

> `LoadNKlass` nodes can then be expanded into more primitive operations (load and shift for compact headers, load with `klass_offset_in_bytes()` for original headers) within C2's back-end or even during code emission as sketched [here](https://github.com/robcasloz/jdk/commit/6cb4219f101e3be982264071c2cb1d0af1c6d754). @rkennke is this similar to what you tried out ("Expanding it as a macro")?

No, this is not what I tried. I tried to completely expand LoadNKlass, and replace it with the lower nodes that load and shift the mark-word right there, in ideal graph. But your approach is saner: there is so much implicit knowledge about Load(N)Klass, and even klass_offset_in_bytes(), all over the place, it would be very hard to get this right without breaking something.

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

PR Comment: https://git.openjdk.org/jdk/pull/20677#issuecomment-2352926265

From roland at openjdk.org  Mon Sep 16 14:07:07 2024
From: roland at openjdk.org (Roland Westrelin)
Date: Mon, 16 Sep 2024 14:07:07 GMT
Subject: RFR: 8340183: Shenandoah: Incorrect match for clone barrier in
 is_gc_barrier_node
In-Reply-To: <lMJ7zz1QZt3FMIqVLhEpYe6aqMc_uqU_d0P2mWQI4IY=.136a8eb3-b7ae-43f4-b268-5f7a6d189e09@github.com>
References: <lMJ7zz1QZt3FMIqVLhEpYe6aqMc_uqU_d0P2mWQI4IY=.136a8eb3-b7ae-43f4-b268-5f7a6d189e09@github.com>
Message-ID: <I7NhR4jVuklXowTs34Rv02cNZoZiDttwDz-7Cft1iNE=.2fa69349-9b82-474a-ba53-b400f5361bba@github.com>

On Mon, 16 Sep 2024 10:35:15 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> The name of the call we emit is "shenandoah_clone":
> https://github.com/openjdk/jdk/blob/545951889c1ea68646be600decaf2bf4c049600b/src/hotspot/share/gc/shenandoah/c2/shenandoahBarrierSetC2.cpp#L806
> 
> ...yet we test for "shenandoah_clone_barrier" here:
> https://github.com/openjdk/jdk/blob/545951889c1ea68646be600decaf2bf4c049600b/src/hotspot/share/gc/shenandoah/c2/shenandoahBarrierSetC2.cpp#L688
> 
> I think we are better off polling the call target instead of relying on call name. This change also eliminates `shenandoah_cas_obj` matcher, for which we do not have the emitted call ever since we started doing CAS expansions inline.
> 
> Additional testing:
>  - [x] Linux x86_64 server fastdebug, `hotspot_gc_shenandoah`
>  - [ ] Linux x86_64 server fastdebug, `all` with `-XX:+UseShenandoahGC`

Looks good to me.

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

Marked as reviewed by roland (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21014#pullrequestreview-2306783149

From kvn at openjdk.org  Mon Sep 16 16:11:04 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Mon, 16 Sep 2024 16:11:04 GMT
Subject: RFR: 8340186: Shenandoah: Missing
 load_reference_barrier_phantom_narrow match in is_shenandoah_lrb_call
In-Reply-To: <WKF6HOcWBzpASW2-szk8bk_hZ-DN6CGvX9vwkHPM0x0=.7fb65ec8-d648-4b60-ad73-f9c1e1c1b8ce@github.com>
References: <WKF6HOcWBzpASW2-szk8bk_hZ-DN6CGvX9vwkHPM0x0=.7fb65ec8-d648-4b60-ad73-f9c1e1c1b8ce@github.com>
Message-ID: <Eeb3ati5QBCdPFcglZ4XQ1KGCNJBXynYlw-BKGVmQwU=.db10e7de-56c6-41c0-930d-a15dac622c5e@github.com>

On Mon, 16 Sep 2024 10:38:12 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> [JDK-8256999](https://bugs.openjdk.org/browse/JDK-8256999) added `ShenandoahRuntime::load_reference_barrier_phantom_narrow`, but missed adding it to `ShenandoahBarrierSetC2::is_shenandoah_lrb_call`. It is currently innocuous, as there are no users of `is_shenandoah_lrb_call`, but it will be important when [JDK-8340183](https://bugs.openjdk.org/browse/JDK-8340183) lands.

Trivial ;)

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

Marked as reviewed by kvn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21016#pullrequestreview-2307108763

From aboldtch at openjdk.org  Mon Sep 16 16:21:20 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Mon, 16 Sep 2024 16:21:20 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v17]
In-Reply-To: <_5gI7i33xrOgXMTI_04oX9UDGwhVTtSNWoSiNfM3FOM=.b24979b3-dcde-401f-b2d8-9b201d303f57@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <_5gI7i33xrOgXMTI_04oX9UDGwhVTtSNWoSiNfM3FOM=.b24979b3-dcde-401f-b2d8-9b201d303f57@github.com>
Message-ID: <ofn5UzcoE5CTfZm-tNL_xw1htewyzz9VmVbEOSvplVg=.8f474dd6-b18c-464e-b944-3780281a6717@github.com>

On Mon, 16 Sep 2024 13:28:00 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> This is the main body of the JEP 450: Compact Object Headers (Experimental).
>> 
>> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing.
>> 
>> Main changes:
>>  - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers.
>>  - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded.
>>  - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops).
>>  - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all).
>>  - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16).
>>  - Arrays will now store their length at offset 8.
>>  - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _co...
>
> Roman Kennke has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 54 commits:
> 
>  - Merge remote-tracking branch 'origin/master' into JDK-8305895-v4
>  - Fix  test/hotspot/jtreg/runtime/CompressedOops/CompressedClassPointersEncodingScheme.java
>  - Fix loop on aarch64
>  - clarify obscure assert in metasapce setup
>  - Rework compressedklass encoding
>  - remove stray debug output
>  - Fixes post 8338526
>  - Merge commit '597788850041e7272a23714c05ba546ee6080856' into JDK-8305895-v4
>  - Various touch-ups
>  - Hide log timestamps in test to prevent false failures
>  - ... and 44 more: https://git.openjdk.org/jdk/compare/54595188...2125cd81

src/hotspot/cpu/aarch64/aarch64.ad line 6459:

> 6457:   format %{ "ldrw  $dst, $mem\t# compressed class ptr" %}
> 6458:   ins_encode %{
> 6459:     __ load_nklass_compact_c2($dst$$Register, $mem$$base$$Register, $mem$$index$$Register, $mem$$scale, $mem$$disp);

I wonder if something along the line of this is required here.
Suggestion:

    Address addr = mem2address($mem->opcode(), $mem$$base$$Register, $mem$$index, $mem$$scale, $mem$$disp);
    __ load_nklass_compact_c2($dst$$Register, __ adjust_compact_object_header_address_c2(addr, rscratch1));

With `adjust_compact_object_header_address_c2` being:
```C++
Address C2_MacroAssembler::adjust_compact_object_header_address_c2(Address addr, Register tmp) {
  // The incoming address is pointing into obj-start + klass_offset_in_bytes. We need to extract
  // obj-start, so that we can load from the object's mark-word instead. Usually the address
  // comes as obj-start in addr.base() and klass_offset_in_bytes in addr.offset().
  if (addr.getMode() != Address::base_plus_offset) {
    lea(tmp, addr);
    addr = Address(tmp, -oopDesc::klass_offset_in_bytes());
  } else {
    addr = Address(addr.base(), addr.offset() - oopDesc::klass_offset_in_bytes());
  }
  return legitimize_address(addr, 8, tmp);
}


Maybe it is the case that we never get the case where `$mem->opcode()` is not `lsl` variant, nor that the offset is to far away for an immediate fixed by `legitimize_address`. But it seems like this would at least make those cases correct, while avoiding the `lea` in the common case. 

Maybe someone with better experience in aarch64 macroassembler+ad files and C2 can give an opinion.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1761455581

From shade at openjdk.org  Mon Sep 16 16:25:08 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 16 Sep 2024 16:25:08 GMT
Subject: RFR: 8340186: Shenandoah: Missing
 load_reference_barrier_phantom_narrow match in is_shenandoah_lrb_call
In-Reply-To: <WKF6HOcWBzpASW2-szk8bk_hZ-DN6CGvX9vwkHPM0x0=.7fb65ec8-d648-4b60-ad73-f9c1e1c1b8ce@github.com>
References: <WKF6HOcWBzpASW2-szk8bk_hZ-DN6CGvX9vwkHPM0x0=.7fb65ec8-d648-4b60-ad73-f9c1e1c1b8ce@github.com>
Message-ID: <2JTmLP8qoq6b358-CVLMhT5fgLK3rB_dWqTdNtwYUXg=.6a991137-e68a-4bdc-b58c-3bfb66774e79@github.com>

On Mon, 16 Sep 2024 10:38:12 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> [JDK-8256999](https://bugs.openjdk.org/browse/JDK-8256999) added `ShenandoahRuntime::load_reference_barrier_phantom_narrow`, but missed adding it to `ShenandoahBarrierSetC2::is_shenandoah_lrb_call`. It is currently innocuous, as there are no users of `is_shenandoah_lrb_call`, but it will be important when [JDK-8340183](https://bugs.openjdk.org/browse/JDK-8340183) lands.

Yup :) Thanks!

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

PR Comment: https://git.openjdk.org/jdk/pull/21016#issuecomment-2353368636

From shade at openjdk.org  Mon Sep 16 16:25:09 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 16 Sep 2024 16:25:09 GMT
Subject: Integrated: 8340186: Shenandoah: Missing
 load_reference_barrier_phantom_narrow match in is_shenandoah_lrb_call
In-Reply-To: <WKF6HOcWBzpASW2-szk8bk_hZ-DN6CGvX9vwkHPM0x0=.7fb65ec8-d648-4b60-ad73-f9c1e1c1b8ce@github.com>
References: <WKF6HOcWBzpASW2-szk8bk_hZ-DN6CGvX9vwkHPM0x0=.7fb65ec8-d648-4b60-ad73-f9c1e1c1b8ce@github.com>
Message-ID: <vIaPR50C2wPm6-9tPKibr2sCaqIBMc76QHPLR8XzrO0=.3d685ecd-125a-4f41-b9a9-ba28e0ac0faf@github.com>

On Mon, 16 Sep 2024 10:38:12 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> [JDK-8256999](https://bugs.openjdk.org/browse/JDK-8256999) added `ShenandoahRuntime::load_reference_barrier_phantom_narrow`, but missed adding it to `ShenandoahBarrierSetC2::is_shenandoah_lrb_call`. It is currently innocuous, as there are no users of `is_shenandoah_lrb_call`, but it will be important when [JDK-8340183](https://bugs.openjdk.org/browse/JDK-8340183) lands.

This pull request has now been integrated.

Changeset: 1640bd26
Author:    Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1640bd2676d8d183f02b4f5386ce42c47950e356
Stats:     2 lines in 1 file changed: 1 ins; 0 del; 1 mod

8340186: Shenandoah: Missing load_reference_barrier_phantom_narrow match in is_shenandoah_lrb_call

Reviewed-by: kvn

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

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

From wkemper at openjdk.org  Mon Sep 16 16:26:31 2024
From: wkemper at openjdk.org (William Kemper)
Date: Mon, 16 Sep 2024 16:26:31 GMT
Subject: RFR: 8339611: GenShen: Simplify
 ShenandoahOldHeuristics::trigger_collection_if_fragmented [v2]
In-Reply-To: <29Vz5DMyRNeJ5GUCizzDZifamn5c_3qt80Jcvk-vQBc=.077aefe4-c868-4813-8aed-9ff6c90a8399@github.com>
References: <Wbfv5Hn_mjgJ9Fdy_iOu27bFHMWxjbHyWn_bZ9LbChA=.f20657e9-69e4-4c5d-89e8-f3485101a710@github.com>
 <29Vz5DMyRNeJ5GUCizzDZifamn5c_3qt80Jcvk-vQBc=.077aefe4-c868-4813-8aed-9ff6c90a8399@github.com>
Message-ID: <yXsuqzMA06c22C5carAJDtVfjCupow8payvmNSkn6RI=.5413d0a6-3cca-416f-91c6-2da720c2a647@github.com>

On Sun, 15 Sep 2024 02:43:47 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> This pull request contains a backport of commit c38b31af from the openjdk/shenandoah repository.
>> 
>> The commit being backported was authored by Kelvin Nilsen on 13 Sep 2024 and was reviewed by William Kemper.
>
> Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove dependency on checkedCast.hpp

Marked as reviewed by wkemper (Committer).

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

PR Review: https://git.openjdk.org/shenandoah-jdk21u/pull/89#pullrequestreview-2307140040

From wkemper at openjdk.org  Mon Sep 16 16:35:36 2024
From: wkemper at openjdk.org (William Kemper)
Date: Mon, 16 Sep 2024 16:35:36 GMT
Subject: Integrated: 8340137: GenShen: Reset mark bitmaps when a region is
 recycled
In-Reply-To: <Q8VdOP97kNcDMSmE_hHCkFzdX4B8iPxfoGg7tlzVXVI=.38ad995c-f4a3-4153-8061-f706a2aa4983@github.com>
References: <Q8VdOP97kNcDMSmE_hHCkFzdX4B8iPxfoGg7tlzVXVI=.38ad995c-f4a3-4153-8061-f706a2aa4983@github.com>
Message-ID: <0Yh6DrfSSmUgEfvs2pBg3m3VoPxUklecYOaof5h-jFg=.49f86c14-3338-48c0-875f-bbaa35758659@github.com>

On Fri, 13 Sep 2024 17:53:00 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Historically, the concurrent reset phase has reset bitmaps for _all_ committed regions. In the generational mode, however, we wish to reset bitmaps for only the generation being collected. This action was recently made to [exclude](https://bugs.openjdk.org/browse/JDK-8332082) [free](https://github.com/openjdk/shenandoah/pull/496/files#diff-21f0a6cd0f9698d813b88d4265dd2b8686a836966789d23de509cd1b9e936ae1R52) regions. This broke an assert for regions that became committed (active) after concurrent reset. To address this, we can reset bitmaps for a region when it is recycled (resets still happen for active regions during concurrent reset).
> 
> ## Testing
> GHA, internal pipelines

This pull request has now been integrated.

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

8340137: GenShen: Reset mark bitmaps when a region is recycled

Reviewed-by: kdnilsen, ysr

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

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

From wkemper at openjdk.org  Mon Sep 16 16:38:17 2024
From: wkemper at openjdk.org (William Kemper)
Date: Mon, 16 Sep 2024 16:38:17 GMT
Subject: RFR: 8338620: GenShen: Distinguish between young and old collector in
 GC configuration
Message-ID: <2Y72BC2jhq1jIr0NzMtmOrFAvF8yMCM0oG_NbXeFTQY=.79dae4f1-46e9-4727-9598-5bcc0c593bac@github.com>

Clean backport.

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

Commit messages:
 - Backport e31d1e49885f02ae25bd5758c8d4a2705f4b97e1

Changes: https://git.openjdk.org/shenandoah-jdk21u/pull/91/files
  Webrev: https://webrevs.openjdk.org/?repo=shenandoah-jdk21u&pr=91&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8338620
  Stats: 38 lines in 2 files changed: 24 ins; 14 del; 0 mod
  Patch: https://git.openjdk.org/shenandoah-jdk21u/pull/91.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah-jdk21u.git pull/91/head:pull/91

PR: https://git.openjdk.org/shenandoah-jdk21u/pull/91

From wkemper at openjdk.org  Mon Sep 16 16:41:28 2024
From: wkemper at openjdk.org (William Kemper)
Date: Mon, 16 Sep 2024 16:41:28 GMT
Subject: Integrated: 8338620: GenShen: Distinguish between young and old
 collector in GC configuration
In-Reply-To: <2Y72BC2jhq1jIr0NzMtmOrFAvF8yMCM0oG_NbXeFTQY=.79dae4f1-46e9-4727-9598-5bcc0c593bac@github.com>
References: <2Y72BC2jhq1jIr0NzMtmOrFAvF8yMCM0oG_NbXeFTQY=.79dae4f1-46e9-4727-9598-5bcc0c593bac@github.com>
Message-ID: <EFQec07FIv9ypL55vQKmXBo1sXy1KRhRG1VoYzC8UZU=.bdfa7084-b41c-4608-98ce-313d5982d82e@github.com>

On Mon, 16 Sep 2024 16:31:53 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Clean backport.

This pull request has now been integrated.

Changeset: a38c7c54
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.org/shenandoah-jdk21u/commit/a38c7c543912a1bec5da4b45e5bed5a8a7a1bd80
Stats:     38 lines in 2 files changed: 24 ins; 14 del; 0 mod

8338620: GenShen: Distinguish between young and old collector in GC configuration

Backport-of: e31d1e49885f02ae25bd5758c8d4a2705f4b97e1

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

PR: https://git.openjdk.org/shenandoah-jdk21u/pull/91

From wkemper at openjdk.org  Mon Sep 16 16:42:16 2024
From: wkemper at openjdk.org (William Kemper)
Date: Mon, 16 Sep 2024 16:42:16 GMT
Subject: RFR: Merge openjdk/jdk:master [v2]
In-Reply-To: <-xgHZQZ7LpFfBspEVezFI5Lru3TXDxH9M-AExzZPlOs=.17c3a1db-0347-40be-bc04-dba08e5e36b0@github.com>
References: <-xgHZQZ7LpFfBspEVezFI5Lru3TXDxH9M-AExzZPlOs=.17c3a1db-0347-40be-bc04-dba08e5e36b0@github.com>
Message-ID: <wgA3XsdUEMd4j9r1G_SPo4Bd92Vr12GcRy-lmOPYlfs=.c70fda09-fedb-471b-b602-4bd9b2047c65@github.com>

> Merges tag jdk-24+15
> 
> ## Notes:
> * CDS support is disabled for generational mode, pending: https://bugs.openjdk.org/browse/JDK-8339182
> * make_regular_bypass has been modified to maintain humongous waste accounting
> 
> ## Testing
> GHA, internal pipelines

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

 - Merge branch 'shenandoah-master' into merge-jdk-24+N
 - Clear bitmaps when region is recycled
 - Merge remote-tracking branch 'shenandoah/master' into merge-jdk-24+N
 - Merge tag 'jdk-24+15' into merge-jdk-24+N
   
   Added tag jdk-24+15 for changeset 3c40afa5
 - 8334165: Remove serialVersionUID compatibility logic from JMX
   
   Reviewed-by: dfuchs
 - 8339733: C2: some nodes can have incorrect control after do_range_check()
   
   Reviewed-by: chagedorn, thartmann
 - 8339731: java.desktop/share/classes/javax/swing/text/html/default.css typo in margin settings
   
   Reviewed-by: prr
 - 8339159: api/java_rmi/Naming/Rebind.html crashes with SEGV from UTF8::quoted_ascii_length call
   
   Reviewed-by: iklam, aboldtch
 - 8339835: Replace usages of -mx and -ms in some client-libs tests
   
   Reviewed-by: azvegint, prr
 - 8339834: Replace usages of -mx and -ms in some tests
   
   Reviewed-by: aivanov, ascarpino, prr, dholmes
 - ... and 302 more: https://git.openjdk.org/shenandoah/compare/a8e2908e...62b8b5ae

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

Changes: https://git.openjdk.org/shenandoah/pull/498/files
  Webrev: https://webrevs.openjdk.org/?repo=shenandoah&pr=498&range=01
  Stats: 44821 lines in 1351 files changed: 27370 ins; 10467 del; 6984 mod
  Patch: https://git.openjdk.org/shenandoah/pull/498.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah.git pull/498/head:pull/498

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

From wkemper at openjdk.org  Mon Sep 16 16:47:47 2024
From: wkemper at openjdk.org (William Kemper)
Date: Mon, 16 Sep 2024 16:47:47 GMT
Subject: Integrated: 8338717: GenShen: Fix up some assertions
Message-ID: <201O9V25qwULF_96LvtvXqDRKnXCmSoPtZoYc9CNesg=.f223a523-8b3d-41ae-8ace-62cbb259c8f5@github.com>

Clean.

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

Commit messages:
 - Backport d7e22354f30a1260fc55006cafe8fd80bdad9e04

Changes: https://git.openjdk.org/shenandoah-jdk21u/pull/92/files
  Webrev: https://webrevs.openjdk.org/?repo=shenandoah-jdk21u&pr=92&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8338717
  Stats: 74 lines in 9 files changed: 49 ins; 8 del; 17 mod
  Patch: https://git.openjdk.org/shenandoah-jdk21u/pull/92.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah-jdk21u.git pull/92/head:pull/92

PR: https://git.openjdk.org/shenandoah-jdk21u/pull/92

From wkemper at openjdk.org  Mon Sep 16 16:47:48 2024
From: wkemper at openjdk.org (William Kemper)
Date: Mon, 16 Sep 2024 16:47:48 GMT
Subject: Integrated: 8338717: GenShen: Fix up some assertions
In-Reply-To: <201O9V25qwULF_96LvtvXqDRKnXCmSoPtZoYc9CNesg=.f223a523-8b3d-41ae-8ace-62cbb259c8f5@github.com>
References: <201O9V25qwULF_96LvtvXqDRKnXCmSoPtZoYc9CNesg=.f223a523-8b3d-41ae-8ace-62cbb259c8f5@github.com>
Message-ID: <j9_b-TkUZWrHdgja-8Z4GiXmkPUr9qecuZCLgswRj0o=.46639dbe-fb68-45f9-ae81-6ac1d826ea63@github.com>

On Mon, 16 Sep 2024 16:40:53 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Clean.

This pull request has now been integrated.

Changeset: fe42b404
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.org/shenandoah-jdk21u/commit/fe42b404734fdd215ee9960ab21890ac6c4cc56d
Stats:     74 lines in 9 files changed: 49 ins; 8 del; 17 mod

8338717: GenShen: Fix up some assertions

Backport-of: d7e22354f30a1260fc55006cafe8fd80bdad9e04

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

PR: https://git.openjdk.org/shenandoah-jdk21u/pull/92

From wkemper at openjdk.org  Mon Sep 16 17:02:48 2024
From: wkemper at openjdk.org (William Kemper)
Date: Mon, 16 Sep 2024 17:02:48 GMT
Subject: Integrated: Merge openjdk/jdk:master
In-Reply-To: <-xgHZQZ7LpFfBspEVezFI5Lru3TXDxH9M-AExzZPlOs=.17c3a1db-0347-40be-bc04-dba08e5e36b0@github.com>
References: <-xgHZQZ7LpFfBspEVezFI5Lru3TXDxH9M-AExzZPlOs=.17c3a1db-0347-40be-bc04-dba08e5e36b0@github.com>
Message-ID: <NM9eI_CyvBb8OcvqPfNEUGRV54dATKiUTthJUQWzJX0=.e5aaf69e-421d-479d-bf46-9061e0371ad1@github.com>

On Thu, 12 Sep 2024 20:22:00 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Merges tag jdk-24+15
> 
> ## Notes:
> * CDS support is disabled for generational mode, pending: https://bugs.openjdk.org/browse/JDK-8339182
> * make_regular_bypass has been modified to maintain humongous waste accounting
> 
> ## Testing
> GHA, internal pipelines

This pull request has now been integrated.

Changeset: b561293c
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.org/shenandoah/commit/b561293c0ca9eb20b8ff3378cc8521e0a7eec853
Stats:     44821 lines in 1351 files changed: 27370 ins; 10467 del; 6984 mod

Merge

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

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

From wkemper at openjdk.org  Mon Sep 16 17:03:34 2024
From: wkemper at openjdk.org (William Kemper)
Date: Mon, 16 Sep 2024 17:03:34 GMT
Subject: RFR: Merge openjdk/jdk:master [v2]
In-Reply-To: <zppzsQWzZhGwpTxGg1sKzUqbumITN6uvkJtsjrEnW00=.ede73fe9-c3e7-474b-aa83-305561c1585e@github.com>
References: <zppzsQWzZhGwpTxGg1sKzUqbumITN6uvkJtsjrEnW00=.ede73fe9-c3e7-474b-aa83-305561c1585e@github.com>
Message-ID: <mIu939owrpY-M-bMXeQ0oy9pzTJK9_aFFVXoiG54ADQ=.5f98478d-41ce-41c9-a9e8-ae78c5c41edf@github.com>

> Merges tag jdk-24+15

William Kemper has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase.

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

Changes:
  - all: https://git.openjdk.org/shenandoah/pull/499/files
  - new: https://git.openjdk.org/shenandoah/pull/499/files/3c40afa5..3c40afa5

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

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

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

From wkemper at openjdk.org  Mon Sep 16 17:03:35 2024
From: wkemper at openjdk.org (William Kemper)
Date: Mon, 16 Sep 2024 17:03:35 GMT
Subject: RFR: Merge openjdk/jdk:master
In-Reply-To: <zppzsQWzZhGwpTxGg1sKzUqbumITN6uvkJtsjrEnW00=.ede73fe9-c3e7-474b-aa83-305561c1585e@github.com>
References: <zppzsQWzZhGwpTxGg1sKzUqbumITN6uvkJtsjrEnW00=.ede73fe9-c3e7-474b-aa83-305561c1585e@github.com>
Message-ID: <Zp6BYr8emKtkbDJcD6hMpF1kOSGyRVId27qdj2v8kF4=.8e54be25-44ff-4e35-982d-ade07ed1535a@github.com>

On Fri, 13 Sep 2024 14:11:21 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Merges tag jdk-24+15

Superseded by https://github.com/openjdk/shenandoah/pull/498

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

PR Comment: https://git.openjdk.org/shenandoah/pull/499#issuecomment-2353449122

From wkemper at openjdk.org  Mon Sep 16 17:03:35 2024
From: wkemper at openjdk.org (William Kemper)
Date: Mon, 16 Sep 2024 17:03:35 GMT
Subject: Withdrawn: Merge openjdk/jdk:master
In-Reply-To: <zppzsQWzZhGwpTxGg1sKzUqbumITN6uvkJtsjrEnW00=.ede73fe9-c3e7-474b-aa83-305561c1585e@github.com>
References: <zppzsQWzZhGwpTxGg1sKzUqbumITN6uvkJtsjrEnW00=.ede73fe9-c3e7-474b-aa83-305561c1585e@github.com>
Message-ID: <BxHPwbtgaCAAh7uhHlvYHvBHKr5vJzeZu8Z753hR1mc=.749069b9-3936-43ce-9ead-fc6b8e1f21d6@github.com>

On Fri, 13 Sep 2024 14:11:21 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Merges tag jdk-24+15

This pull request has been closed without being integrated.

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

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

From kdnilsen at openjdk.org  Mon Sep 16 17:21:28 2024
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Mon, 16 Sep 2024 17:21:28 GMT
Subject: Integrated: 8339611: GenShen: Simplify
 ShenandoahOldHeuristics::trigger_collection_if_fragmented
In-Reply-To: <Wbfv5Hn_mjgJ9Fdy_iOu27bFHMWxjbHyWn_bZ9LbChA=.f20657e9-69e4-4c5d-89e8-f3485101a710@github.com>
References: <Wbfv5Hn_mjgJ9Fdy_iOu27bFHMWxjbHyWn_bZ9LbChA=.f20657e9-69e4-4c5d-89e8-f3485101a710@github.com>
Message-ID: <voRdXBeR_VxaIIMUP7DZ5VPAn_tdwuWner25eAhMNbM=.bd24c864-d5b9-4e12-bb33-2c8ed44b9933@github.com>

On Sat, 14 Sep 2024 00:02:56 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

> This pull request contains a backport of commit c38b31af from the openjdk/shenandoah repository.
> 
> The commit being backported was authored by Kelvin Nilsen on 13 Sep 2024 and was reviewed by William Kemper.

This pull request has now been integrated.

Changeset: c0b27b2a
Author:    Kelvin Nilsen <kdnilsen at openjdk.org>
URL:       https://git.openjdk.org/shenandoah-jdk21u/commit/c0b27b2a2326c93ce15d0b688c559ed804057b3a
Stats:     73 lines in 4 files changed: 25 ins; 16 del; 32 mod

8339611: GenShen: Simplify ShenandoahOldHeuristics::trigger_collection_if_fragmented

Reviewed-by: shade, wkemper
Backport-of: c38b31afe8ff4fdcdd27a771e72d38b128273f01

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

PR: https://git.openjdk.org/shenandoah-jdk21u/pull/89

From kdnilsen at openjdk.org  Mon Sep 16 17:39:31 2024
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Mon, 16 Sep 2024 17:39:31 GMT
Subject: Integrated: 8339197: GenShen: Adding Generation and Evacuation
 Information JFR Logging
In-Reply-To: <opdPiC2deogh0GwB9hj9t8BQ5H0nfKoFX19NvpAP61k=.af1900d6-fedb-4448-a662-a7445949ca16@github.com>
References: <opdPiC2deogh0GwB9hj9t8BQ5H0nfKoFX19NvpAP61k=.af1900d6-fedb-4448-a662-a7445949ca16@github.com>
Message-ID: <pnUik0BYgR2at5X8-VxpqWVi0vcyFfZongJ6eukaAAw=.9d1d432d-a4d6-46af-a5ca-70adba9e8b88@github.com>

On Fri, 13 Sep 2024 19:34:00 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

> This pull request contains a backport of commit 662d146d from the openjdk/shenandoah repository.
> 
> The commit being backported was authored by Satyen Subramaniam on 4 Sep 2024 and was reviewed by Kelvin Nilsen,
> William Kemper and Y. Srinivas Ramakrishna.

This pull request has now been integrated.

Changeset: ef760228
Author:    Kelvin Nilsen <kdnilsen at openjdk.org>
URL:       https://git.openjdk.org/shenandoah-jdk21u/commit/ef7602284b54dfd7b63eb71dc76c2fb7c6bc800a
Stats:     323 lines in 10 files changed: 312 ins; 5 del; 6 mod

8339197: GenShen: Adding Generation and Evacuation Information JFR Logging

Backport-of: 662d146d52dd77d13cfe705a4a4959c5fb2fb5a1

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

PR: https://git.openjdk.org/shenandoah-jdk21u/pull/81

From rkennke at openjdk.org  Mon Sep 16 17:53:09 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Mon, 16 Sep 2024 17:53:09 GMT
Subject: RFR: 8339960: GenShen: Fix inconsistencies in generational
 Shenandoah behavior
In-Reply-To: <vzXjdQg2wTPzgTG1aU7_CUnAxtnlt_2o01drZXtI324=.100816d9-1ed5-497c-be51-fd540f496cb7@github.com>
References: <vzXjdQg2wTPzgTG1aU7_CUnAxtnlt_2o01drZXtI324=.100816d9-1ed5-497c-be51-fd540f496cb7@github.com>
Message-ID: <82yjeweCEIPcfscwWESC3M8c_UTgXKOAROiVXAKF09k=.4273df48-3931-4836-8da7-c25d8fd5a29b@github.com>

On Thu, 12 Sep 2024 20:23:36 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

> This fixes some bugs found in recent code review and playback of an assertion failure.
> 
> See also https://github.com/openjdk/shenandoah/pull/497

Looks good, thanks!

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

Marked as reviewed by rkennke (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20974#pullrequestreview-2307337108

From duke at openjdk.org  Mon Sep 16 18:09:22 2024
From: duke at openjdk.org (duke)
Date: Mon, 16 Sep 2024 18:09:22 GMT
Subject: RFR: 8339960: GenShen: Fix inconsistencies in generational
 Shenandoah behavior
In-Reply-To: <vzXjdQg2wTPzgTG1aU7_CUnAxtnlt_2o01drZXtI324=.100816d9-1ed5-497c-be51-fd540f496cb7@github.com>
References: <vzXjdQg2wTPzgTG1aU7_CUnAxtnlt_2o01drZXtI324=.100816d9-1ed5-497c-be51-fd540f496cb7@github.com>
Message-ID: <e5qWqDwU24IurRMAe6iqSOrVnZUMFtOrwabMG4krC84=.5b71c284-d4f6-460f-84f4-3d39e53ace31@github.com>

On Thu, 12 Sep 2024 20:23:36 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

> This fixes some bugs found in recent code review and playback of an assertion failure.
> 
> See also https://github.com/openjdk/shenandoah/pull/497

@kdnilsen 
Your change (at version f1ba63f4d58161512ad0262783ceda0916aece3c) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/20974#issuecomment-2353576294

From wkemper at openjdk.org  Mon Sep 16 18:19:36 2024
From: wkemper at openjdk.org (William Kemper)
Date: Mon, 16 Sep 2024 18:19:36 GMT
Subject: RFR: 8338695: GenShen: Clean up jtreg tests
Message-ID: <HGLcfYJAQw4jrjWhnqUMVPWO13ovoP-aJZ4fpmoULYg=.3b5bbd34-b10a-4e47-be60-d69979e03466@github.com>

Inexplicable merge conflict in SupplementaryLocaleDataProvider.java. Took what was already in the 21 repo, we've never touched that file.

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

Commit messages:
 - Fix trailing whitespace
 - Merge remote-tracking branch 'shenandoah-jdk21u/master' into backport-49994b3f
 - 8338695: GenShen: Clean up jtreg tests

Changes: https://git.openjdk.org/shenandoah-jdk21u/pull/93/files
  Webrev: https://webrevs.openjdk.org/?repo=shenandoah-jdk21u&pr=93&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8338695
  Stats: 496 lines in 16 files changed: 128 ins; 196 del; 172 mod
  Patch: https://git.openjdk.org/shenandoah-jdk21u/pull/93.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah-jdk21u.git pull/93/head:pull/93

PR: https://git.openjdk.org/shenandoah-jdk21u/pull/93

From kdnilsen at openjdk.org  Mon Sep 16 18:19:36 2024
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Mon, 16 Sep 2024 18:19:36 GMT
Subject: RFR: 8338695: GenShen: Clean up jtreg tests
In-Reply-To: <HGLcfYJAQw4jrjWhnqUMVPWO13ovoP-aJZ4fpmoULYg=.3b5bbd34-b10a-4e47-be60-d69979e03466@github.com>
References: <HGLcfYJAQw4jrjWhnqUMVPWO13ovoP-aJZ4fpmoULYg=.3b5bbd34-b10a-4e47-be60-d69979e03466@github.com>
Message-ID: <UIYEnOeZgBgHq0r_Rz8cuFRgeRMREJCPWcGw9SUXxOE=.9bd3ef78-7be4-4ac9-a59a-a3a9afe61440@github.com>

On Mon, 16 Sep 2024 18:09:23 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Inexplicable merge conflict in SupplementaryLocaleDataProvider.java. Took what was already in the 21 repo, we've never touched that file.

Marked as reviewed by kdnilsen (Committer).

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

PR Review: https://git.openjdk.org/shenandoah-jdk21u/pull/93#pullrequestreview-2307394294

From wkemper at openjdk.org  Mon Sep 16 18:23:43 2024
From: wkemper at openjdk.org (William Kemper)
Date: Mon, 16 Sep 2024 18:23:43 GMT
Subject: Integrated: 8338695: GenShen: Clean up jtreg tests
In-Reply-To: <HGLcfYJAQw4jrjWhnqUMVPWO13ovoP-aJZ4fpmoULYg=.3b5bbd34-b10a-4e47-be60-d69979e03466@github.com>
References: <HGLcfYJAQw4jrjWhnqUMVPWO13ovoP-aJZ4fpmoULYg=.3b5bbd34-b10a-4e47-be60-d69979e03466@github.com>
Message-ID: <u-Xqbq0TN9IhsCx0nbO5weuS3VJ9kmkeITna_X8R-zg=.ee4b7b2c-92bc-44e9-a2a6-11e4232a56a2@github.com>

On Mon, 16 Sep 2024 18:09:23 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Inexplicable merge conflict in SupplementaryLocaleDataProvider.java. Took what was already in the 21 repo, we've never touched that file.

This pull request has now been integrated.

Changeset: 1da4c792
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.org/shenandoah-jdk21u/commit/1da4c7920ef82aa0840d109bbad06d34f39780a4
Stats:     496 lines in 16 files changed: 128 ins; 196 del; 172 mod

8338695: GenShen: Clean up jtreg tests

Reviewed-by: kdnilsen
Backport-of: 49994b3f2e84063eeec9ab493af7ba9d0c165e79

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

PR: https://git.openjdk.org/shenandoah-jdk21u/pull/93

From wkemper at openjdk.org  Mon Sep 16 18:30:02 2024
From: wkemper at openjdk.org (William Kemper)
Date: Mon, 16 Sep 2024 18:30:02 GMT
Subject: RFR: 8338779: GenShen: Prefer log_develop_debug in performance
 critical code
Message-ID: <22wobe4q4bHRnoDuJeYXa8ML4QbelTP4KE5RIxmzAcI=.057bf8fd-4ac1-4113-be4a-787dc9e00e7f@github.com>

Clean backport

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

Commit messages:
 - Backport d2ed6519cace41354bbcd073b46a00c9055f6060

Changes: https://git.openjdk.org/shenandoah-jdk21u/pull/94/files
  Webrev: https://webrevs.openjdk.org/?repo=shenandoah-jdk21u&pr=94&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8338779
  Stats: 5 lines in 2 files changed: 0 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/shenandoah-jdk21u/pull/94.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah-jdk21u.git pull/94/head:pull/94

PR: https://git.openjdk.org/shenandoah-jdk21u/pull/94

From wkemper at openjdk.org  Mon Sep 16 18:35:31 2024
From: wkemper at openjdk.org (William Kemper)
Date: Mon, 16 Sep 2024 18:35:31 GMT
Subject: Integrated: 8338779: GenShen: Prefer log_develop_debug in performance
 critical code
In-Reply-To: <22wobe4q4bHRnoDuJeYXa8ML4QbelTP4KE5RIxmzAcI=.057bf8fd-4ac1-4113-be4a-787dc9e00e7f@github.com>
References: <22wobe4q4bHRnoDuJeYXa8ML4QbelTP4KE5RIxmzAcI=.057bf8fd-4ac1-4113-be4a-787dc9e00e7f@github.com>
Message-ID: <V4xWyazaLTMUaRiNDjc9ekdbW9DXudDZgvnlutqrZyI=.ede889e0-53d3-48f9-857e-d00dd991aa19@github.com>

On Mon, 16 Sep 2024 18:22:28 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Clean backport

This pull request has now been integrated.

Changeset: 2a1b7315
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.org/shenandoah-jdk21u/commit/2a1b73156d1ce9c546c16dc44505d216c4c84596
Stats:     5 lines in 2 files changed: 0 ins; 0 del; 5 mod

8338779: GenShen: Prefer log_develop_debug in performance critical code

Backport-of: d2ed6519cace41354bbcd073b46a00c9055f6060

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

PR: https://git.openjdk.org/shenandoah-jdk21u/pull/94

From wkemper at openjdk.org  Mon Sep 16 18:51:39 2024
From: wkemper at openjdk.org (William Kemper)
Date: Mon, 16 Sep 2024 18:51:39 GMT
Subject: Integrated: 8338780: GenShen: Fix up some comments
In-Reply-To: <CjfA57ghwfmoLpcRF9DoR5fbdekm53oen_aSNlKn21Y=.9ec60124-fbe0-4709-be3b-06d0929b7960@github.com>
References: <CjfA57ghwfmoLpcRF9DoR5fbdekm53oen_aSNlKn21Y=.9ec60124-fbe0-4709-be3b-06d0929b7960@github.com>
Message-ID: <fo2B7S9kQtrxVC6w4ml86XIXTEfUiN4jgWH0yLddubE=.1d4e8897-1034-4018-9c3c-dd3da84f4e92@github.com>

On Mon, 16 Sep 2024 18:45:47 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Clean.

This pull request has now been integrated.

Changeset: 75f8e490
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.org/shenandoah-jdk21u/commit/75f8e4902ff30508b3fa348123d863ef73bffa9d
Stats:     114 lines in 4 files changed: 34 ins; 72 del; 8 mod

8338780: GenShen: Fix up some comments

Backport-of: 977200a0c073e90754f56730477d0fa32fd7ec9a

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

PR: https://git.openjdk.org/shenandoah-jdk21u/pull/95

From wkemper at openjdk.org  Mon Sep 16 18:51:39 2024
From: wkemper at openjdk.org (William Kemper)
Date: Mon, 16 Sep 2024 18:51:39 GMT
Subject: Integrated: 8338780: GenShen: Fix up some comments
Message-ID: <CjfA57ghwfmoLpcRF9DoR5fbdekm53oen_aSNlKn21Y=.9ec60124-fbe0-4709-be3b-06d0929b7960@github.com>

Clean.

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

Commit messages:
 - Backport 977200a0c073e90754f56730477d0fa32fd7ec9a

Changes: https://git.openjdk.org/shenandoah-jdk21u/pull/95/files
  Webrev: https://webrevs.openjdk.org/?repo=shenandoah-jdk21u&pr=95&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8338780
  Stats: 114 lines in 4 files changed: 34 ins; 72 del; 8 mod
  Patch: https://git.openjdk.org/shenandoah-jdk21u/pull/95.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah-jdk21u.git pull/95/head:pull/95

PR: https://git.openjdk.org/shenandoah-jdk21u/pull/95

From wkemper at openjdk.org  Mon Sep 16 19:13:34 2024
From: wkemper at openjdk.org (William Kemper)
Date: Mon, 16 Sep 2024 19:13:34 GMT
Subject: Integrated: 8338763: GenShen: Global GC should not swap remembered
 sets for the verifier
Message-ID: <3uXrkz3I--f7OUg6Z5-QXCyypgxjKsluQoQ58sXSWVk=.3d38e9c0-62a2-4ef5-bcdc-482b1d206193@github.com>

Clean

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

Commit messages:
 - Backport fc1acee6474022d6e9d3c7c2ba2f94f9a5ec5ff0

Changes: https://git.openjdk.org/shenandoah-jdk21u/pull/96/files
  Webrev: https://webrevs.openjdk.org/?repo=shenandoah-jdk21u&pr=96&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8338763
  Stats: 9 lines in 2 files changed: 0 ins; 5 del; 4 mod
  Patch: https://git.openjdk.org/shenandoah-jdk21u/pull/96.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah-jdk21u.git pull/96/head:pull/96

PR: https://git.openjdk.org/shenandoah-jdk21u/pull/96

From wkemper at openjdk.org  Mon Sep 16 19:13:34 2024
From: wkemper at openjdk.org (William Kemper)
Date: Mon, 16 Sep 2024 19:13:34 GMT
Subject: Integrated: 8338763: GenShen: Global GC should not swap remembered
 sets for the verifier
In-Reply-To: <3uXrkz3I--f7OUg6Z5-QXCyypgxjKsluQoQ58sXSWVk=.3d38e9c0-62a2-4ef5-bcdc-482b1d206193@github.com>
References: <3uXrkz3I--f7OUg6Z5-QXCyypgxjKsluQoQ58sXSWVk=.3d38e9c0-62a2-4ef5-bcdc-482b1d206193@github.com>
Message-ID: <tm5hsdAGbx5qAuxXULhMM8h3084u2x_nvLFvOtw09QU=.d358abd1-0dae-414b-9f15-089b7f5b3434@github.com>

On Mon, 16 Sep 2024 19:05:58 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Clean

This pull request has now been integrated.

Changeset: d86dccb7
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.org/shenandoah-jdk21u/commit/d86dccb702243ea5a78b2b82b9f01afe31db5712
Stats:     9 lines in 2 files changed: 0 ins; 5 del; 4 mod

8338763: GenShen: Global GC should not swap remembered sets for the verifier

Backport-of: fc1acee6474022d6e9d3c7c2ba2f94f9a5ec5ff0

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

PR: https://git.openjdk.org/shenandoah-jdk21u/pull/96

From kdnilsen at openjdk.org  Mon Sep 16 19:18:11 2024
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Mon, 16 Sep 2024 19:18:11 GMT
Subject: Integrated: 8339960: GenShen: Fix inconsistencies in generational
 Shenandoah behavior
In-Reply-To: <vzXjdQg2wTPzgTG1aU7_CUnAxtnlt_2o01drZXtI324=.100816d9-1ed5-497c-be51-fd540f496cb7@github.com>
References: <vzXjdQg2wTPzgTG1aU7_CUnAxtnlt_2o01drZXtI324=.100816d9-1ed5-497c-be51-fd540f496cb7@github.com>
Message-ID: <6MxEO3TVWiI4HzK-mHqwb32Yq8tRq6Gg6PbxePp8Hl8=.ced31c43-4ff8-45af-9293-819a6cc9ab73@github.com>

On Thu, 12 Sep 2024 20:23:36 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

> This fixes some bugs found in recent code review and playback of an assertion failure.
> 
> See also https://github.com/openjdk/shenandoah/pull/497

This pull request has now been integrated.

Changeset: 858b4f12
Author:    Kelvin Nilsen <kdnilsen at openjdk.org>
Committer: Y. Srinivas Ramakrishna <ysr at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/858b4f127ad873666f51f4c54c37fa2d7801c32c
Stats:     4 lines in 1 file changed: 2 ins; 0 del; 2 mod

8339960: GenShen: Fix inconsistencies in generational Shenandoah behavior

Reviewed-by: wkemper, rkennke

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

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

From wkemper at openjdk.org  Mon Sep 16 20:00:41 2024
From: wkemper at openjdk.org (William Kemper)
Date: Mon, 16 Sep 2024 20:00:41 GMT
Subject: RFR: 8338881: GenShen: Use explicit third temp register for post
 barrier
Message-ID: <qm1eCFKdxOf4rfTK8QNdWmemWSG7-TaT2u9OpGmo7Ao=.7c8b827c-27ed-49b0-9f4f-213829356c65@github.com>

Conflict with IU barrier support in 21.

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

Commit messages:
 - Backport 12af9f629ab2f3d29392eb8e6ab2abd518723480

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

PR: https://git.openjdk.org/shenandoah-jdk21u/pull/97

From kdnilsen at openjdk.org  Mon Sep 16 20:43:18 2024
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Mon, 16 Sep 2024 20:43:18 GMT
Subject: RFR: 8338881: GenShen: Use explicit third temp register for post
 barrier
In-Reply-To: <qm1eCFKdxOf4rfTK8QNdWmemWSG7-TaT2u9OpGmo7Ao=.7c8b827c-27ed-49b0-9f4f-213829356c65@github.com>
References: <qm1eCFKdxOf4rfTK8QNdWmemWSG7-TaT2u9OpGmo7Ao=.7c8b827c-27ed-49b0-9f4f-213829356c65@github.com>
Message-ID: <M0W7cbAB3gYrW6el0wPo78Ei6XmVxDDYNEsI5yzk6DU=.36e68a4c-0fd5-4e9d-b95c-b9e305c9f57b@github.com>

On Mon, 16 Sep 2024 19:54:58 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Conflict with IU barrier support in 21.

Marked as reviewed by kdnilsen (Committer).

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

PR Review: https://git.openjdk.org/shenandoah-jdk21u/pull/97#pullrequestreview-2307810452

From wkemper at openjdk.org  Mon Sep 16 20:52:26 2024
From: wkemper at openjdk.org (William Kemper)
Date: Mon, 16 Sep 2024 20:52:26 GMT
Subject: Integrated: 8338881: GenShen: Use explicit third temp register for
 post barrier
In-Reply-To: <qm1eCFKdxOf4rfTK8QNdWmemWSG7-TaT2u9OpGmo7Ao=.7c8b827c-27ed-49b0-9f4f-213829356c65@github.com>
References: <qm1eCFKdxOf4rfTK8QNdWmemWSG7-TaT2u9OpGmo7Ao=.7c8b827c-27ed-49b0-9f4f-213829356c65@github.com>
Message-ID: <8B2hxsbK-vQJrLXLQEyR6fr8XjgNNQ_p0FYbURDnOFw=.726e5649-f0a6-44c5-8f08-72f9d2312dd3@github.com>

On Mon, 16 Sep 2024 19:54:58 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Conflict with IU barrier support in 21.

This pull request has now been integrated.

Changeset: 324b9129
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.org/shenandoah-jdk21u/commit/324b912979ebda01f20c67f23c8bc0d7517772cd
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8338881: GenShen: Use explicit third temp register for post barrier

Reviewed-by: kdnilsen
Backport-of: 12af9f629ab2f3d29392eb8e6ab2abd518723480

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

PR: https://git.openjdk.org/shenandoah-jdk21u/pull/97

From wkemper at openjdk.org  Mon Sep 16 21:24:54 2024
From: wkemper at openjdk.org (William Kemper)
Date: Mon, 16 Sep 2024 21:24:54 GMT
Subject: RFR: 8339094: Shenandoah: Fix up test output from
 ShenandoahNumberSeqTest
Message-ID: <PPuBkQTXQfrM9KbMVeriJMXXcuaKw9_jBXtporq8D4k=.d9463e72-de12-47e9-b15f-92cd285865f7@github.com>

Clean

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

Commit messages:
 - Backport f8273594124a2b17fe855b8eb10458e0b9291bd6

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

PR: https://git.openjdk.org/shenandoah-jdk21u/pull/98

From wkemper at openjdk.org  Mon Sep 16 21:30:19 2024
From: wkemper at openjdk.org (William Kemper)
Date: Mon, 16 Sep 2024 21:30:19 GMT
Subject: Integrated: 8339094: Shenandoah: Fix up test output from
 ShenandoahNumberSeqTest
In-Reply-To: <PPuBkQTXQfrM9KbMVeriJMXXcuaKw9_jBXtporq8D4k=.d9463e72-de12-47e9-b15f-92cd285865f7@github.com>
References: <PPuBkQTXQfrM9KbMVeriJMXXcuaKw9_jBXtporq8D4k=.d9463e72-de12-47e9-b15f-92cd285865f7@github.com>
Message-ID: <OGOcdDVbWYhPB6rPkIdWUg0Bb_kFUK7wpAE44A1qQqg=.b80cb7e8-1cb5-4d49-88cc-acbeefa69706@github.com>

On Mon, 16 Sep 2024 21:20:07 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Clean

This pull request has now been integrated.

Changeset: 8144d245
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.org/shenandoah-jdk21u/commit/8144d24509fc296a68896d3940edbc7fc8316c8e
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8339094: Shenandoah: Fix up test output from ShenandoahNumberSeqTest

Shenandoah: Fix up test output from ShenandoahNumberSeqTest

Trivial change: added percentile labels on distribution; slightly adjusted format for readability.

**Testing:**
- [ ] make test TEST="gtest:BasicShenandoahNumberSeqTest gtest:ShenandoahNumberSeqMergeTest" w/fastdebug & release

Backport-of: f8273594124a2b17fe855b8eb10458e0b9291bd6

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

PR: https://git.openjdk.org/shenandoah-jdk21u/pull/98

From wkemper at openjdk.org  Mon Sep 16 21:37:49 2024
From: wkemper at openjdk.org (William Kemper)
Date: Mon, 16 Sep 2024 21:37:49 GMT
Subject: RFR: 8339127: GenShen: Restore completed mark context assertion during
 class unloading
Message-ID: <DHzxlZB3cCfLa4ouZ-3I4QskcuFSKTtBIsPyi0x6vrQ=.02214e75-5219-4c6b-bdf2-5d16b4fd7342@github.com>

Clean

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

Commit messages:
 - Backport c7cfc7fa32fbe90bed39456288c03d74aa2432b9

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

PR: https://git.openjdk.org/shenandoah-jdk21u/pull/99

From wkemper at openjdk.org  Mon Sep 16 21:45:26 2024
From: wkemper at openjdk.org (William Kemper)
Date: Mon, 16 Sep 2024 21:45:26 GMT
Subject: Integrated: 8339127: GenShen: Restore completed mark context assertion
 during class unloading
In-Reply-To: <DHzxlZB3cCfLa4ouZ-3I4QskcuFSKTtBIsPyi0x6vrQ=.02214e75-5219-4c6b-bdf2-5d16b4fd7342@github.com>
References: <DHzxlZB3cCfLa4ouZ-3I4QskcuFSKTtBIsPyi0x6vrQ=.02214e75-5219-4c6b-bdf2-5d16b4fd7342@github.com>
Message-ID: <u7ABD84D-s7VNBVLa5Hkp7UMI5TDvpQq-xQRcLi15nI=.28506bec-0431-4c83-b7b2-f85ed715e6b6@github.com>

On Mon, 16 Sep 2024 21:33:42 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Clean

This pull request has now been integrated.

Changeset: 843cec7e
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.org/shenandoah-jdk21u/commit/843cec7e2737d6b927df293b2f7dd1764394eed4
Stats:     2 lines in 1 file changed: 0 ins; 1 del; 1 mod

8339127: GenShen: Restore completed mark context assertion during class unloading

Backport-of: c7cfc7fa32fbe90bed39456288c03d74aa2432b9

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

PR: https://git.openjdk.org/shenandoah-jdk21u/pull/99

From kdnilsen at openjdk.org  Mon Sep 16 21:51:40 2024
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Mon, 16 Sep 2024 21:51:40 GMT
Subject: RFR: 8339960: GenShen: Fix inconsistencies in generational
 Shenandoah behavior [v2]
In-Reply-To: <iC_hPGmUdI86hXwB8zZ0TUY18L7lPU1HweCLpEjoEo8=.90c27500-49a4-4ed8-9861-e37c0248ba0c@github.com>
References: <iC_hPGmUdI86hXwB8zZ0TUY18L7lPU1HweCLpEjoEo8=.90c27500-49a4-4ed8-9861-e37c0248ba0c@github.com>
Message-ID: <hvvv1Axb7mK1l7NTpLGrkPEDoV2R5F6gXIpmqvXQa0Q=.22d7415a-b138-4475-a9a1-3aa86fb12692@github.com>

> This pull request contains a backport of commit 1a7d597d from the openjdk/shenandoah repository.
> 
> The commit being backported was authored by Kelvin Nilsen on 13 Sep 2024 and was reviewed by William Kemper.

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

  remove dependency on utilities/checkedCast.hpp

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

Changes:
  - all: https://git.openjdk.org/shenandoah-jdk21u/pull/90/files
  - new: https://git.openjdk.org/shenandoah-jdk21u/pull/90/files/94312e0e..e0a82e57

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

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

PR: https://git.openjdk.org/shenandoah-jdk21u/pull/90

From wkemper at openjdk.org  Mon Sep 16 22:07:55 2024
From: wkemper at openjdk.org (William Kemper)
Date: Mon, 16 Sep 2024 22:07:55 GMT
Subject: Integrated: 8339346: GenShen: Remove even more stale TODOs
Message-ID: <jI_LNbclBsYbor0oN1b3WQnQHU2TVIEWbsV4pjTEaks=.78cfc639-55d7-4984-909d-8bc205ea78ac@github.com>

Clean

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

Commit messages:
 - Backport dea5a915a4cb54ba5df59e19a63d3f552d7f69e4

Changes: https://git.openjdk.org/shenandoah-jdk21u/pull/100/files
  Webrev: https://webrevs.openjdk.org/?repo=shenandoah-jdk21u&pr=100&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8339346
  Stats: 205 lines in 18 files changed: 0 ins; 176 del; 29 mod
  Patch: https://git.openjdk.org/shenandoah-jdk21u/pull/100.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah-jdk21u.git pull/100/head:pull/100

PR: https://git.openjdk.org/shenandoah-jdk21u/pull/100

From wkemper at openjdk.org  Mon Sep 16 22:07:56 2024
From: wkemper at openjdk.org (William Kemper)
Date: Mon, 16 Sep 2024 22:07:56 GMT
Subject: Integrated: 8339346: GenShen: Remove even more stale TODOs
In-Reply-To: <jI_LNbclBsYbor0oN1b3WQnQHU2TVIEWbsV4pjTEaks=.78cfc639-55d7-4984-909d-8bc205ea78ac@github.com>
References: <jI_LNbclBsYbor0oN1b3WQnQHU2TVIEWbsV4pjTEaks=.78cfc639-55d7-4984-909d-8bc205ea78ac@github.com>
Message-ID: <C4v8TqviSznReasAl0XSenNElIUYnfbgJsZue26veo8=.abf31aa4-15d3-4872-aaa9-387084af962e@github.com>

On Mon, 16 Sep 2024 21:59:55 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Clean

This pull request has now been integrated.

Changeset: 7a5a4fa3
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.org/shenandoah-jdk21u/commit/7a5a4fa3375f94249565704549bbbf357cf20fe1
Stats:     205 lines in 18 files changed: 0 ins; 176 del; 29 mod

8339346: GenShen: Remove even more stale TODOs

Backport-of: dea5a915a4cb54ba5df59e19a63d3f552d7f69e4

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

PR: https://git.openjdk.org/shenandoah-jdk21u/pull/100

From wkemper at openjdk.org  Mon Sep 16 22:19:54 2024
From: wkemper at openjdk.org (William Kemper)
Date: Mon, 16 Sep 2024 22:19:54 GMT
Subject: RFR: 8339695: GenShen: Concurrent reset performance has regressed
Message-ID: <-658i8BJcnsGMpApgIxwGjuTADUIiGula6uEk9kwkFQ=.11a1bbc3-5681-4716-a4e3-210eaed05253@github.com>

Clean

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

Commit messages:
 - Backport 08c64116f1b604b5e0d3e777b83636753282b435

Changes: https://git.openjdk.org/shenandoah-jdk21u/pull/101/files
  Webrev: https://webrevs.openjdk.org/?repo=shenandoah-jdk21u&pr=101&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8339695
  Stats: 34 lines in 1 file changed: 6 ins; 6 del; 22 mod
  Patch: https://git.openjdk.org/shenandoah-jdk21u/pull/101.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah-jdk21u.git pull/101/head:pull/101

PR: https://git.openjdk.org/shenandoah-jdk21u/pull/101

From wkemper at openjdk.org  Mon Sep 16 22:22:19 2024
From: wkemper at openjdk.org (William Kemper)
Date: Mon, 16 Sep 2024 22:22:19 GMT
Subject: Integrated: 8339695: GenShen: Concurrent reset performance has
 regressed
In-Reply-To: <-658i8BJcnsGMpApgIxwGjuTADUIiGula6uEk9kwkFQ=.11a1bbc3-5681-4716-a4e3-210eaed05253@github.com>
References: <-658i8BJcnsGMpApgIxwGjuTADUIiGula6uEk9kwkFQ=.11a1bbc3-5681-4716-a4e3-210eaed05253@github.com>
Message-ID: <c_0b9jSGDRzBb05z0rtcvIwGxlU3JY2RDf0pOrHXiA8=.3d843363-54c9-4eab-8384-a53cf8c1ef39@github.com>

On Mon, 16 Sep 2024 22:14:13 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Clean

This pull request has now been integrated.

Changeset: edd5958f
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.org/shenandoah-jdk21u/commit/edd5958f238fbb17ed244d4b6eaae0790d1d467e
Stats:     34 lines in 1 file changed: 6 ins; 6 del; 22 mod

8339695: GenShen: Concurrent reset performance has regressed

Backport-of: 08c64116f1b604b5e0d3e777b83636753282b435

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

PR: https://git.openjdk.org/shenandoah-jdk21u/pull/101

From wkemper at openjdk.org  Mon Sep 16 22:29:54 2024
From: wkemper at openjdk.org (William Kemper)
Date: Mon, 16 Sep 2024 22:29:54 GMT
Subject: RFR: 8339870: Remove yet more stale TODOs
Message-ID: <DGs_HOlXZEGDEfNZLqFIEakcCS2QxgFFll49m_qyzO0=.5f8b66c5-acc0-4b02-872f-d1037a24f116@github.com>

Clean

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

Commit messages:
 - Backport b7405b19d531269ccb611cb5dc6a07f491a7b9de

Changes: https://git.openjdk.org/shenandoah-jdk21u/pull/102/files
  Webrev: https://webrevs.openjdk.org/?repo=shenandoah-jdk21u&pr=102&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8339870
  Stats: 318 lines in 15 files changed: 50 ins; 162 del; 106 mod
  Patch: https://git.openjdk.org/shenandoah-jdk21u/pull/102.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah-jdk21u.git pull/102/head:pull/102

PR: https://git.openjdk.org/shenandoah-jdk21u/pull/102

From wkemper at openjdk.org  Mon Sep 16 22:39:18 2024
From: wkemper at openjdk.org (William Kemper)
Date: Mon, 16 Sep 2024 22:39:18 GMT
Subject: Integrated: 8339870: Remove yet more stale TODOs
In-Reply-To: <DGs_HOlXZEGDEfNZLqFIEakcCS2QxgFFll49m_qyzO0=.5f8b66c5-acc0-4b02-872f-d1037a24f116@github.com>
References: <DGs_HOlXZEGDEfNZLqFIEakcCS2QxgFFll49m_qyzO0=.5f8b66c5-acc0-4b02-872f-d1037a24f116@github.com>
Message-ID: <lPiLw0zpnG8-SG0Gpe9HAvzaFb3TCn5H_VImGtoNZtY=.fb861aa4-7688-4890-b06c-18e299095eee@github.com>

On Mon, 16 Sep 2024 22:24:50 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Clean

This pull request has now been integrated.

Changeset: f0ffe612
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.org/shenandoah-jdk21u/commit/f0ffe612d354e706829f387154b806cbb6073456
Stats:     318 lines in 15 files changed: 50 ins; 162 del; 106 mod

8339870: Remove yet more stale TODOs

Backport-of: b7405b19d531269ccb611cb5dc6a07f491a7b9de

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

PR: https://git.openjdk.org/shenandoah-jdk21u/pull/102

From wkemper at openjdk.org  Mon Sep 16 22:48:51 2024
From: wkemper at openjdk.org (William Kemper)
Date: Mon, 16 Sep 2024 22:48:51 GMT
Subject: RFR: 8340137: GenShen: Reset mark bitmaps when a region is recycled
Message-ID: <c3k4JiU4Q0CaTGN6ek5MaHDFqTX6XV3Ec9GTJX6spuA=.9bd98515-440e-4123-a98c-dd4f02a06efa@github.com>

Clean back port, critical bug fix.

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

Commit messages:
 - Backport a8e2908eed1ab8c271eb206e0a41ee3d38b18de3

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

PR: https://git.openjdk.org/shenandoah-jdk21u/pull/103

From wkemper at openjdk.org  Mon Sep 16 23:03:25 2024
From: wkemper at openjdk.org (William Kemper)
Date: Mon, 16 Sep 2024 23:03:25 GMT
Subject: Integrated: 8340137: GenShen: Reset mark bitmaps when a region is
 recycled
In-Reply-To: <c3k4JiU4Q0CaTGN6ek5MaHDFqTX6XV3Ec9GTJX6spuA=.9bd98515-440e-4123-a98c-dd4f02a06efa@github.com>
References: <c3k4JiU4Q0CaTGN6ek5MaHDFqTX6XV3Ec9GTJX6spuA=.9bd98515-440e-4123-a98c-dd4f02a06efa@github.com>
Message-ID: <49Wj9_o00ea3Hs3RhYJykGCcf_hlcCTqzdKKOiESA_w=.35170850-1487-4faa-a07f-c90c4e944e9d@github.com>

On Mon, 16 Sep 2024 22:43:01 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Clean back port, critical bug fix.

This pull request has now been integrated.

Changeset: e966cef4
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.org/shenandoah-jdk21u/commit/e966cef489f6914b3439f48b4543e4c7b1ff6a8a
Stats:     4 lines in 1 file changed: 4 ins; 0 del; 0 mod

8340137: GenShen: Reset mark bitmaps when a region is recycled

Backport-of: a8e2908eed1ab8c271eb206e0a41ee3d38b18de3

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

PR: https://git.openjdk.org/shenandoah-jdk21u/pull/103

From kdnilsen at openjdk.org  Tue Sep 17 00:26:23 2024
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Tue, 17 Sep 2024 00:26:23 GMT
Subject: RFR: 8339643: Port JEP 404 to RISC-V [v2]
In-Reply-To: <yEiP-f7USvTdorMQHNEIiJuwNgAcf_Gf9uOJvRVA8yk=.5f1e27d8-8e52-47e6-848f-fd9c924cd107@github.com>
References: <J3I-KZdj2aYAEN7cFFDkuZEpp6WBM7AFaikL14CDdWM=.5f1201e3-3ca2-426e-b6ce-a4bd9aa9a879@github.com>
 <yEiP-f7USvTdorMQHNEIiJuwNgAcf_Gf9uOJvRVA8yk=.5f1e27d8-8e52-47e6-848f-fd9c924cd107@github.com>
Message-ID: <ayZGK5AgrQPslampqfgIEPfyOu8s6qbbWQl8BgdNm5g=.497a4470-13ad-471c-b396-18c19c505fc1@github.com>

On Fri, 13 Sep 2024 03:47:46 GMT, Fei Yang <fyang at openjdk.org> wrote:

>> The riscv64 implementation of [JDK-8337511](https://bugs.openjdk.org/browse/JDK-8337511) Implement JEP-404: Generational Shenandoah (Experimental).
>> This is mainly adapted from the changes in aarch64.
>> 
>> Testing
>> - [x] Gtest (release & fastdebug)
>> - [x] hotspot_gc_shenandoah (release & fastdebug)
>
> Fei Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review

Marked as reviewed by kdnilsen (Committer).

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

PR Review: https://git.openjdk.org/shenandoah/pull/493#pullrequestreview-2308027808

From fyang at openjdk.org  Tue Sep 17 07:35:11 2024
From: fyang at openjdk.org (Fei Yang)
Date: Tue, 17 Sep 2024 07:35:11 GMT
Subject: RFR: 8339643: Port JEP 404 to RISC-V [v3]
In-Reply-To: <J3I-KZdj2aYAEN7cFFDkuZEpp6WBM7AFaikL14CDdWM=.5f1201e3-3ca2-426e-b6ce-a4bd9aa9a879@github.com>
References: <J3I-KZdj2aYAEN7cFFDkuZEpp6WBM7AFaikL14CDdWM=.5f1201e3-3ca2-426e-b6ce-a4bd9aa9a879@github.com>
Message-ID: <Yw5fSsnnN93crXtTVdD1ttm02zxhbFalTvHAxyRQeb4=.d3652541-0cbb-4b5f-bc8f-ce55ca962166@github.com>

> The riscv64 implementation of [JDK-8337511](https://bugs.openjdk.org/browse/JDK-8337511) Implement JEP-404: Generational Shenandoah (Experimental).
> This is mainly adapted from the changes in aarch64.
> 
> Testing
> - [x] Gtest (release & fastdebug)
> - [x] hotspot_gc_shenandoah (release & fastdebug)

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

 - Merge remote-tracking branch 'upstream/master' into JDK-8339643
 - Review
 - JDK-8339643: Port JEP 404 to RISC-V

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

Changes:
  - all: https://git.openjdk.org/shenandoah/pull/493/files
  - new: https://git.openjdk.org/shenandoah/pull/493/files/9be141c0..54c5f73b

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

  Stats: 45277 lines in 1364 files changed: 27475 ins; 10650 del; 7152 mod
  Patch: https://git.openjdk.org/shenandoah/pull/493.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah.git pull/493/head:pull/493

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

From rkennke at openjdk.org  Tue Sep 17 09:35:02 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Tue, 17 Sep 2024 09:35:02 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v18]
In-Reply-To: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
Message-ID: <tzW1ygFfWY40OR9lB3z0gVv7H9WKJPbFCZmR0F23-_k=.de6459ea-024c-48de-a062-0136d0af0306@github.com>

> This is the main body of the JEP 450: Compact Object Headers (Experimental).
> 
> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing.
> 
> Main changes:
>  - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers.
>  - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded.
>  - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops).
>  - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all).
>  - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16).
>  - Arrays will now store their length at offset 8.
>  - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _coh variants of CDS archiv...

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

 - fix CompressedClassPointersEncodingScheme yet again for linux aarch64
 - Fixes post-8340184
 - Merge upstream up to and including 8340184
 - Merge remote-tracking branch 'origin/master' into JDK-8305895-v4
 - Fix  test/hotspot/jtreg/runtime/CompressedOops/CompressedClassPointersEncodingScheme.java
 - Fix loop on aarch64
 - clarify obscure assert in metasapce setup
 - Rework compressedklass encoding
 - remove stray debug output
 - Fixes post 8338526
 - ... and 47 more: https://git.openjdk.org/jdk/compare/7849f252...28a26aed

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

Changes: https://git.openjdk.org/jdk/pull/20677/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20677&range=17
  Stats: 4518 lines in 190 files changed: 3180 ins; 718 del; 620 mod
  Patch: https://git.openjdk.org/jdk/pull/20677.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20677/head:pull/20677

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

From stuefe at openjdk.org  Tue Sep 17 10:02:17 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Tue, 17 Sep 2024 10:02:17 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v11]
In-Reply-To: <b8u6PaStO4nt0AGnbZEkmXkzQKzXaB2c4lSiC9JWdTY=.a5805ef2-84d8-44c0-9dc0-3e90da3460aa@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <DUgk6HT_Zk5KnbmAd_HzrJi4B8D1J-uuoAGzReWyI8s=.6c04f90a-bf1d-49af-a31d-5224973952d4@github.com>
 <b8u6PaStO4nt0AGnbZEkmXkzQKzXaB2c4lSiC9JWdTY=.a5805ef2-84d8-44c0-9dc0-3e90da3460aa@github.com>
Message-ID: <IvzUGZlRyrzIiWxydj9nR_z-0seKPQXR3vZgv9fDYbs=.e21f58b1-42bc-42d5-9eb5-797320dcd9ce@github.com>

On Wed, 11 Sep 2024 12:25:37 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix FullGCForwarding initialization
>
> src/hotspot/share/memory/classLoaderMetaspace.hpp line 81:
> 
>> 79:   metaspace::MetaspaceArena* class_space_arena() const       { return _class_space_arena; }
>> 80: 
>> 81:   bool have_class_space_arena() const { return _class_space_arena != nullptr; }
> 
> This is unnecessary. Instead of having this and having to remember to check for nullness each time, just change the `_class_space_arena` to point to the same arena as the `_non_class_space_arena` does when we run with `-XX:-UseCompressedClassPointers`

I'd prefer not to. 

This logic (when -UCCP class space arena is NULL, with the implicit assumption that both are different entities) has been in there forever, and changing that is out of scope for and unrelated to this PR. I am not sure what will break if I change this but don't want to chase risk test errors at this point (one example, reporting would have to be adapted to recognize that both arenas are the same, and there are plenty of tests that would also need to be fixd).

This can be done in a follow-up RFE if necessary.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1762917467

From stuefe at openjdk.org  Tue Sep 17 10:05:20 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Tue, 17 Sep 2024 10:05:20 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v11]
In-Reply-To: <b8u6PaStO4nt0AGnbZEkmXkzQKzXaB2c4lSiC9JWdTY=.a5805ef2-84d8-44c0-9dc0-3e90da3460aa@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <DUgk6HT_Zk5KnbmAd_HzrJi4B8D1J-uuoAGzReWyI8s=.6c04f90a-bf1d-49af-a31d-5224973952d4@github.com>
 <b8u6PaStO4nt0AGnbZEkmXkzQKzXaB2c4lSiC9JWdTY=.a5805ef2-84d8-44c0-9dc0-3e90da3460aa@github.com>
Message-ID: <uvkx62POF-wL1HcEf22FxsR8sjbeiW3K2OKzqzcUwmg=.c3c4c165-ff8a-4839-a5bc-d269666a316e@github.com>

On Wed, 11 Sep 2024 13:05:10 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix FullGCForwarding initialization
>
> src/hotspot/share/memory/classLoaderMetaspace.cpp line 165:
> 
>> 163:   MetaBlock bl(ptr, word_size);
>> 164:   // If the block would be reusable for a Klass, add to class arena, otherwise to
>> 165:   // then non-class arena.
> 
> Nit: spelling, "the"

Okay

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1762928041

From stuefe at openjdk.org  Tue Sep 17 10:16:24 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Tue, 17 Sep 2024 10:16:24 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v11]
In-Reply-To: <b8u6PaStO4nt0AGnbZEkmXkzQKzXaB2c4lSiC9JWdTY=.a5805ef2-84d8-44c0-9dc0-3e90da3460aa@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <DUgk6HT_Zk5KnbmAd_HzrJi4B8D1J-uuoAGzReWyI8s=.6c04f90a-bf1d-49af-a31d-5224973952d4@github.com>
 <b8u6PaStO4nt0AGnbZEkmXkzQKzXaB2c4lSiC9JWdTY=.a5805ef2-84d8-44c0-9dc0-3e90da3460aa@github.com>
Message-ID: <HUXKSlIwpGr-tpd3FY7OBJJ_mUDUYFb4Z51fLmndwuc=.aeff8ad5-6710-4ffa-a377-73eb69811667@github.com>

On Wed, 11 Sep 2024 13:50:59 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix FullGCForwarding initialization
>
> src/hotspot/share/memory/metaspace.cpp line 656:
> 
>> 654:     // Adjust size of the compressed class space.
>> 655: 
>> 656:     const size_t res_align = reserve_alignment();
> 
> Can you change the name to `root_chunk_size`?

It feels wrong, since this is a deeply hidden implementation detail.\

I will remove this temporary variable, which will also make the diff smaller.

> src/hotspot/share/memory/metaspace.hpp line 112:
> 
>> 110:   static size_t max_allocation_word_size();
>> 111: 
>> 112:   // Minimum allocation alignment, in bytes. All MetaData shall be aligned correclty
> 
> Nit: Spelling, "correctly"

Fixed

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1762968742
PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1762972938

From stuefe at openjdk.org  Tue Sep 17 10:23:19 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Tue, 17 Sep 2024 10:23:19 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v11]
In-Reply-To: <b8u6PaStO4nt0AGnbZEkmXkzQKzXaB2c4lSiC9JWdTY=.a5805ef2-84d8-44c0-9dc0-3e90da3460aa@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <DUgk6HT_Zk5KnbmAd_HzrJi4B8D1J-uuoAGzReWyI8s=.6c04f90a-bf1d-49af-a31d-5224973952d4@github.com>
 <b8u6PaStO4nt0AGnbZEkmXkzQKzXaB2c4lSiC9JWdTY=.a5805ef2-84d8-44c0-9dc0-3e90da3460aa@github.com>
Message-ID: <McAy2Wmaq0Pz-V1qYn1ejKHxBqB86FLFTmz1ALHa1K0=.1dbcb43f-dd7f-41c3-ac2b-ce1134f802dd@github.com>

On Wed, 11 Sep 2024 11:25:56 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix FullGCForwarding initialization
>
> src/hotspot/share/memory/metaspace/metablock.hpp line 48:
> 
>> 46: 
>> 47:   MetaWord* base() const { return _base; }
>> 48:   const MetaWord* end() const { return _base + _word_size; }
> 
> `assert(is_nonempty())`

Raises the question of why here and not in other accessors? 

Note that the only patch via which end() is called already asserts for non-empty-ness (MetaspaceArena::contains).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1762985723

From jsjolen at openjdk.org  Tue Sep 17 10:31:19 2024
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Tue, 17 Sep 2024 10:31:19 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v11]
In-Reply-To: <IvzUGZlRyrzIiWxydj9nR_z-0seKPQXR3vZgv9fDYbs=.e21f58b1-42bc-42d5-9eb5-797320dcd9ce@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <DUgk6HT_Zk5KnbmAd_HzrJi4B8D1J-uuoAGzReWyI8s=.6c04f90a-bf1d-49af-a31d-5224973952d4@github.com>
 <b8u6PaStO4nt0AGnbZEkmXkzQKzXaB2c4lSiC9JWdTY=.a5805ef2-84d8-44c0-9dc0-3e90da3460aa@github.com>
 <IvzUGZlRyrzIiWxydj9nR_z-0seKPQXR3vZgv9fDYbs=.e21f58b1-42bc-42d5-9eb5-797320dcd9ce@github.com>
Message-ID: <Wzl0buNcLNqNrvVd8m4A8-oPngryjSc5wBcDoaT-6o0=.fbed6a18-5f64-4b2c-93b7-abb65fd5b3ec@github.com>

On Tue, 17 Sep 2024 09:59:49 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> src/hotspot/share/memory/classLoaderMetaspace.hpp line 81:
>> 
>>> 79:   metaspace::MetaspaceArena* class_space_arena() const       { return _class_space_arena; }
>>> 80: 
>>> 81:   bool have_class_space_arena() const { return _class_space_arena != nullptr; }
>> 
>> This is unnecessary. Instead of having this and having to remember to check for nullness each time, just change the `_class_space_arena` to point to the same arena as the `_non_class_space_arena` does when we run with `-XX:-UseCompressedClassPointers`
>
> I'd prefer not to. 
> 
> This logic (when -UCCP class space arena is NULL, with the implicit assumption that both are different entities) has been in there forever, and changing that is out of scope for and unrelated to this PR. I am not sure what will break if I change this but don't want to risk test errors at this point (one example, reporting would have to be adapted to recognize that both arenas are the same, and there are plenty of tests that would also need to be fixd).
> 
> This can be done in a follow-up RFE if necessary.

OK, that's fine.

>> src/hotspot/share/memory/metaspace.cpp line 656:
>> 
>>> 654:     // Adjust size of the compressed class space.
>>> 655: 
>>> 656:     const size_t res_align = reserve_alignment();
>> 
>> Can you change the name to `root_chunk_size`?
>
> It feels wrong, since this is a deeply hidden implementation detail.\
> 
> I will remove this temporary variable, which will also make the diff smaller.

Sounds OK, I wanted the name change to indicate that "hey, deep impl detail where we use this to mean something else".

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1762993568
PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1762994772

From stuefe at openjdk.org  Tue Sep 17 10:31:20 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Tue, 17 Sep 2024 10:31:20 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v11]
In-Reply-To: <b8u6PaStO4nt0AGnbZEkmXkzQKzXaB2c4lSiC9JWdTY=.a5805ef2-84d8-44c0-9dc0-3e90da3460aa@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <DUgk6HT_Zk5KnbmAd_HzrJi4B8D1J-uuoAGzReWyI8s=.6c04f90a-bf1d-49af-a31d-5224973952d4@github.com>
 <b8u6PaStO4nt0AGnbZEkmXkzQKzXaB2c4lSiC9JWdTY=.a5805ef2-84d8-44c0-9dc0-3e90da3460aa@github.com>
Message-ID: <32_SIVHDWyZyYSvbV1jUHc631MTKUP2Thh_M9Q71jrc=.351aed23-599d-4a53-9cc0-0e9c85ecdf03@github.com>

On Wed, 11 Sep 2024 11:29:38 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix FullGCForwarding initialization
>
> src/hotspot/share/memory/metaspace/metablock.hpp line 52:
> 
>> 50:   bool is_empty() const { return _base == nullptr; }
>> 51:   bool is_nonempty() const { return _base != nullptr; }
>> 52:   void reset() { _base = nullptr; _word_size = 0; }
> 
> Is this function really necessary? According to my IDE it's only used in tests and even then the `MetaBlock` isn't used afterwards (so it has no effect).

see test_clms.cpp, test_random function, used in two places there.

> src/hotspot/share/memory/metaspace/metaspaceArena.hpp line 84:
> 
>> 82:   // between threads and needs to be synchronized in CLMS.
>> 83: 
>> 84:   const size_t _allocation_alignment_words;
> 
> Nit: Document this? All other members are documented.

ok

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1762993378
PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1762995731

From stuefe at openjdk.org  Tue Sep 17 10:31:23 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Tue, 17 Sep 2024 10:31:23 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v18]
In-Reply-To: <b8u6PaStO4nt0AGnbZEkmXkzQKzXaB2c4lSiC9JWdTY=.a5805ef2-84d8-44c0-9dc0-3e90da3460aa@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <DUgk6HT_Zk5KnbmAd_HzrJi4B8D1J-uuoAGzReWyI8s=.6c04f90a-bf1d-49af-a31d-5224973952d4@github.com>
 <b8u6PaStO4nt0AGnbZEkmXkzQKzXaB2c4lSiC9JWdTY=.a5805ef2-84d8-44c0-9dc0-3e90da3460aa@github.com>
Message-ID: <nE6sEWK9Et-vO44iZzCxbuZv-qnE20-DrCXBIdh7e1o=.089d17cb-8501-4e39-884d-9f638920b638@github.com>

On Wed, 11 Sep 2024 11:40:24 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> Roman Kennke has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 57 commits:
>> 
>>  - fix CompressedClassPointersEncodingScheme yet again for linux aarch64
>>  - Fixes post-8340184
>>  - Merge upstream up to and including 8340184
>>  - Merge remote-tracking branch 'origin/master' into JDK-8305895-v4
>>  - Fix  test/hotspot/jtreg/runtime/CompressedOops/CompressedClassPointersEncodingScheme.java
>>  - Fix loop on aarch64
>>  - clarify obscure assert in metasapce setup
>>  - Rework compressedklass encoding
>>  - remove stray debug output
>>  - Fixes post 8338526
>>  - ... and 47 more: https://git.openjdk.org/jdk/compare/7849f252...28a26aed
>
> src/hotspot/share/memory/metaspace/metaspaceArena.hpp line 44:
> 
>> 42: class FreeBlocks;
>> 43: 
>> 44: struct ArenaStats;
> 
> Nit: Sort?

ok

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1762994972

From jsjolen at openjdk.org  Tue Sep 17 10:47:25 2024
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Tue, 17 Sep 2024 10:47:25 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v18]
In-Reply-To: <tzW1ygFfWY40OR9lB3z0gVv7H9WKJPbFCZmR0F23-_k=.de6459ea-024c-48de-a062-0136d0af0306@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <tzW1ygFfWY40OR9lB3z0gVv7H9WKJPbFCZmR0F23-_k=.de6459ea-024c-48de-a062-0136d0af0306@github.com>
Message-ID: <sXx4wxL6nlbJFQXLjN83xKY43ZZ1PyuLwk32st0Dfhg=.df5ee7f3-9c92-41d4-a80b-6e7291619a23@github.com>

On Tue, 17 Sep 2024 09:35:02 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> This is the main body of the JEP 450: Compact Object Headers (Experimental).
>> 
>> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing.
>> 
>> Main changes:
>>  - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers.
>>  - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded.
>>  - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops).
>>  - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all).
>>  - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16).
>>  - Arrays will now store their length at offset 8.
>>  - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _co...
>
> Roman Kennke has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 57 commits:
> 
>  - fix CompressedClassPointersEncodingScheme yet again for linux aarch64
>  - Fixes post-8340184
>  - Merge upstream up to and including 8340184
>  - Merge remote-tracking branch 'origin/master' into JDK-8305895-v4
>  - Fix  test/hotspot/jtreg/runtime/CompressedOops/CompressedClassPointersEncodingScheme.java
>  - Fix loop on aarch64
>  - clarify obscure assert in metasapce setup
>  - Rework compressedklass encoding
>  - remove stray debug output
>  - Fixes post 8338526
>  - ... and 47 more: https://git.openjdk.org/jdk/compare/7849f252...28a26aed

Hi,

We've gone through the rest of the Metaspace code and looked at the tests. It looks OK to us. Would like to see some style cleanups in the tests, but that can wait as a follow up.

test/hotspot/gtest/metaspace/test_clms.cpp line 193:

> 191: 
> 192:       {
> 193:         // Nonclass arena allocation.

The style in this source file isn't really up to scratch, especially *these* lines. Anyway, it's in the tests, so I'm OK with this being fixed in a follow up RFE.

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

PR Review: https://git.openjdk.org/jdk/pull/20677#pullrequestreview-2309360771
PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1763005291

From rkennke at openjdk.org  Tue Sep 17 12:52:03 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Tue, 17 Sep 2024 12:52:03 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v19]
In-Reply-To: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
Message-ID: <FENW_mCsovAzl3Jpaf-3Sz4Lm8PWbCYlDHEqrDT4qjM=.0f01c195-d868-4ba0-a3f6-2bdf8e95e510@github.com>

> This is the main body of the JEP 450: Compact Object Headers (Experimental).
> 
> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing.
> 
> Main changes:
>  - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers.
>  - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded.
>  - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops).
>  - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all).
>  - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16).
>  - Arrays will now store their length at offset 8.
>  - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _coh variants of CDS archiv...

Roman Kennke has updated the pull request incrementally with two additional commits since the last revision:

 - CompressedKlassPointers::is_encodable shall be callable with -UseCCP
 - Johan review feedback

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20677/files
  - new: https://git.openjdk.org/jdk/pull/20677/files/28a26aed..612d3045

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20677&range=18
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20677&range=17-18

  Stats: 39 lines in 7 files changed: 22 ins; 8 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/20677.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20677/head:pull/20677

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

From kdnilsen at openjdk.org  Tue Sep 17 17:21:26 2024
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Tue, 17 Sep 2024 17:21:26 GMT
Subject: RFR: 8339960: GenShen: Fix inconsistencies in generational
 Shenandoah behavior [v2]
In-Reply-To: <hvvv1Axb7mK1l7NTpLGrkPEDoV2R5F6gXIpmqvXQa0Q=.22d7415a-b138-4475-a9a1-3aa86fb12692@github.com>
References: <iC_hPGmUdI86hXwB8zZ0TUY18L7lPU1HweCLpEjoEo8=.90c27500-49a4-4ed8-9861-e37c0248ba0c@github.com>
 <hvvv1Axb7mK1l7NTpLGrkPEDoV2R5F6gXIpmqvXQa0Q=.22d7415a-b138-4475-a9a1-3aa86fb12692@github.com>
Message-ID: <IvfjP3qP2ffa2JnoNMjYEsu6RTrRjClA3m_r4aRF6i4=.ce8a0df8-f89c-4103-a156-b7b7537440dc@github.com>

On Mon, 16 Sep 2024 21:51:40 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> This pull request contains a backport of commit 1a7d597d from the openjdk/shenandoah repository.
>> 
>> The commit being backported was authored by Kelvin Nilsen on 13 Sep 2024 and was reviewed by William Kemper.
>
> Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove dependency on utilities/checkedCast.hpp

We are planning to problem-list IU tests and deprecate IU mode.

The failure reported by GHA tests with ExceptionInInitializerError is known and has been fixed upstream. The fix is not feasible for backporting to JDK21.  See https://github.com/openjdk/jdk/pull/14404

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

PR Comment: https://git.openjdk.org/shenandoah-jdk21u/pull/90#issuecomment-2356487302

From ysr at openjdk.org  Tue Sep 17 17:35:36 2024
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Tue, 17 Sep 2024 17:35:36 GMT
Subject: RFR: 8339960: GenShen: Fix inconsistencies in generational
 Shenandoah behavior [v2]
In-Reply-To: <hvvv1Axb7mK1l7NTpLGrkPEDoV2R5F6gXIpmqvXQa0Q=.22d7415a-b138-4475-a9a1-3aa86fb12692@github.com>
References: <iC_hPGmUdI86hXwB8zZ0TUY18L7lPU1HweCLpEjoEo8=.90c27500-49a4-4ed8-9861-e37c0248ba0c@github.com>
 <hvvv1Axb7mK1l7NTpLGrkPEDoV2R5F6gXIpmqvXQa0Q=.22d7415a-b138-4475-a9a1-3aa86fb12692@github.com>
Message-ID: <w3hMsCOhaoYgqLlJeGC_1g6fvecLmSlAwVt0IkFqWiU=.ab4401e9-f5ce-4240-b38c-6d698a3e5acc@github.com>

On Mon, 16 Sep 2024 21:51:40 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> This pull request contains a backport of commit 1a7d597d from the openjdk/shenandoah repository.
>> 
>> The commit being backported was authored by Kelvin Nilsen on 13 Sep 2024 and was reviewed by William Kemper.
>
> Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove dependency on utilities/checkedCast.hpp

Marked as reviewed by ysr (Committer).

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

PR Review: https://git.openjdk.org/shenandoah-jdk21u/pull/90#pullrequestreview-2310406769

From kdnilsen at openjdk.org  Tue Sep 17 17:50:44 2024
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Tue, 17 Sep 2024 17:50:44 GMT
Subject: RFR: 8339960: GenShen: Fix inconsistencies in generational
 Shenandoah behavior [v3]
In-Reply-To: <iC_hPGmUdI86hXwB8zZ0TUY18L7lPU1HweCLpEjoEo8=.90c27500-49a4-4ed8-9861-e37c0248ba0c@github.com>
References: <iC_hPGmUdI86hXwB8zZ0TUY18L7lPU1HweCLpEjoEo8=.90c27500-49a4-4ed8-9861-e37c0248ba0c@github.com>
Message-ID: <PRUFjjEuzXYeHAAENJcM5q2llUu_2mL9xX8xb5tH-LY=.aaf7b2d2-4eea-48d1-aa50-67b91e2fd109@github.com>

> This pull request contains a backport of commit 1a7d597d from the openjdk/shenandoah repository.
> 
> The commit being backported was authored by Kelvin Nilsen on 13 Sep 2024 and was reviewed by William Kemper.

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

  Problem list two tests

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

Changes:
  - all: https://git.openjdk.org/shenandoah-jdk21u/pull/90/files
  - new: https://git.openjdk.org/shenandoah-jdk21u/pull/90/files/e0a82e57..7bf48357

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

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

PR: https://git.openjdk.org/shenandoah-jdk21u/pull/90

From gziemski at openjdk.org  Tue Sep 17 20:02:18 2024
From: gziemski at openjdk.org (Gerard Ziemski)
Date: Tue, 17 Sep 2024 20:02:18 GMT
Subject: Integrated: 8337563: NMT: rename MEMFLAGS to MemTag
In-Reply-To: <aQDgRwE-H5U0lz8wooLBAQZsuDnB5zZzjMhheIu3y9Y=.0bae7ae4-062e-47de-b7c3-4fedc5d7e20a@github.com>
References: <aQDgRwE-H5U0lz8wooLBAQZsuDnB5zZzjMhheIu3y9Y=.0bae7ae4-062e-47de-b7c3-4fedc5d7e20a@github.com>
Message-ID: <6f1uGL8qdaFMXKcWOHRwQb7z_up-MGAHqjOo9WEP3vA=.fa267ab6-4754-4175-912b-c10ca62cf7ac@github.com>

On Thu, 5 Sep 2024 16:10:05 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

> Please review this cleanup, where we rename `MEMFLAGS` to `MemTag`.
> 
> `MEMFLAGS` implies that we can use more than one at the same time, but those are exclusive values, so `MemTag` is a more suitable name.
> 
> This fix also includes a cleanup of all the related function/template parameter names and local variable names.
> 
> Testing is pending...
> 
> Note: there is more history in old closed PRs [https://github.com/openjdk/jdk/pull/20497](https://github.com/openjdk/jdk/pull/20497) and [https://github.com/openjdk/jdk/pull/20472](https://github.com/openjdk/jdk/pull/20472)

This pull request has now been integrated.

Changeset: eabfc6e4
Author:    Gerard Ziemski <gziemski at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/eabfc6e4d901c53b93a78da740ca376607d9576d
Stats:     1533 lines in 127 files changed: 144 ins; 138 del; 1251 mod

8337563: NMT: rename MEMFLAGS to MemTag

Reviewed-by: dholmes, coleenp, jsjolen

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

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

From fyang at openjdk.org  Wed Sep 18 03:17:03 2024
From: fyang at openjdk.org (Fei Yang)
Date: Wed, 18 Sep 2024 03:17:03 GMT
Subject: RFR: 8339643: Port JEP 404 to RISC-V [v4]
In-Reply-To: <J3I-KZdj2aYAEN7cFFDkuZEpp6WBM7AFaikL14CDdWM=.5f1201e3-3ca2-426e-b6ce-a4bd9aa9a879@github.com>
References: <J3I-KZdj2aYAEN7cFFDkuZEpp6WBM7AFaikL14CDdWM=.5f1201e3-3ca2-426e-b6ce-a4bd9aa9a879@github.com>
Message-ID: <AFl8f2VD_LyEAlgHcNu6Yc8j0o20bDm4XUPYjzNxeVY=.bac34882-5b54-4b6b-9325-ee0c3d0624f5@github.com>

> The riscv64 implementation of [JDK-8337511](https://bugs.openjdk.org/browse/JDK-8337511) Implement JEP-404: Generational Shenandoah (Experimental).
> This is mainly adapted from the changes in aarch64.
> 
> Testing
> - [x] Gtest (release & fastdebug)
> - [x] hotspot_gc_shenandoah (release & fastdebug)

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

  Improve ShenandoahBarrierSetAssembler::store_check

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

Changes:
  - all: https://git.openjdk.org/shenandoah/pull/493/files
  - new: https://git.openjdk.org/shenandoah/pull/493/files/54c5f73b..53ee41c2

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

  Stats: 7 lines in 1 file changed: 1 ins; 3 del; 3 mod
  Patch: https://git.openjdk.org/shenandoah/pull/493.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah.git pull/493/head:pull/493

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

From fyang at openjdk.org  Wed Sep 18 04:01:22 2024
From: fyang at openjdk.org (Fei Yang)
Date: Wed, 18 Sep 2024 04:01:22 GMT
Subject: RFR: 8339643: Port JEP 404 to RISC-V [v4]
In-Reply-To: <AFl8f2VD_LyEAlgHcNu6Yc8j0o20bDm4XUPYjzNxeVY=.bac34882-5b54-4b6b-9325-ee0c3d0624f5@github.com>
References: <J3I-KZdj2aYAEN7cFFDkuZEpp6WBM7AFaikL14CDdWM=.5f1201e3-3ca2-426e-b6ce-a4bd9aa9a879@github.com>
 <AFl8f2VD_LyEAlgHcNu6Yc8j0o20bDm4XUPYjzNxeVY=.bac34882-5b54-4b6b-9325-ee0c3d0624f5@github.com>
Message-ID: <ugPqGTw6BPAZkbo4P1w0A9Lz2HkZ1PlRUu2b5K2ys50=.b54b7bbd-d3cc-4c6d-8023-5866322387be@github.com>

On Wed, 18 Sep 2024 03:17:03 GMT, Fei Yang <fyang at openjdk.org> wrote:

>> The riscv64 implementation of [JDK-8337511](https://bugs.openjdk.org/browse/JDK-8337511) Implement JEP-404: Generational Shenandoah (Experimental).
>> This is mainly adapted from the changes in aarch64.
>> 
>> Testing
>> - [x] Gtest (release & fastdebug)
>> - [x] hotspot_gc_shenandoah (release & fastdebug)
>
> Fei Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improve ShenandoahBarrierSetAssembler::store_check

Thanks all for the review. Merged master and pushed one minor improvement for `ShenandoahBarrierSetAssembler::store_check`. This saves us one add instruction when doing address calculation under `UseCondCardMark`. `hotspot_gc_shenandoah` & `gtest` tested with release and fastdebug builds. I am going to integrate this change if no other opinions.

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

PR Comment: https://git.openjdk.org/shenandoah/pull/493#issuecomment-2357443986

From rkennke at openjdk.org  Wed Sep 18 12:11:31 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Wed, 18 Sep 2024 12:11:31 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v15]
In-Reply-To: <6UJOrZqmfsJj6pRzMjPdlYt191QgBV6fIv1qJAYsv60=.15284272-464f-4321-b76c-3412dafc6c63@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <CCz9B03dUxzua_YHk9-nyyHS_FTa6axwrwYjACcz4Y0=.6052f53c-9ddb-4868-a817-aff4276a2b6a@github.com>
 <6UJOrZqmfsJj6pRzMjPdlYt191QgBV6fIv1qJAYsv60=.15284272-464f-4321-b76c-3412dafc6c63@github.com>
Message-ID: <poutu1_cWKZJS_aUjdHdxXdoYBb0nS5Zohb1-_UwFiY=.403c84c9-a971-4b16-b436-e34cc9654321@github.com>

On Mon, 16 Sep 2024 06:53:42 GMT, Roberto Casta?eda Lozano <rcastanedalo at openjdk.org> wrote:

>> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Various touch-ups
>
> src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.cpp line 2576:
> 
>> 2574:   } else {
>> 2575:     lea(dst, Address(obj, index, Address::lsl(scale)));
>> 2576:     ldr(dst, Address(dst, offset));
> 
> Do you have a reproducer (or, better yet, a test case) that exercises this case? I ran Oracle's internal CI tiers 1-5 and could never hit it. Could this happen for x64 as well?

AFAIK, this happens only when using compressed oops with a heap-base in r27. When running with that setting, we would get addresses like r27[nklass] or r27[nklass]+offset, both with scale=8. You would need large heaps, perhaps >4GB, to get this coops setting. The problem with aarch64 is that we can't have an address like  r27[nklass]+offset, that's why we need to lea the r27[nklass] part first.
Yes, this also happens on x86, but x86 supports  rX[nklass]+offset addressing.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1764937842

From rkennke at openjdk.org  Wed Sep 18 12:25:50 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Wed, 18 Sep 2024 12:25:50 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v20]
In-Reply-To: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
Message-ID: <1o2b4fxBhqrlRqkNwKqZD1mgRNfTM16_NHZweEbd9SI=.1f68868b-1b98-4f78-9d37-2a805ffc932b@github.com>

> This is the main body of the JEP 450: Compact Object Headers (Experimental).
> 
> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing.
> 
> Main changes:
>  - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers.
>  - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded.
>  - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops).
>  - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all).
>  - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16).
>  - Arrays will now store their length at offset 8.
>  - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _coh variants of CDS archiv...

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

 - Merge remote-tracking branch 'origin/master' into JDK-8305895-v4
 - CompressedKlassPointers::is_encodable shall be callable with -UseCCP
 - Johan review feedback
 - fix CompressedClassPointersEncodingScheme yet again for linux aarch64
 - Fixes post-8340184
 - Merge upstream up to and including 8340184
 - Merge remote-tracking branch 'origin/master' into JDK-8305895-v4
 - Fix  test/hotspot/jtreg/runtime/CompressedOops/CompressedClassPointersEncodingScheme.java
 - Fix loop on aarch64
 - clarify obscure assert in metasapce setup
 - ... and 50 more: https://git.openjdk.org/jdk/compare/19b2cee4...bb641621

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

Changes: https://git.openjdk.org/jdk/pull/20677/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20677&range=19
  Stats: 4525 lines in 190 files changed: 3194 ins; 718 del; 613 mod
  Patch: https://git.openjdk.org/jdk/pull/20677.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20677/head:pull/20677

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

From yzheng at openjdk.org  Wed Sep 18 12:25:51 2024
From: yzheng at openjdk.org (Yudi Zheng)
Date: Wed, 18 Sep 2024 12:25:51 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v19]
In-Reply-To: <FENW_mCsovAzl3Jpaf-3Sz4Lm8PWbCYlDHEqrDT4qjM=.0f01c195-d868-4ba0-a3f6-2bdf8e95e510@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <FENW_mCsovAzl3Jpaf-3Sz4Lm8PWbCYlDHEqrDT4qjM=.0f01c195-d868-4ba0-a3f6-2bdf8e95e510@github.com>
Message-ID: <RfVmBzOwNMSLLg29JMF6QNg_5I_VBr4sYTepEVylQc8=.02dbd983-ddb2-4602-914f-1d0e13c05e29@github.com>

On Tue, 17 Sep 2024 12:52:03 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> This is the main body of the JEP 450: Compact Object Headers (Experimental).
>> 
>> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing.
>> 
>> Main changes:
>>  - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers.
>>  - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded.
>>  - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops).
>>  - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all).
>>  - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16).
>>  - Arrays will now store their length at offset 8.
>>  - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _co...
>
> Roman Kennke has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - CompressedKlassPointers::is_encodable shall be callable with -UseCCP
>  - Johan review feedback

Could you please cherry pick https://github.com/mur47x111/jdk/commit/c45ebc2a89d0b25a3dd8cc46386e37a635ff9af2 for the JVMCI support?

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

PR Comment: https://git.openjdk.org/jdk/pull/20677#issuecomment-2358324621

From rkennke at openjdk.org  Wed Sep 18 12:38:21 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Wed, 18 Sep 2024 12:38:21 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v6]
In-Reply-To: <xyQ56u8rEyLnbVv9iP23zziwfEkc0v9bm1MGVQ8BUHY=.352e102f-41d3-4ef6-86d2-2ebc998671d1@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <BGmZ04yibLn_KtPyQrA3sQv5OtMonrcDy3aN0vAj8NA=.5de6cae3-3a05-4a74-a15c-aade4176bdeb@github.com>
 <Og4I5G3w51d7zF27JawLM9pm_XpHwijYt3lJZ4hpeWQ=.fd974e82-2ce0-4ebd-b49e-108ab87690a9@github.com>
 <S-95OBPOZb6GfBEUIDtHxCB4hTFPB2uNf5YmwMerGcE=.83afc323-883e-4ae0-8d10-fe7030cddb33@github.com>
 <ZnddOJnCLP0HABu3ymeWaAvcJNd3mKz8AhFwOtUAYW8=.f534bbd8-c222-4cd7-b6a9-3d6fd644c5e1@github.com>
 <SKA53xBzGbvMWiQxBtEYG9QB2KqZOKEBMzJzbQb_Zr8=.0cd24aa4-3aed-46e6-9092-bbc4b926bb42@github.com>
 <xyQ56u8rEyLnbVv9iP23zziwfEkc0v9bm1MGVQ8BUHY=.352e102f-41d3-4ef6-86d2-2ebc998671d1@github.com>
Message-ID: <kUw1IOXnjaF1IqloewVZ8vlWvB2qGcSCSgPFCUtK6L0=.997c885c-48b1-4c1c-9c06-4d2eacaf86ea@github.com>

On Mon, 9 Sep 2024 19:04:13 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> I pulled your changes and I see one slight difference in the output. The following line is missing:
>> 
>> `_metadata._compressed_klass: InstanceKlass for java/util/concurrent/locks/AbstractQueuedSynchronizer$ConditionObject`
>> 
>> I realize that there is no `_metadata._compressed_klass` when you have compact headers, and that the Klass* is encoded in the `_mark` word, which is now looks something like this in the output:
>> 
>> _mark: 16294762323640321
>> 
>> So you can say that the Klass* is embedded in the _mark work, but this isn't of much help to SA users. I think what is expected is that the visitor is passed a MetadataField object that when getValue() is called on it, the Klass mirror is returned. Maybe we need a new CompactKlassField type like we current have a NarrowKlassField field type, and it will do the decoding of the _mark work into a Klass. The current getKlass() is related to this.
>
> Thinking about this a bit more, maybe _mark needs to be a MetadataFile rather than CInt. This is a kind of odd situation. Basically we have a CInt field that is more than just simple bits used as flags or small integers. It also gets you to the Klass*. Possibly SA should treat _mark is two seprate fields; one that remains a CInt as it currently is and another that treats it as an encoded Klass* like the NarrowKlassField case.

Do you think this needs to be addressed before integration? And if so, could you help with implementation? Or could we do it after intergration? Then please file a follow-up issue.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1764976086

From rkennke at openjdk.org  Wed Sep 18 12:59:25 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Wed, 18 Sep 2024 12:59:25 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v9]
In-Reply-To: <NR6CKOtdUaVarB7hiAUIAsIMe03qiTQr5VcEOWGt8mA=.164efc10-f0ff-4ddf-80b8-c56599c0ba7d@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <6Rant6SjxpFIHHWNthWc_plOdnGpWPvqj3rxRe144po=.bcdbad7a-e93a-41a3-b958-6ae602c7e083@github.com>
 <NR6CKOtdUaVarB7hiAUIAsIMe03qiTQr5VcEOWGt8mA=.164efc10-f0ff-4ddf-80b8-c56599c0ba7d@github.com>
Message-ID: <BNQiyA0NCBO-oFZU4Nz3yvaMxDzICFxfqDKWt4wCL_U=.9405414d-f961-4168-8d26-ef5f58069161@github.com>

On Mon, 9 Sep 2024 18:30:21 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Roman Kennke has updated the pull request incrementally with six additional commits since the last revision:
>> 
>>  - Print as warning when UCOH doesn't match in CDS archive
>>  - Improve initialization of mark-word in CDS ArchiveHeapWriter
>>  - Simplify getKlass() in SA
>>  - Simplify oopDesc::init_mark()
>>  - Get rid of forward_safe_* methods
>>  - GCForwarding touch-ups
>
> src/hotspot/share/oops/markWord.inline.hpp line 90:
> 
>> 88:   ShouldNotReachHere();
>> 89:   return markWord();
>> 90: #endif
> 
> Is the ifdef _LP64 necessary, since UseCompactObjectHeaders should always be false for 32 bits?

Kindof. The problem is that klass_shift is larger than 31, and shifting with it would thus be UB and generate a compiler warning. I opted to simply not compile any of that code in 32bit builds. We could also define klass_shift differently on 32bit.
Long-term (maybe with Lilliput2/4-byte-headers?) it would be nice to consolidate the header layout between 32 and 64 bit builds and not make any distinction anywhere. E.g. define markWord (or objectHeader?) in a single way, and use that to extract all the relevant stuff. It's not totally unlikely that we deprecate 32-bit builds before that can happen, though.

> src/hotspot/share/oops/oop.inline.hpp line 90:
> 
>> 88:   } else {
>> 89:     return markWord::prototype();
>> 90:   }
> 
> Could this be unconditional since prototoype_header is initialized for all Klasses?

yes, but there is ongoing effort (at Oracle) to get rid of ```Klass::_prototype_header``` altogether. Let's wait for that and see how it looks then.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1765003983
PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1765006669

From rkennke at openjdk.org  Wed Sep 18 13:23:44 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Wed, 18 Sep 2024 13:23:44 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v21]
In-Reply-To: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
Message-ID: <TCFshDmOrJjN0zTh1X9BGEa_rczyMqRbyDIiYsFr_5I=.ea051371-4c86-461e-8721-83b32caf808f@github.com>

> This is the main body of the JEP 450: Compact Object Headers (Experimental).
> 
> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing.
> 
> Main changes:
>  - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers.
>  - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded.
>  - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops).
>  - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all).
>  - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16).
>  - Arrays will now store their length at offset 8.
>  - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _coh variants of CDS archiv...

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

  JVMCI support

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20677/files
  - new: https://git.openjdk.org/jdk/pull/20677/files/bb641621..9ad2e62f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20677&range=20
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20677&range=19-20

  Stats: 22 lines in 6 files changed: 16 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/20677.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20677/head:pull/20677

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

From shade at openjdk.org  Wed Sep 18 13:55:37 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 18 Sep 2024 13:55:37 GMT
Subject: RFR: 8340381: Shenandoah: Class mirrors verification should check
 forwarded objects
Message-ID: <9vV2xnuP2lgRCLLbB5LWnIg26HtPjS7BOIyt0qaLkwg=.d7975d49-c70b-43e5-89cb-ef1b4f86ac52@github.com>

The from-space objects can be effectively dead, and their backlinks to `InstanceKlass*` not updated anymore. So they can point to garbage. 

Additional testing:
 - [x] Some previously failing reproducers are not failing anymore
 - [x] Linux x86_64 server fastdebug, `hotspot_gc_shenandoah`

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

Commit messages:
 - Fix

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

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

From stuefe at openjdk.org  Wed Sep 18 14:00:25 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Wed, 18 Sep 2024 14:00:25 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v11]
In-Reply-To: <b8u6PaStO4nt0AGnbZEkmXkzQKzXaB2c4lSiC9JWdTY=.a5805ef2-84d8-44c0-9dc0-3e90da3460aa@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <DUgk6HT_Zk5KnbmAd_HzrJi4B8D1J-uuoAGzReWyI8s=.6c04f90a-bf1d-49af-a31d-5224973952d4@github.com>
 <b8u6PaStO4nt0AGnbZEkmXkzQKzXaB2c4lSiC9JWdTY=.a5805ef2-84d8-44c0-9dc0-3e90da3460aa@github.com>
Message-ID: <m9Xj-C2ZuCBJfaOrr8zH59Ny5LDERRs-Lw5oVzDGvII=.daaae9b4-b1a3-491c-a5d0-9e327443e3bd@github.com>

On Wed, 11 Sep 2024 12:27:14 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix FullGCForwarding initialization
>
> src/hotspot/share/memory/classLoaderMetaspace.cpp line 87:
> 
>> 85:         klass_alignment_words,
>> 86:         "class arena");
>> 87:   }
> 
> As per my comment in the header file, change the code to this:
> 
> ```c++
> if (class_context != nullptr) {
>   // ... Same as in PR
> } else {
>   _class_space_arena = _non_class_space_arena;
> }

Rather not, see reasoning under https://github.com/openjdk/jdk/pull/20677/files#r1754330432

> src/hotspot/share/memory/classLoaderMetaspace.cpp line 118:
> 
>> 116: #ifdef ASSERT
>> 117:   if (result.is_nonempty()) {
>> 118:     const bool in_class_arena = class_space_arena() != nullptr ? class_space_arena()->contains(result) : false;
> 
> Unnecessary nullptr check if you take my suggestion, or you should switch to `have_class_space_arena`.

See reasoning under https://github.com/openjdk/jdk/pull/20677/files#r1754335269

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1765113297
PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1765113850

From cjplummer at openjdk.org  Wed Sep 18 16:41:20 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 18 Sep 2024 16:41:20 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v6]
In-Reply-To: <kUw1IOXnjaF1IqloewVZ8vlWvB2qGcSCSgPFCUtK6L0=.997c885c-48b1-4c1c-9c06-4d2eacaf86ea@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <BGmZ04yibLn_KtPyQrA3sQv5OtMonrcDy3aN0vAj8NA=.5de6cae3-3a05-4a74-a15c-aade4176bdeb@github.com>
 <Og4I5G3w51d7zF27JawLM9pm_XpHwijYt3lJZ4hpeWQ=.fd974e82-2ce0-4ebd-b49e-108ab87690a9@github.com>
 <S-95OBPOZb6GfBEUIDtHxCB4hTFPB2uNf5YmwMerGcE=.83afc323-883e-4ae0-8d10-fe7030cddb33@github.com>
 <ZnddOJnCLP0HABu3ymeWaAvcJNd3mKz8AhFwOtUAYW8=.f534bbd8-c222-4cd7-b6a9-3d6fd644c5e1@github.com>
 <SKA53xBzGbvMWiQxBtEYG9QB2KqZOKEBMzJzbQb_Zr8=.0cd24aa4-3aed-46e6-9092-bbc4b926bb42@github.com>
 <xyQ56u8rEyLnbVv9iP23zziwfEkc0v9bm1MGVQ8BUHY=.352e102f-41d3-4ef6-86d2-2ebc998671d1@github.com>
 <kUw1IOXnjaF1IqloewVZ8vlWvB2qGcSCSgPFCUtK6L0=.997c885c-48b1-4c1c-9c06-4d2eacaf86ea@github.com>
Message-ID: <N6Anv99FjOg7Ebitb2vL8NVA5-dv0gEzLduMfQz7hmc=.eae44a47-a460-4a6a-845b-4c02681ebb87@github.com>

On Wed, 18 Sep 2024 12:35:28 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> Thinking about this a bit more, maybe _mark needs to be a MetadataField rather than CInt. This is a kind of odd situation. Basically we have a CInt field that is more than just simple bits used as flags or small integers. It also gets you to the Klass*. Possibly SA should treat _mark is two separate fields; one that remains a CInt as it currently is and another that treats it as an encoded Klass* like the NarrowKlassField case.
>
> Do you think this needs to be addressed before integration? And if so, could you help with implementation? Or could we do it after intergration? Then please file a follow-up issue.

Ok. I filed [JDK-8340396](https://bugs.openjdk.org/browse/JDK-8340396).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1765387764

From wkemper at openjdk.org  Wed Sep 18 16:45:58 2024
From: wkemper at openjdk.org (William Kemper)
Date: Wed, 18 Sep 2024 16:45:58 GMT
Subject: RFR: 8340395: GenShen: Remove unnecessary check on card barrier flag
Message-ID: <0HL_tPWDn_ZkwY0syBqXh2BEsZ-3kLZIOESBUZnRJDQ=.d1a78947-5aa1-43d6-9b3f-178ffd48f9b6@github.com>

PLABs will only be non-null in the generational mode, so we do not need to check the mode before checking if a PLAB is non-null.

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

Commit messages:
 - Remove unnecessary mode check

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

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

From wkemper at openjdk.org  Wed Sep 18 20:29:41 2024
From: wkemper at openjdk.org (William Kemper)
Date: Wed, 18 Sep 2024 20:29:41 GMT
Subject: RFR: Merge openjdk/jdk:master [v2]
In-Reply-To: <hS4FmVLXJUDz0GxkTfuhAkgzNl3JshEwg5RrnZFplrE=.afc12e77-8ea1-4f6b-80b6-24e8cce28ba2@github.com>
References: <hS4FmVLXJUDz0GxkTfuhAkgzNl3JshEwg5RrnZFplrE=.afc12e77-8ea1-4f6b-80b6-24e8cce28ba2@github.com>
Message-ID: <z54Xk3tqe1V77wc9Q3oA3cFfNRqaMHR44GirgNM-_jo=.21eb6a72-c787-4830-81f7-6e539deb26f0@github.com>

> Merges tag jdk-24+14

William Kemper has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase.

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

Changes:
  - all: https://git.openjdk.org/shenandoah/pull/494/files
  - new: https://git.openjdk.org/shenandoah/pull/494/files/28de44da..28de44da

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

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

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

From ysr at openjdk.org  Wed Sep 18 20:47:09 2024
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Wed, 18 Sep 2024 20:47:09 GMT
Subject: RFR: 8340395: GenShen: Remove unnecessary check on card barrier
 flag
In-Reply-To: <0HL_tPWDn_ZkwY0syBqXh2BEsZ-3kLZIOESBUZnRJDQ=.d1a78947-5aa1-43d6-9b3f-178ffd48f9b6@github.com>
References: <0HL_tPWDn_ZkwY0syBqXh2BEsZ-3kLZIOESBUZnRJDQ=.d1a78947-5aa1-43d6-9b3f-178ffd48f9b6@github.com>
Message-ID: <f_qUK-gu82SAxkqpBXuegZHgEdHc4knqd8XmKFHJmpY=.309e190c-5b00-47be-b720-9883875a41e9@github.com>

On Wed, 18 Sep 2024 16:41:04 GMT, William Kemper <wkemper at openjdk.org> wrote:

> PLABs will only be non-null in the generational mode, so we do not need to check the mode before checking if a PLAB is non-null.

Marked as reviewed by ysr (Committer).

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

PR Review: https://git.openjdk.org/shenandoah/pull/501#pullrequestreview-2313765066

From wkemper at openjdk.org  Wed Sep 18 20:54:56 2024
From: wkemper at openjdk.org (William Kemper)
Date: Wed, 18 Sep 2024 20:54:56 GMT
Subject: Integrated: 8340395: GenShen: Remove unnecessary check on card barrier
 flag
In-Reply-To: <0HL_tPWDn_ZkwY0syBqXh2BEsZ-3kLZIOESBUZnRJDQ=.d1a78947-5aa1-43d6-9b3f-178ffd48f9b6@github.com>
References: <0HL_tPWDn_ZkwY0syBqXh2BEsZ-3kLZIOESBUZnRJDQ=.d1a78947-5aa1-43d6-9b3f-178ffd48f9b6@github.com>
Message-ID: <Wh3q_UL5ggrm0ljqqhlqvNDuDNHGblFHKosTccwHr5U=.e47a2d82-3a82-4378-8995-3a68fd6348d5@github.com>

On Wed, 18 Sep 2024 16:41:04 GMT, William Kemper <wkemper at openjdk.org> wrote:

> PLABs will only be non-null in the generational mode, so we do not need to check the mode before checking if a PLAB is non-null.

This pull request has now been integrated.

Changeset: e11a68f8
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.org/shenandoah/commit/e11a68f8168675ce3ddced82860b9b3d288707df
Stats:     5 lines in 1 file changed: 0 ins; 1 del; 4 mod

8340395: GenShen: Remove unnecessary check on card barrier flag

Reviewed-by: ysr

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

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

From wkemper at openjdk.org  Wed Sep 18 21:09:19 2024
From: wkemper at openjdk.org (William Kemper)
Date: Wed, 18 Sep 2024 21:09:19 GMT
Subject: RFR: 8340400: Shenandoah: Whitebox breakpoint GC requests may cause
 assertions
Message-ID: <eFIBip-WT-4JsLJIJ9F-L66700DZjmakU3P4ZRcWjL0=.712ae3a2-65c6-4f78-a2f5-ab8a92a8aa3a@github.com>

When a test requests a concurrent GC breakpoint, the calling thread arranges for itself to block until the concurrent GC thread notifies it that the GC has reached the requested breakpoint (phase). The code that handles the whitebox breakpoint request should therefore not block the caller. An attempt was made to do this, but the request just has the caller thread run in a busy loop without waiting. What's more, this loop resets the requested gc cause on every iteration, which may lead to gc cycles with a wb_breakpoint cause, but no breakpoint set - which violates assertions.

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

Commit messages:
 - Do not block whitebox breakpoint requests for gc

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

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

From coleenp at openjdk.org  Thu Sep 19 00:04:45 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 19 Sep 2024 00:04:45 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v21]
In-Reply-To: <TCFshDmOrJjN0zTh1X9BGEa_rczyMqRbyDIiYsFr_5I=.ea051371-4c86-461e-8721-83b32caf808f@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <TCFshDmOrJjN0zTh1X9BGEa_rczyMqRbyDIiYsFr_5I=.ea051371-4c86-461e-8721-83b32caf808f@github.com>
Message-ID: <DDy_r4_vlMDIhKmbAYCyQj4Uu43soArfL9tAJoDX9-I=.b14baeb8-a7ef-4144-8a9c-de8d733e1c4d@github.com>

On Wed, 18 Sep 2024 13:23:44 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> This is the main body of the JEP 450: Compact Object Headers (Experimental).
>> 
>> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing.
>> 
>> Main changes:
>>  - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers.
>>  - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded.
>>  - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops).
>>  - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all).
>>  - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16).
>>  - Arrays will now store their length at offset 8.
>>  - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _co...
>
> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JVMCI support

src/hotspot/share/oops/compressedKlass.cpp line 242:

> 240:   } else {
> 241: 
> 242:     // Traditional (non-compact) header mode)

Extra )

src/hotspot/share/oops/compressedKlass.hpp line 175:

> 173:   //   5b) if CDS=off: Calls initialize() - here, we have more freedom and, if we want, can choose an encoding
> 174:   //       base that differs from the reservation base from step (4). That allows us, e.g., to later use
> 175:   //       zero-based encoding.

Not for this but is there really any benefit for zero based encoding for klass ids?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1765888065
PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1765889975

From coleenp at openjdk.org  Thu Sep 19 00:04:46 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 19 Sep 2024 00:04:46 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v9]
In-Reply-To: <BNQiyA0NCBO-oFZU4Nz3yvaMxDzICFxfqDKWt4wCL_U=.9405414d-f961-4168-8d26-ef5f58069161@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <6Rant6SjxpFIHHWNthWc_plOdnGpWPvqj3rxRe144po=.bcdbad7a-e93a-41a3-b958-6ae602c7e083@github.com>
 <NR6CKOtdUaVarB7hiAUIAsIMe03qiTQr5VcEOWGt8mA=.164efc10-f0ff-4ddf-80b8-c56599c0ba7d@github.com>
 <BNQiyA0NCBO-oFZU4Nz3yvaMxDzICFxfqDKWt4wCL_U=.9405414d-f961-4168-8d26-ef5f58069161@github.com>
Message-ID: <igBchd3diNsHdnQwZS2sj4tjaKejOq4f4EZovOmpmRQ=.abf79fee-9592-4555-ac01-de0170665ae4@github.com>

On Wed, 18 Sep 2024 12:56:16 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> src/hotspot/share/oops/oop.inline.hpp line 90:
>> 
>>> 88:   } else {
>>> 89:     return markWord::prototype();
>>> 90:   }
>> 
>> Could this be unconditional since prototoype_header is initialized for all Klasses?
>
> yes, but there is ongoing effort (at Oracle) to get rid of ```Klass::_prototype_header``` altogether. Let's wait for that and see how it looks then.

Yes, I saw that patch.  I'm not sure I like the idea of cpu dependent code also doing the encoding.  There were some C2 changes related to it that I didn't understand if that scheme required them.  I don't see the down side to having the prototype header pre-encoded in the markWord.  Seems simpler.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1765893566

From kdnilsen at openjdk.org  Thu Sep 19 00:06:41 2024
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Thu, 19 Sep 2024 00:06:41 GMT
Subject: RFR: 8339960: GenShen: Fix inconsistencies in generational
 Shenandoah behavior [v4]
In-Reply-To: <iC_hPGmUdI86hXwB8zZ0TUY18L7lPU1HweCLpEjoEo8=.90c27500-49a4-4ed8-9861-e37c0248ba0c@github.com>
References: <iC_hPGmUdI86hXwB8zZ0TUY18L7lPU1HweCLpEjoEo8=.90c27500-49a4-4ed8-9861-e37c0248ba0c@github.com>
Message-ID: <Aa-kypYIlHj-KvkRii7UphPE4o39_wKr7UyipSYkuWE=.2ab24c6f-3d08-4fa5-80b7-e0c029bb9509@github.com>

> This pull request contains a backport of commit 1a7d597d from the openjdk/shenandoah repository.
> 
> The commit being backported was authored by Kelvin Nilsen on 13 Sep 2024 and was reviewed by William Kemper.

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

  add comments to ProblemList.txt

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

Changes:
  - all: https://git.openjdk.org/shenandoah-jdk21u/pull/90/files
  - new: https://git.openjdk.org/shenandoah-jdk21u/pull/90/files/7bf48357..4791a570

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

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

PR: https://git.openjdk.org/shenandoah-jdk21u/pull/90

From zgu at openjdk.org  Thu Sep 19 00:40:21 2024
From: zgu at openjdk.org (Zhengyu Gu)
Date: Thu, 19 Sep 2024 00:40:21 GMT
Subject: RFR: 8340408: Shenandoah: Remove redundant task stats printing code in
 ShenandoahTaskQueue
Message-ID: <6PiT6kRNGaQjkJTNknVTqMV14SyYXwFosAz9Ts3Emfk=.46c01286-6733-424c-a0d6-e6ff8aa4726c@github.com>

[JDK-8280397](https://bugs.openjdk.org/browse/JDK-8280397) made the code redundant. 

Adopt shared implementation.

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

Commit messages:
 - 8340408: Shenandoah: Remove redundant task stats printing code in ShenandoahTaskQueue

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

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

From duke at openjdk.org  Thu Sep 19 01:31:06 2024
From: duke at openjdk.org (duke)
Date: Thu, 19 Sep 2024 01:31:06 GMT
Subject: RFR: 8339643: Port JEP 404 to RISC-V [v4]
In-Reply-To: <AFl8f2VD_LyEAlgHcNu6Yc8j0o20bDm4XUPYjzNxeVY=.bac34882-5b54-4b6b-9325-ee0c3d0624f5@github.com>
References: <J3I-KZdj2aYAEN7cFFDkuZEpp6WBM7AFaikL14CDdWM=.5f1201e3-3ca2-426e-b6ce-a4bd9aa9a879@github.com>
 <AFl8f2VD_LyEAlgHcNu6Yc8j0o20bDm4XUPYjzNxeVY=.bac34882-5b54-4b6b-9325-ee0c3d0624f5@github.com>
Message-ID: <4PuFUp-Qkfb7zt53xm6lawJ3zYleRUZIEtxXD-vh4PU=.eeecc39c-4bc3-47fb-9188-6e041a1b7490@github.com>

On Wed, 18 Sep 2024 03:17:03 GMT, Fei Yang <fyang at openjdk.org> wrote:

>> The riscv64 implementation of [JDK-8337511](https://bugs.openjdk.org/browse/JDK-8337511) Implement JEP-404: Generational Shenandoah (Experimental).
>> This is mainly adapted from the changes in aarch64.
>> 
>> Testing
>> - [x] Gtest (release & fastdebug)
>> - [x] hotspot_gc_shenandoah (release & fastdebug)
>
> Fei Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improve ShenandoahBarrierSetAssembler::store_check

@RealFYang 
Your change (at version 53ee41c2aa950d939a82d42aa554515085d593de) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/shenandoah/pull/493#issuecomment-2359731340

From stefank at openjdk.org  Thu Sep 19 05:06:51 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Thu, 19 Sep 2024 05:06:51 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v9]
In-Reply-To: <igBchd3diNsHdnQwZS2sj4tjaKejOq4f4EZovOmpmRQ=.abf79fee-9592-4555-ac01-de0170665ae4@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <6Rant6SjxpFIHHWNthWc_plOdnGpWPvqj3rxRe144po=.bcdbad7a-e93a-41a3-b958-6ae602c7e083@github.com>
 <NR6CKOtdUaVarB7hiAUIAsIMe03qiTQr5VcEOWGt8mA=.164efc10-f0ff-4ddf-80b8-c56599c0ba7d@github.com>
 <BNQiyA0NCBO-oFZU4Nz3yvaMxDzICFxfqDKWt4wCL_U=.9405414d-f961-4168-8d26-ef5f58069161@github.com>
 <igBchd3diNsHdnQwZS2sj4tjaKejOq4f4EZovOmpmRQ=.abf79fee-9592-4555-ac01-de0170665ae4@github.com>
Message-ID: <BkuKSFHleaF8I2tWCDIC-rGlWnfGhbK1zQ6CLlB-rVE=.9c7976e3-b0e9-4356-8d4b-d880aa30bffa@github.com>

On Wed, 18 Sep 2024 23:59:39 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> yes, but there is ongoing effort (at Oracle) to get rid of ```Klass::_prototype_header``` altogether. Let's wait for that and see how it looks then.
>
> Yes, I saw that patch.  I'm not sure I like the idea of cpu dependent code also doing the encoding.  There were some C2 changes related to it that I didn't understand if that scheme required them.  I don't see the down side to having the prototype header pre-encoded in the markWord.  Seems simpler.

We already have a cpu dependent code for both C1 and the interpreter. Adding cpu dependent code to C2 doesn't make it significantly worse. My latest patch also refactors the code so that C1, interpreter, and C2 all calls into shared functions in the macro assembler.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1766163092

From stefank at openjdk.org  Thu Sep 19 05:53:48 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Thu, 19 Sep 2024 05:53:48 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v21]
In-Reply-To: <TCFshDmOrJjN0zTh1X9BGEa_rczyMqRbyDIiYsFr_5I=.ea051371-4c86-461e-8721-83b32caf808f@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <TCFshDmOrJjN0zTh1X9BGEa_rczyMqRbyDIiYsFr_5I=.ea051371-4c86-461e-8721-83b32caf808f@github.com>
Message-ID: <qPL-XuWVkfNYFmfYatyQZwbHismNzW_jXdvkDvIiVNc=.d4fd26a8-f509-494a-bd3d-0c6f37ba5269@github.com>

On Wed, 18 Sep 2024 13:23:44 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> This is the main body of the JEP 450: Compact Object Headers (Experimental).
>> 
>> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing.
>> 
>> Main changes:
>>  - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers.
>>  - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded.
>>  - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops).
>>  - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all).
>>  - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16).
>>  - Arrays will now store their length at offset 8.
>>  - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _co...
>
> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JVMCI support

src/hotspot/share/gc/parallel/psParallelCompact.cpp line 787:

> 785:     // The gap is always equal to min-fill-size, so nothing to do.
> 786:     return;
> 787:   }

Reading the comment, it is not obvious that this is correct if you set MinObjectAlignment to something larger than the default value:

void PSParallelCompact::fill_dense_prefix_end(SpaceId id) {
  // Comparing two sizes to decide if filling is required:
  //
  // The size of the filler (min-obj-size) is 2 heap words with the default
  // MinObjAlignment, since both markword and klass take 1 heap word.
  //
  // The size of the gap (if any) right before dense-prefix-end is
  // MinObjAlignment.
  //
  // Need to fill in the gap only if it's smaller than min-obj-size, and the
  // filler obj will extend to next region.

  // Note: If min-fill-size decreases to 1, this whole method becomes redundant.
  if (UseCompactObjectHeaders) {
    // The gap is always equal to min-fill-size, so nothing to do.
    return;
  }
  assert(CollectedHeap::min_fill_size() >= 2, "inv");

src/hotspot/share/oops/compressedKlass.cpp line 231:

> 229:     // The reason is that we want to avoid, if possible, shifts larger than
> 230:     // a cacheline size.
> 231:     _base = addr;

Why is this important?

src/hotspot/share/oops/compressedKlass.hpp line 261:

> 259:   }
> 260: 
> 261: };

Missing blank line before `#endif`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1766185665
PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1766192688
PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1766193355

From stefank at openjdk.org  Thu Sep 19 05:53:49 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Thu, 19 Sep 2024 05:53:49 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v21]
In-Reply-To: <qPL-XuWVkfNYFmfYatyQZwbHismNzW_jXdvkDvIiVNc=.d4fd26a8-f509-494a-bd3d-0c6f37ba5269@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <TCFshDmOrJjN0zTh1X9BGEa_rczyMqRbyDIiYsFr_5I=.ea051371-4c86-461e-8721-83b32caf808f@github.com>
 <qPL-XuWVkfNYFmfYatyQZwbHismNzW_jXdvkDvIiVNc=.d4fd26a8-f509-494a-bd3d-0c6f37ba5269@github.com>
Message-ID: <-UEFgAIQjGBginN0JRoyuwwJLmDssUEQGE_tCP-tRkw=.01ef3f37-01fa-4931-b4f3-571d21252bbd@github.com>

On Thu, 19 Sep 2024 05:35:34 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   JVMCI support
>
> src/hotspot/share/gc/parallel/psParallelCompact.cpp line 787:
> 
>> 785:     // The gap is always equal to min-fill-size, so nothing to do.
>> 786:     return;
>> 787:   }
> 
> Reading the comment, it is not obvious that this is correct if you set MinObjectAlignment to something larger than the default value:
> 
> void PSParallelCompact::fill_dense_prefix_end(SpaceId id) {
>   // Comparing two sizes to decide if filling is required:
>   //
>   // The size of the filler (min-obj-size) is 2 heap words with the default
>   // MinObjAlignment, since both markword and klass take 1 heap word.
>   //
>   // The size of the gap (if any) right before dense-prefix-end is
>   // MinObjAlignment.
>   //
>   // Need to fill in the gap only if it's smaller than min-obj-size, and the
>   // filler obj will extend to next region.
> 
>   // Note: If min-fill-size decreases to 1, this whole method becomes redundant.
>   if (UseCompactObjectHeaders) {
>     // The gap is always equal to min-fill-size, so nothing to do.
>     return;
>   }
>   assert(CollectedHeap::min_fill_size() >= 2, "inv");

Style note: The added code is inserted between a comment and the code that the comment refers to. It would be nice to tidy this up.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1766186545

From shade at openjdk.org  Thu Sep 19 05:58:38 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 19 Sep 2024 05:58:38 GMT
Subject: RFR: 8340183: Shenandoah: Incorrect match for clone barrier in
 is_gc_barrier_node
In-Reply-To: <lMJ7zz1QZt3FMIqVLhEpYe6aqMc_uqU_d0P2mWQI4IY=.136a8eb3-b7ae-43f4-b268-5f7a6d189e09@github.com>
References: <lMJ7zz1QZt3FMIqVLhEpYe6aqMc_uqU_d0P2mWQI4IY=.136a8eb3-b7ae-43f4-b268-5f7a6d189e09@github.com>
Message-ID: <pYs0mZTeChFp6f7DfK1cU45Bx4-PM3ddUJxqsgFK-TA=.e062b4d5-d26e-409a-ad58-91a6addfb30d@github.com>

On Mon, 16 Sep 2024 10:35:15 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> The name of the call we emit is "shenandoah_clone":
> https://github.com/openjdk/jdk/blob/545951889c1ea68646be600decaf2bf4c049600b/src/hotspot/share/gc/shenandoah/c2/shenandoahBarrierSetC2.cpp#L806
> 
> ...yet we test for "shenandoah_clone_barrier" here:
> https://github.com/openjdk/jdk/blob/545951889c1ea68646be600decaf2bf4c049600b/src/hotspot/share/gc/shenandoah/c2/shenandoahBarrierSetC2.cpp#L688
> 
> I think we are better off polling the call target instead of relying on call name. This change also eliminates `shenandoah_cas_obj` matcher, for which we do not have the emitted call ever since we started doing CAS expansions inline.
> 
> Additional testing:
>  - [x] Linux x86_64 server fastdebug, `hotspot_gc_shenandoah`
>  - [ ] Linux x86_64 server fastdebug, `all` with `-XX:+UseShenandoahGC`

Need another review here. @rkennke, maybe?

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

PR Comment: https://git.openjdk.org/jdk/pull/21014#issuecomment-2360040048

From shade at openjdk.org  Thu Sep 19 08:31:35 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 19 Sep 2024 08:31:35 GMT
Subject: RFR: 8340408: Shenandoah: Remove redundant task stats printing
 code in ShenandoahTaskQueue
In-Reply-To: <6PiT6kRNGaQjkJTNknVTqMV14SyYXwFosAz9Ts3Emfk=.46c01286-6733-424c-a0d6-e6ff8aa4726c@github.com>
References: <6PiT6kRNGaQjkJTNknVTqMV14SyYXwFosAz9Ts3Emfk=.46c01286-6733-424c-a0d6-e6ff8aa4726c@github.com>
Message-ID: <1m4c0G4GgF_uHGxwKvqmilfGjIv1qqsvhCZX3VfKvbo=.5628bbd0-f0c2-4efd-a9f0-c43c0a8ccc64@github.com>

On Thu, 19 Sep 2024 00:33:04 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> [JDK-8280397](https://bugs.openjdk.org/browse/JDK-8280397) made the code redundant. 
> 
> Adopt shared implementation.

Ah, cool. Thanks.

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

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21077#pullrequestreview-2314809810

From shade at openjdk.org  Thu Sep 19 08:45:36 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 19 Sep 2024 08:45:36 GMT
Subject: RFR: 8340408: Shenandoah: Remove redundant task stats printing
 code in ShenandoahTaskQueue
In-Reply-To: <6PiT6kRNGaQjkJTNknVTqMV14SyYXwFosAz9Ts3Emfk=.46c01286-6733-424c-a0d6-e6ff8aa4726c@github.com>
References: <6PiT6kRNGaQjkJTNknVTqMV14SyYXwFosAz9Ts3Emfk=.46c01286-6733-424c-a0d6-e6ff8aa4726c@github.com>
Message-ID: <8ML4TaXKk8S8zA_MiOfZyniZqVP7uyQMaY2SRw5Nsow=.490b258d-3731-4fca-bfb1-07439da5a1a3@github.com>

On Thu, 19 Sep 2024 00:33:04 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> [JDK-8280397](https://bugs.openjdk.org/browse/JDK-8280397) made the code redundant. 
> 
> Adopt shared implementation.

@earthling-amzn, @kdnilsen, @ysramakrishna -- your turn :)

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

PR Comment: https://git.openjdk.org/jdk/pull/21077#issuecomment-2360383565

From mli at openjdk.org  Thu Sep 19 10:32:50 2024
From: mli at openjdk.org (Hamlin Li)
Date: Thu, 19 Sep 2024 10:32:50 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v21]
In-Reply-To: <TCFshDmOrJjN0zTh1X9BGEa_rczyMqRbyDIiYsFr_5I=.ea051371-4c86-461e-8721-83b32caf808f@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <TCFshDmOrJjN0zTh1X9BGEa_rczyMqRbyDIiYsFr_5I=.ea051371-4c86-461e-8721-83b32caf808f@github.com>
Message-ID: <pOeT98rm-lCu2o8_7HzKpkA7iC800HUxgaJMNTD6K5Q=.03ff309e-c28c-4945-ad71-4462ed1b7f67@github.com>

On Wed, 18 Sep 2024 13:23:44 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> This is the main body of the JEP 450: Compact Object Headers (Experimental).
>> 
>> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing.
>> 
>> Main changes:
>>  - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers.
>>  - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded.
>>  - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops).
>>  - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all).
>>  - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16).
>>  - Arrays will now store their length at offset 8.
>>  - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _co...
>
> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JVMCI support

src/hotspot/cpu/aarch64/c1_LIRAssembler_aarch64.cpp line 2529:

> 2527:     }
> 2528:     __ decode_klass_not_null(result);
> 2529:   } else {

Could this if/else block be replaced with a simple call of load_klass(...)?

src/hotspot/cpu/x86/c1_LIRAssembler_x86.cpp line 3522:

> 3520:   {
> 3521:     __ movptr(result, Address(obj, oopDesc::klass_offset_in_bytes()));
> 3522:   }

Could this if/else block be replaced with a simple call of load_klass(...)?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1766587136
PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1766582255

From rcastanedalo at openjdk.org  Thu Sep 19 11:02:50 2024
From: rcastanedalo at openjdk.org (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Thu, 19 Sep 2024 11:02:50 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v15]
In-Reply-To: <mX0ou3n5MzR_tt1nnuLy-cFYj_85cfCK-LHR6KZ-Uwk=.4fca751d-a06a-4c2d-8bb2-eba51d435ef2@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <CCz9B03dUxzua_YHk9-nyyHS_FTa6axwrwYjACcz4Y0=.6052f53c-9ddb-4868-a817-aff4276a2b6a@github.com>
 <mX0ou3n5MzR_tt1nnuLy-cFYj_85cfCK-LHR6KZ-Uwk=.4fca751d-a06a-4c2d-8bb2-eba51d435ef2@github.com>
Message-ID: <gPJJkZqhS0S4vgAqP_FoUfNEIAfw_f53uU_kID1N1P8=.a4433f1f-3b2c-4c00-a074-ab650b81b38b@github.com>

On Mon, 16 Sep 2024 08:04:43 GMT, Roberto Casta?eda Lozano <rcastanedalo at openjdk.org> wrote:

> I agree that this is the simplest and least intrusive way of getting klass loading working in C2 for this experimental version of the feature. However, the approach seems brittle and error-prone, and it may be hard to maintain in the long run. Therefore, I think that a more principled and robust modeling will be needed, after this PR is integrated, in preparation for the non-experimental version.

What do you think about this @rkennke? Do you agree on an alternative modeling of klass loading in C2 (without any reliance on `oopDesc::klass_offset_in_bytes()`) being a pre-condition for a future, non-experimental version of compact headers?

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

PR Comment: https://git.openjdk.org/jdk/pull/20677#issuecomment-2360673405

From yzheng at openjdk.org  Thu Sep 19 11:12:49 2024
From: yzheng at openjdk.org (Yudi Zheng)
Date: Thu, 19 Sep 2024 11:12:49 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v9]
In-Reply-To: <BkuKSFHleaF8I2tWCDIC-rGlWnfGhbK1zQ6CLlB-rVE=.9c7976e3-b0e9-4356-8d4b-d880aa30bffa@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <6Rant6SjxpFIHHWNthWc_plOdnGpWPvqj3rxRe144po=.bcdbad7a-e93a-41a3-b958-6ae602c7e083@github.com>
 <NR6CKOtdUaVarB7hiAUIAsIMe03qiTQr5VcEOWGt8mA=.164efc10-f0ff-4ddf-80b8-c56599c0ba7d@github.com>
 <BNQiyA0NCBO-oFZU4Nz3yvaMxDzICFxfqDKWt4wCL_U=.9405414d-f961-4168-8d26-ef5f58069161@github.com>
 <igBchd3diNsHdnQwZS2sj4tjaKejOq4f4EZovOmpmRQ=.abf79fee-9592-4555-ac01-de0170665ae4@github.com>
 <BkuKSFHleaF8I2tWCDIC-rGlWnfGhbK1zQ6CLlB-rVE=.9c7976e3-b0e9-4356-8d4b-d880aa30bffa@github.com>
Message-ID: <XBxfeOy1JiEESlmCA3u1_zYc7ss5dUkSzYdJSI1XJJo=.948eb061-5051-4781-a3f0-60daaf58419d@github.com>

On Thu, 19 Sep 2024 05:03:42 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> Yes, I saw that patch.  I'm not sure I like the idea of cpu dependent code also doing the encoding.  There were some C2 changes related to it that I didn't understand if that scheme required them.  I don't see the down side to having the prototype header pre-encoded in the markWord.  Seems simpler.
>
> We already have a cpu dependent code for both C1 and the interpreter. Adding cpu dependent code to C2 doesn't make it significantly worse. My latest patch also refactors the code so that C1, interpreter, and C2 all calls into shared functions in the macro assembler.

Could you please point me to the C2 change? Is it going to be integrated in this PR? We in Graal have not yet adopted `Klass::_prototype_header` and will hold if you decide to get rid of it

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1766642585

From stuefe at openjdk.org  Thu Sep 19 11:39:50 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 19 Sep 2024 11:39:50 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v21]
In-Reply-To: <DDy_r4_vlMDIhKmbAYCyQj4Uu43soArfL9tAJoDX9-I=.b14baeb8-a7ef-4144-8a9c-de8d733e1c4d@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <TCFshDmOrJjN0zTh1X9BGEa_rczyMqRbyDIiYsFr_5I=.ea051371-4c86-461e-8721-83b32caf808f@github.com>
 <DDy_r4_vlMDIhKmbAYCyQj4Uu43soArfL9tAJoDX9-I=.b14baeb8-a7ef-4144-8a9c-de8d733e1c4d@github.com>
Message-ID: <mN9d7VoyWJaDzLQFV0fcTDlYGsLuRpVDGU1Q03N4W5M=.182fb997-ffb1-4445-a9cb-54abf5daa309@github.com>

On Wed, 18 Sep 2024 23:49:34 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   JVMCI support
>
> src/hotspot/share/oops/compressedKlass.cpp line 242:
> 
>> 240:   } else {
>> 241: 
>> 242:     // Traditional (non-compact) header mode)
> 
> Extra )

Will fix

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1766676702

From rkennke at openjdk.org  Thu Sep 19 11:52:34 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Thu, 19 Sep 2024 11:52:34 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v22]
In-Reply-To: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
Message-ID: <0mWQW50x4UNwdsRE94w3rZVGnppxQeR9fbe4eUrAGtM=.cca89805-ca82-4605-bc11-4f9ac53d2b90@github.com>

> This is the main body of the JEP 450: Compact Object Headers (Experimental).
> 
> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing.
> 
> Main changes:
>  - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers.
>  - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded.
>  - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops).
>  - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all).
>  - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16).
>  - Arrays will now store their length at offset 8.
>  - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _coh variants of CDS archiv...

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

  Simplify LIR_Assembler::emit_load_klass()

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20677/files
  - new: https://git.openjdk.org/jdk/pull/20677/files/9ad2e62f..b25a4b69

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20677&range=21
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20677&range=20-21

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

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

From rkennke at openjdk.org  Thu Sep 19 11:52:34 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Thu, 19 Sep 2024 11:52:34 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v15]
In-Reply-To: <gPJJkZqhS0S4vgAqP_FoUfNEIAfw_f53uU_kID1N1P8=.a4433f1f-3b2c-4c00-a074-ab650b81b38b@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <CCz9B03dUxzua_YHk9-nyyHS_FTa6axwrwYjACcz4Y0=.6052f53c-9ddb-4868-a817-aff4276a2b6a@github.com>
 <mX0ou3n5MzR_tt1nnuLy-cFYj_85cfCK-LHR6KZ-Uwk=.4fca751d-a06a-4c2d-8bb2-eba51d435ef2@github.com>
 <gPJJkZqhS0S4vgAqP_FoUfNEIAfw_f53uU_kID1N1P8=.a4433f1f-3b2c-4c00-a074-ab650b81b38b@github.com>
Message-ID: <kOLQ21p1NoD9_mYCqEo1W1oUjXx1ITxgMAPP_WvKJOM=.21b5935e-d183-4bda-aaf4-286ab3b4a6c4@github.com>

On Thu, 19 Sep 2024 11:00:20 GMT, Roberto Casta?eda Lozano <rcastanedalo at openjdk.org> wrote:

> > I agree that this is the simplest and least intrusive way of getting klass loading working in C2 for this experimental version of the feature. However, the approach seems brittle and error-prone, and it may be hard to maintain in the long run. Therefore, I think that a more principled and robust modeling will be needed, after this PR is integrated, in preparation for the non-experimental version.
> 
> What do you think about this @rkennke? Do you agree on an alternative modeling of klass loading in C2 (without any reliance on `oopDesc::klass_offset_in_bytes()`) being a pre-condition for a future, non-experimental version of compact headers?

Yes, that sounds like a good improvement! It'd also clean up C2 considerably - right now there are many places in C2 that rely on klass_offset_in_bytes(). Getting rid of them all would be great, but also seems like a major effort. Could you file an issue to track that future work?

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

PR Comment: https://git.openjdk.org/jdk/pull/20677#issuecomment-2360756796

From rkennke at openjdk.org  Thu Sep 19 11:52:37 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Thu, 19 Sep 2024 11:52:37 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v21]
In-Reply-To: <pOeT98rm-lCu2o8_7HzKpkA7iC800HUxgaJMNTD6K5Q=.03ff309e-c28c-4945-ad71-4462ed1b7f67@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <TCFshDmOrJjN0zTh1X9BGEa_rczyMqRbyDIiYsFr_5I=.ea051371-4c86-461e-8721-83b32caf808f@github.com>
 <pOeT98rm-lCu2o8_7HzKpkA7iC800HUxgaJMNTD6K5Q=.03ff309e-c28c-4945-ad71-4462ed1b7f67@github.com>
Message-ID: <qt6n1HsHLaG2loSXY0pzBhnSDHGp6owvMZ0cM7DXTP4=.7575154e-2d7f-41bd-beb2-40442f6154ba@github.com>

On Thu, 19 Sep 2024 10:29:11 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   JVMCI support
>
> src/hotspot/cpu/aarch64/c1_LIRAssembler_aarch64.cpp line 2529:
> 
>> 2527:     }
>> 2528:     __ decode_klass_not_null(result);
>> 2529:   } else {
> 
> Could this if/else block be replaced with a simple call of load_klass(...)?

Yes, will do.

> src/hotspot/cpu/x86/c1_LIRAssembler_x86.cpp line 3522:
> 
>> 3520:   {
>> 3521:     __ movptr(result, Address(obj, oopDesc::klass_offset_in_bytes()));
>> 3522:   }
> 
> Could this if/else block be replaced with a simple call of load_klass(...)?

Yes, will do.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1766689169
PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1766689004

From stuefe at openjdk.org  Thu Sep 19 11:52:38 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 19 Sep 2024 11:52:38 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v21]
In-Reply-To: <qPL-XuWVkfNYFmfYatyQZwbHismNzW_jXdvkDvIiVNc=.d4fd26a8-f509-494a-bd3d-0c6f37ba5269@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <TCFshDmOrJjN0zTh1X9BGEa_rczyMqRbyDIiYsFr_5I=.ea051371-4c86-461e-8721-83b32caf808f@github.com>
 <qPL-XuWVkfNYFmfYatyQZwbHismNzW_jXdvkDvIiVNc=.d4fd26a8-f509-494a-bd3d-0c6f37ba5269@github.com>
Message-ID: <spymZDxJXwseFGxL78zfn4V8qe9NpX3gifTgd_eQkiM=.d1af7cf3-b503-4c35-93bb-db00f3c4cfc8@github.com>

On Thu, 19 Sep 2024 05:44:42 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   JVMCI support
>
> src/hotspot/share/oops/compressedKlass.cpp line 231:
> 
>> 229:     // The reason is that we want to avoid, if possible, shifts larger than
>> 230:     // a cacheline size.
>> 231:     _base = addr;
> 
> Why is this important?

It lessens the cache effects of Klass hyperaligning.

> src/hotspot/share/oops/compressedKlass.hpp line 261:
> 
>> 259:   }
>> 260: 
>> 261: };
> 
> Missing blank line before `#endif`

Fixed

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1766684016
PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1766684491

From stuefe at openjdk.org  Thu Sep 19 11:52:39 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 19 Sep 2024 11:52:39 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v21]
In-Reply-To: <spymZDxJXwseFGxL78zfn4V8qe9NpX3gifTgd_eQkiM=.d1af7cf3-b503-4c35-93bb-db00f3c4cfc8@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <TCFshDmOrJjN0zTh1X9BGEa_rczyMqRbyDIiYsFr_5I=.ea051371-4c86-461e-8721-83b32caf808f@github.com>
 <qPL-XuWVkfNYFmfYatyQZwbHismNzW_jXdvkDvIiVNc=.d4fd26a8-f509-494a-bd3d-0c6f37ba5269@github.com>
 <spymZDxJXwseFGxL78zfn4V8qe9NpX3gifTgd_eQkiM=.d1af7cf3-b503-4c35-93bb-db00f3c4cfc8@github.com>
Message-ID: <U1HQ2ijNoadMNlrW_Adxkju4fM8kfAB4hn-a_gkPrnA=.7e0fee38-8534-4dcc-8aac-77d6559687c8@github.com>

On Thu, 19 Sep 2024 11:43:12 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> src/hotspot/share/oops/compressedKlass.cpp line 231:
>> 
>>> 229:     // The reason is that we want to avoid, if possible, shifts larger than
>>> 230:     // a cacheline size.
>>> 231:     _base = addr;
>> 
>> Why is this important?
>
> It lessens the cache effects of Klass hyperaligning.

Note that if we go with my KLUT proposal for post-Lilliput (the GC oop iteration improvements), this will not matter anymore and can be simplified to a fixed shift of 10.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1766688756

From stuefe at openjdk.org  Thu Sep 19 11:52:40 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 19 Sep 2024 11:52:40 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v21]
In-Reply-To: <DDy_r4_vlMDIhKmbAYCyQj4Uu43soArfL9tAJoDX9-I=.b14baeb8-a7ef-4144-8a9c-de8d733e1c4d@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <TCFshDmOrJjN0zTh1X9BGEa_rczyMqRbyDIiYsFr_5I=.ea051371-4c86-461e-8721-83b32caf808f@github.com>
 <DDy_r4_vlMDIhKmbAYCyQj4Uu43soArfL9tAJoDX9-I=.b14baeb8-a7ef-4144-8a9c-de8d733e1c4d@github.com>
Message-ID: <NrRhACMXbA72b5jdZo12kOK8euCDLSLJgRBDGRUmVoM=.ae5bbb9d-b9f5-4b89-a39d-424ecb8031f0@github.com>

On Wed, 18 Sep 2024 23:53:28 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   JVMCI support
>
> src/hotspot/share/oops/compressedKlass.hpp line 175:
> 
>> 173:   //   5b) if CDS=off: Calls initialize() - here, we have more freedom and, if we want, can choose an encoding
>> 174:   //       base that differs from the reservation base from step (4). That allows us, e.g., to later use
>> 175:   //       zero-based encoding.
> 
> Not for this but is there really any benefit for zero based encoding for klass ids?

Yes, I think so. I think the SAP Jit people investigated this when doing the PPC ports. You save at least two instructions, and possibly more, per decode op. You save code size too since you don't need to materialize the 64-bit base immediate. Especially on x64 this can mean easily 11 fewer bytes.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1766681110

From stuefe at openjdk.org  Thu Sep 19 11:52:42 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 19 Sep 2024 11:52:42 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v18]
In-Reply-To: <sXx4wxL6nlbJFQXLjN83xKY43ZZ1PyuLwk32st0Dfhg=.df5ee7f3-9c92-41d4-a80b-6e7291619a23@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <tzW1ygFfWY40OR9lB3z0gVv7H9WKJPbFCZmR0F23-_k=.de6459ea-024c-48de-a062-0136d0af0306@github.com>
 <sXx4wxL6nlbJFQXLjN83xKY43ZZ1PyuLwk32st0Dfhg=.df5ee7f3-9c92-41d4-a80b-6e7291619a23@github.com>
Message-ID: <ZFg-_gMExHPrQiClx2MKLQpk9VN-iemvFgkXxbH8JIE=.35110abe-dd9e-4d41-8d41-dda7b6eae89a@github.com>

On Tue, 17 Sep 2024 10:36:58 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> Roman Kennke has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 57 commits:
>> 
>>  - fix CompressedClassPointersEncodingScheme yet again for linux aarch64
>>  - Fixes post-8340184
>>  - Merge upstream up to and including 8340184
>>  - Merge remote-tracking branch 'origin/master' into JDK-8305895-v4
>>  - Fix  test/hotspot/jtreg/runtime/CompressedOops/CompressedClassPointersEncodingScheme.java
>>  - Fix loop on aarch64
>>  - clarify obscure assert in metasapce setup
>>  - Rework compressedklass encoding
>>  - remove stray debug output
>>  - Fixes post 8338526
>>  - ... and 47 more: https://git.openjdk.org/jdk/compare/7849f252...28a26aed
>
> test/hotspot/gtest/metaspace/test_clms.cpp line 193:
> 
>> 191: 
>> 192:       {
>> 193:         // Nonclass arena allocation.
> 
> The style in this source file isn't really up to scratch, especially *these* lines. Anyway, it's in the tests, so I'm OK with this being fixed in a follow up RFE.

Okay, will fix

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1766686807

From rkennke at openjdk.org  Thu Sep 19 11:57:52 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Thu, 19 Sep 2024 11:57:52 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v9]
In-Reply-To: <BkuKSFHleaF8I2tWCDIC-rGlWnfGhbK1zQ6CLlB-rVE=.9c7976e3-b0e9-4356-8d4b-d880aa30bffa@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <6Rant6SjxpFIHHWNthWc_plOdnGpWPvqj3rxRe144po=.bcdbad7a-e93a-41a3-b958-6ae602c7e083@github.com>
 <NR6CKOtdUaVarB7hiAUIAsIMe03qiTQr5VcEOWGt8mA=.164efc10-f0ff-4ddf-80b8-c56599c0ba7d@github.com>
 <BNQiyA0NCBO-oFZU4Nz3yvaMxDzICFxfqDKWt4wCL_U=.9405414d-f961-4168-8d26-ef5f58069161@github.com>
 <igBchd3diNsHdnQwZS2sj4tjaKejOq4f4EZovOmpmRQ=.abf79fee-9592-4555-ac01-de0170665ae4@github.com>
 <BkuKSFHleaF8I2tWCDIC-rGlWnfGhbK1zQ6CLlB-rVE=.9c7976e3-b0e9-4356-8d4b-d880aa30bffa@github.com>
Message-ID: <ubcY5Q-aPRCLmhZV9MjBfzzbs84FegDvNkHx8nwPUd0=.46503fd8-d274-4558-bd0f-cc0c4f199667@github.com>

On Thu, 19 Sep 2024 05:03:42 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> Yes, I saw that patch.  I'm not sure I like the idea of cpu dependent code also doing the encoding.  There were some C2 changes related to it that I didn't understand if that scheme required them.  I don't see the down side to having the prototype header pre-encoded in the markWord.  Seems simpler.
>
> We already have a cpu dependent code for both C1 and the interpreter. Adding cpu dependent code to C2 doesn't make it significantly worse. My latest patch also refactors the code so that C1, interpreter, and C2 all calls into shared functions in the macro assembler.

We haven't decided whether or not we will git rid of ```Klass::_prototype_header``` before intergrating this PR, or not. @stefank could point you to a WIP branch, if that's helpful.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1766697849

From rkennke at openjdk.org  Thu Sep 19 12:08:46 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Thu, 19 Sep 2024 12:08:46 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v23]
In-Reply-To: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
Message-ID: <0BrAbBTKmpqTGDrc--2znzO8t07yoqabwa6g2K05GHI=.d3c17fd5-4770-4623-8d2f-604816afc033@github.com>

> This is the main body of the JEP 450: Compact Object Headers (Experimental).
> 
> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing.
> 
> Main changes:
>  - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers.
>  - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded.
>  - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops).
>  - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all).
>  - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16).
>  - Arrays will now store their length at offset 8.
>  - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _coh variants of CDS archiv...

Roman Kennke has updated the pull request incrementally with two additional commits since the last revision:

 - Merge remote-tracking branch 'lilliput/JEP-450-temporary-fix-branch-2' into JDK-8305895-v4
 - review feedback

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20677/files
  - new: https://git.openjdk.org/jdk/pull/20677/files/b25a4b69..0d8a9236

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20677&range=22
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20677&range=21-22

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

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

From shade at openjdk.org  Thu Sep 19 12:20:39 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 19 Sep 2024 12:20:39 GMT
Subject: RFR: 8340400: Shenandoah: Whitebox breakpoint GC requests may
 cause assertions
In-Reply-To: <eFIBip-WT-4JsLJIJ9F-L66700DZjmakU3P4ZRcWjL0=.712ae3a2-65c6-4f78-a2f5-ab8a92a8aa3a@github.com>
References: <eFIBip-WT-4JsLJIJ9F-L66700DZjmakU3P4ZRcWjL0=.712ae3a2-65c6-4f78-a2f5-ab8a92a8aa3a@github.com>
Message-ID: <K7fewLuXp389LoFdjN54N4mIBRoUJZRKQqrX7f_gK8c=.0821d3a2-d978-4682-baf5-6eeee97593d7@github.com>

On Wed, 18 Sep 2024 21:02:23 GMT, William Kemper <wkemper at openjdk.org> wrote:

> When a test requests a concurrent GC breakpoint, the calling thread arranges for itself to block until the concurrent GC thread notifies it that the GC has reached the requested breakpoint (phase). The code that handles the whitebox breakpoint request should therefore not block the caller. An attempt was made to do this, but the request just has the caller thread run in a busy loop without waiting. What's more, this loop resets the requested gc cause on every iteration, which may lead to gc cycles with a wb_breakpoint cause, but no breakpoint set - which violates assertions.

Yeah, this makes sense. Any tests fail without this patch?

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

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21074#pullrequestreview-2315363086

From coleenp at openjdk.org  Thu Sep 19 12:38:48 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 19 Sep 2024 12:38:48 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v21]
In-Reply-To: <U1HQ2ijNoadMNlrW_Adxkju4fM8kfAB4hn-a_gkPrnA=.7e0fee38-8534-4dcc-8aac-77d6559687c8@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <TCFshDmOrJjN0zTh1X9BGEa_rczyMqRbyDIiYsFr_5I=.ea051371-4c86-461e-8721-83b32caf808f@github.com>
 <qPL-XuWVkfNYFmfYatyQZwbHismNzW_jXdvkDvIiVNc=.d4fd26a8-f509-494a-bd3d-0c6f37ba5269@github.com>
 <spymZDxJXwseFGxL78zfn4V8qe9NpX3gifTgd_eQkiM=.d1af7cf3-b503-4c35-93bb-db00f3c4cfc8@github.com>
 <U1HQ2ijNoadMNlrW_Adxkju4fM8kfAB4hn-a_gkPrnA=.7e0fee38-8534-4dcc-8aac-77d6559687c8@github.com>
Message-ID: <CNrcAK8SrGCzsreT3SdoxaoGaqKqGb989t-waCJUz64=.0662bccb-661f-4dc9-b8b6-24d615035261@github.com>

On Thu, 19 Sep 2024 11:47:21 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> It lessens the cache effects of Klass hyperaligning.
>
> Note that if we go with my KLUT proposal for post-Lilliput (the GC oop iteration improvements), this will not matter anymore and can be simplified to a fixed shift of 10.

Yes, please, not having this code would be really nice.  This is difficult code.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1766753081

From rcastanedalo at openjdk.org  Thu Sep 19 13:12:49 2024
From: rcastanedalo at openjdk.org (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Thu, 19 Sep 2024 13:12:49 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v15]
In-Reply-To: <kOLQ21p1NoD9_mYCqEo1W1oUjXx1ITxgMAPP_WvKJOM=.21b5935e-d183-4bda-aaf4-286ab3b4a6c4@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <CCz9B03dUxzua_YHk9-nyyHS_FTa6axwrwYjACcz4Y0=.6052f53c-9ddb-4868-a817-aff4276a2b6a@github.com>
 <mX0ou3n5MzR_tt1nnuLy-cFYj_85cfCK-LHR6KZ-Uwk=.4fca751d-a06a-4c2d-8bb2-eba51d435ef2@github.com>
 <gPJJkZqhS0S4vgAqP_FoUfNEIAfw_f53uU_kID1N1P8=.a4433f1f-3b2c-4c00-a074-ab650b81b38b@github.com>
 <kOLQ21p1NoD9_mYCqEo1W1oUjXx1ITxgMAPP_WvKJOM=.21b5935e-d183-4bda-aaf4-286ab3b4a6c4@github.com>
Message-ID: <0gatRiYQ3frDnMftpb_WaDolUwcYvBFh5hAp6jY0dzQ=.21d6518e-7217-477e-954f-69fd52eb713e@github.com>

On Thu, 19 Sep 2024 11:42:04 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> > > I agree that this is the simplest and least intrusive way of getting klass loading working in C2 for this experimental version of the feature. However, the approach seems brittle and error-prone, and it may be hard to maintain in the long run. Therefore, I think that a more principled and robust modeling will be needed, after this PR is integrated, in preparation for the non-experimental version.
> > 
> > 
> > What do you think about this @rkennke? Do you agree on an alternative modeling of klass loading in C2 (without any reliance on `oopDesc::klass_offset_in_bytes()`) being a pre-condition for a future, non-experimental version of compact headers?
> 
> Yes, that sounds like a good improvement! It'd also clean up C2 considerably - right now there are many places in C2 that rely on klass_offset_in_bytes(). Getting rid of them all would be great, but also seems like a major effort. Could you file an issue to track that future work?

Done: https://bugs.openjdk.org/browse/JDK-8340453.

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

PR Comment: https://git.openjdk.org/jdk/pull/20677#issuecomment-2360945827

From stefank at openjdk.org  Thu Sep 19 13:12:50 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Thu, 19 Sep 2024 13:12:50 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v21]
In-Reply-To: <CNrcAK8SrGCzsreT3SdoxaoGaqKqGb989t-waCJUz64=.0662bccb-661f-4dc9-b8b6-24d615035261@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <TCFshDmOrJjN0zTh1X9BGEa_rczyMqRbyDIiYsFr_5I=.ea051371-4c86-461e-8721-83b32caf808f@github.com>
 <qPL-XuWVkfNYFmfYatyQZwbHismNzW_jXdvkDvIiVNc=.d4fd26a8-f509-494a-bd3d-0c6f37ba5269@github.com>
 <spymZDxJXwseFGxL78zfn4V8qe9NpX3gifTgd_eQkiM=.d1af7cf3-b503-4c35-93bb-db00f3c4cfc8@github.com>
 <U1HQ2ijNoadMNlrW_Adxkju4fM8kfAB4hn-a_gkPrnA=.7e0fee38-8534-4dcc-8aac-77d6559687c8@github.com>
 <CNrcAK8SrGCzsreT3SdoxaoGaqKqGb989t-waCJUz64=.0662bccb-661f-4dc9-b8b6-24d615035261@github.com>
Message-ID: <YyPrYu-6p5wcUwfMQQamwoM1eGp6eUze_yC1lrc7mb0=.f1e5853b-3b6e-4460-8f57-a6f7588e513e@github.com>

On Thu, 19 Sep 2024 12:35:30 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Note that if we go with my KLUT proposal for post-Lilliput (the GC oop iteration improvements), this will not matter anymore and can be simplified to a fixed shift of 10.
>
> Yes, please, not having this code would be really nice.  This is difficult code.

Do you seen any effects of this in anything other than special-crafted micro benchmarks? I wonder if it would be good enough to hard-code this to be 10 for the first integration of Lilliput.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1766804699

From stuefe at openjdk.org  Thu Sep 19 13:37:52 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 19 Sep 2024 13:37:52 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v21]
In-Reply-To: <YyPrYu-6p5wcUwfMQQamwoM1eGp6eUze_yC1lrc7mb0=.f1e5853b-3b6e-4460-8f57-a6f7588e513e@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <TCFshDmOrJjN0zTh1X9BGEa_rczyMqRbyDIiYsFr_5I=.ea051371-4c86-461e-8721-83b32caf808f@github.com>
 <qPL-XuWVkfNYFmfYatyQZwbHismNzW_jXdvkDvIiVNc=.d4fd26a8-f509-494a-bd3d-0c6f37ba5269@github.com>
 <spymZDxJXwseFGxL78zfn4V8qe9NpX3gifTgd_eQkiM=.d1af7cf3-b503-4c35-93bb-db00f3c4cfc8@github.com>
 <U1HQ2ijNoadMNlrW_Adxkju4fM8kfAB4hn-a_gkPrnA=.7e0fee38-8534-4dcc-8aac-77d6559687c8@github.com>
 <CNrcAK8SrGCzsreT3SdoxaoGaqKqGb989t-waCJUz64=.0662bccb-661f-4dc9-b8b6-24d615035261@github.com>
 <YyPrYu-6p5wcUwfMQQamwoM1eGp6eUze_yC1lrc7mb0=.f1e5853b-3b6e-4460-8f57-a6f7588e513e@github.com>
Message-ID: <Na5LWOz_h0ZGmLcETAxDA9wYiEopgWfvNTbYAELExR8=.e30fe7a0-c766-4bb4-aebb-fc6643c832c1@github.com>

On Thu, 19 Sep 2024 13:08:43 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> Yes, please, not having this code would be really nice.  This is difficult code.
>
> Do you seen any effects of this in anything other than special-crafted micro benchmarks? I wonder if it would be good enough to hard-code this to be 10 for the first integration of Lilliput.

I will do some benchmarks

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1766848371

From kdnilsen at openjdk.org  Thu Sep 19 13:40:06 2024
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Thu, 19 Sep 2024 13:40:06 GMT
Subject: Integrated: 8339960: GenShen: Fix inconsistencies in generational
 Shenandoah behavior
In-Reply-To: <iC_hPGmUdI86hXwB8zZ0TUY18L7lPU1HweCLpEjoEo8=.90c27500-49a4-4ed8-9861-e37c0248ba0c@github.com>
References: <iC_hPGmUdI86hXwB8zZ0TUY18L7lPU1HweCLpEjoEo8=.90c27500-49a4-4ed8-9861-e37c0248ba0c@github.com>
Message-ID: <sJL_LnJOsGaXuW85LQZe1sGg2_b79se7_YLWdrTpbKE=.df49079a-eefe-445e-8d76-7b0b237ce824@github.com>

On Sat, 14 Sep 2024 00:06:19 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

> This pull request contains a backport of commit 1a7d597d from the openjdk/shenandoah repository.
> 
> The commit being backported was authored by Kelvin Nilsen on 13 Sep 2024 and was reviewed by William Kemper.

This pull request has now been integrated.

Changeset: 4e5107d5
Author:    Kelvin Nilsen <kdnilsen at openjdk.org>
URL:       https://git.openjdk.org/shenandoah-jdk21u/commit/4e5107d5bbdce838b95e04d129b667efc10a8bc0
Stats:     31 lines in 2 files changed: 22 ins; 0 del; 9 mod

8339960: GenShen: Fix inconsistencies in generational Shenandoah behavior

Reviewed-by: ysr
Backport-of: 1a7d597dad0fb3560f88f582ab760cca28cf54fd

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

PR: https://git.openjdk.org/shenandoah-jdk21u/pull/90

From wkemper at openjdk.org  Thu Sep 19 14:25:15 2024
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 19 Sep 2024 14:25:15 GMT
Subject: RFR: Merge openjdk/jdk21u-dev:master
Message-ID: <7LCHmp1lRwMox4FXtVqnHP_rYRyYuTrskm5P2iGiTHI=.6e726b08-87e6-454e-b964-ba2e11a4ddd7@github.com>

Merges tag jdk-21.0.5+8

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

Commit messages:
 - 8337622: IllegalArgumentException in java.lang.reflect.Field.get
 - 8329667: [macos] Issue with JTree related fix for JDK-8317771
 - 8339869: [21u] Test CreationTime.java fails with UnsatisfiedLinkError after 8334339

The merge commit only contains trivial merges, so no merge-specific webrevs have been generated.

Changes: https://git.openjdk.org/shenandoah-jdk21u/pull/104/files
  Stats: 228 lines in 7 files changed: 148 ins; 71 del; 9 mod
  Patch: https://git.openjdk.org/shenandoah-jdk21u/pull/104.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah-jdk21u.git pull/104/head:pull/104

PR: https://git.openjdk.org/shenandoah-jdk21u/pull/104

From stefank at openjdk.org  Thu Sep 19 14:25:52 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Thu, 19 Sep 2024 14:25:52 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v9]
In-Reply-To: <ubcY5Q-aPRCLmhZV9MjBfzzbs84FegDvNkHx8nwPUd0=.46503fd8-d274-4558-bd0f-cc0c4f199667@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <6Rant6SjxpFIHHWNthWc_plOdnGpWPvqj3rxRe144po=.bcdbad7a-e93a-41a3-b958-6ae602c7e083@github.com>
 <NR6CKOtdUaVarB7hiAUIAsIMe03qiTQr5VcEOWGt8mA=.164efc10-f0ff-4ddf-80b8-c56599c0ba7d@github.com>
 <BNQiyA0NCBO-oFZU4Nz3yvaMxDzICFxfqDKWt4wCL_U=.9405414d-f961-4168-8d26-ef5f58069161@github.com>
 <igBchd3diNsHdnQwZS2sj4tjaKejOq4f4EZovOmpmRQ=.abf79fee-9592-4555-ac01-de0170665ae4@github.com>
 <BkuKSFHleaF8I2tWCDIC-rGlWnfGhbK1zQ6CLlB-rVE=.9c7976e3-b0e9-4356-8d4b-d880aa30bffa@github.com>
 <ubcY5Q-aPRCLmhZV9MjBfzzbs84FegDvNkHx8nwPUd0=.46503fd8-d274-4558-bd0f-cc0c4f199667@github.com>
Message-ID: <2w9H6VAbxm7BgSGRwKAxbI56bG-k4bE_ZDviGrBF36o=.3d4cb47f-0f84-479a-a809-6d0186dfad2d@github.com>

On Thu, 19 Sep 2024 11:54:50 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> We already have a cpu dependent code for both C1 and the interpreter. Adding cpu dependent code to C2 doesn't make it significantly worse. My latest patch also refactors the code so that C1, interpreter, and C2 all calls into shared functions in the macro assembler.
>
> We haven't decided whether or not we will git rid of ```Klass::_prototype_header``` before intergrating this PR, or not. @stefank could point you to a WIP branch, if that's helpful.

This is my current work-in-progress code:
https://github.com/stefank/jdk/compare/pull/20677...stefank:jdk:lilliput_remove_prototype_header_wip_2

I've made some large rewrites and are currently running it through functional testing.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1766934571

From mli at openjdk.org  Thu Sep 19 15:03:53 2024
From: mli at openjdk.org (Hamlin Li)
Date: Thu, 19 Sep 2024 15:03:53 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v23]
In-Reply-To: <0BrAbBTKmpqTGDrc--2znzO8t07yoqabwa6g2K05GHI=.d3c17fd5-4770-4623-8d2f-604816afc033@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <0BrAbBTKmpqTGDrc--2znzO8t07yoqabwa6g2K05GHI=.d3c17fd5-4770-4623-8d2f-604816afc033@github.com>
Message-ID: <cL1TRIR8QmiIxhVU8LmxcEjUcneCNyLOh7ik4fgmIcM=.abc5dea2-6d92-4b6e-9e3f-01137441d02e@github.com>

On Thu, 19 Sep 2024 12:08:46 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> This is the main body of the JEP 450: Compact Object Headers (Experimental).
>> 
>> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing.
>> 
>> Main changes:
>>  - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers.
>>  - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded.
>>  - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops).
>>  - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all).
>>  - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16).
>>  - Arrays will now store their length at offset 8.
>>  - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _co...
>
> Roman Kennke has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'lilliput/JEP-450-temporary-fix-branch-2' into JDK-8305895-v4
>  - review feedback

In both aarch64.ad and x86_64.ad, `MachUEPNode::format` might need some change accordingly?

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

PR Comment: https://git.openjdk.org/jdk/pull/20677#issuecomment-2361266175

From rcastanedalo at openjdk.org  Thu Sep 19 17:23:50 2024
From: rcastanedalo at openjdk.org (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Thu, 19 Sep 2024 17:23:50 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v15]
In-Reply-To: <poutu1_cWKZJS_aUjdHdxXdoYBb0nS5Zohb1-_UwFiY=.403c84c9-a971-4b16-b436-e34cc9654321@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <CCz9B03dUxzua_YHk9-nyyHS_FTa6axwrwYjACcz4Y0=.6052f53c-9ddb-4868-a817-aff4276a2b6a@github.com>
 <6UJOrZqmfsJj6pRzMjPdlYt191QgBV6fIv1qJAYsv60=.15284272-464f-4321-b76c-3412dafc6c63@github.com>
 <poutu1_cWKZJS_aUjdHdxXdoYBb0nS5Zohb1-_UwFiY=.403c84c9-a971-4b16-b436-e34cc9654321@github.com>
Message-ID: <IvQ2g_HP080mVZMQYJM3SCnjeAwZnJHfDHGUzwkXpR4=.053ed2be-6e53-4b91-b048-8efb57645c9c@github.com>

On Wed, 18 Sep 2024 12:08:46 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.cpp line 2576:
>> 
>>> 2574:   } else {
>>> 2575:     lea(dst, Address(obj, index, Address::lsl(scale)));
>>> 2576:     ldr(dst, Address(dst, offset));
>> 
>> Do you have a reproducer (or, better yet, a test case) that exercises this case? I ran Oracle's internal CI tiers 1-5 and could never hit it. Could this happen for x64 as well?
>
> AFAIK, this happens only when using compressed oops with a heap-base in r27. When running with that setting, we would get addresses like r27[nklass] or r27[nklass]+offset, both with scale=8. You would need large heaps, perhaps >4GB, to get this coops setting. The problem with aarch64 is that we can't have an address like  r27[nklass]+offset, that's why we need to lea the r27[nklass] part first.
> Yes, this also happens on x86, but x86 supports  rX[nklass]+offset addressing.

Thanks @rkennke, I tried running test tiers 1-3 using different compressed OOPs configurations but could not reach this code, unfortunately. Could you provide a reproducer? The reason I am particularly interested is because I'd like to find whether there could be any problematic interaction with C2's implicit null check optimization.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1767315114

From wkemper at openjdk.org  Thu Sep 19 17:28:48 2024
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 19 Sep 2024 17:28:48 GMT
Subject: RFR: Merge openjdk/jdk21u-dev:master [v2]
In-Reply-To: <7LCHmp1lRwMox4FXtVqnHP_rYRyYuTrskm5P2iGiTHI=.6e726b08-87e6-454e-b964-ba2e11a4ddd7@github.com>
References: <7LCHmp1lRwMox4FXtVqnHP_rYRyYuTrskm5P2iGiTHI=.6e726b08-87e6-454e-b964-ba2e11a4ddd7@github.com>
Message-ID: <iwe6oNqU9IE3gDO1csSrvU7z5E4o8b_x-XPhYXZsm2M=.094d8d91-69ca-4f46-b8cc-07eab59d422d@github.com>

> Merges tag jdk-21.0.5+8

William Kemper has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase.

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

Changes:
  - all: https://git.openjdk.org/shenandoah-jdk21u/pull/104/files
  - new: https://git.openjdk.org/shenandoah-jdk21u/pull/104/files/b99bff9e..b99bff9e

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

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

PR: https://git.openjdk.org/shenandoah-jdk21u/pull/104

From wkemper at openjdk.org  Thu Sep 19 17:28:49 2024
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 19 Sep 2024 17:28:49 GMT
Subject: Integrated: Merge openjdk/jdk21u-dev:master
In-Reply-To: <7LCHmp1lRwMox4FXtVqnHP_rYRyYuTrskm5P2iGiTHI=.6e726b08-87e6-454e-b964-ba2e11a4ddd7@github.com>
References: <7LCHmp1lRwMox4FXtVqnHP_rYRyYuTrskm5P2iGiTHI=.6e726b08-87e6-454e-b964-ba2e11a4ddd7@github.com>
Message-ID: <ebYNt_xccqkjT61ZswnkTR3P35bpeFTps6szcrrJUsU=.777a0f41-88a3-408a-82a8-c899ef790943@github.com>

On Thu, 19 Sep 2024 14:18:52 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Merges tag jdk-21.0.5+8

This pull request has now been integrated.

Changeset: 1441c79f
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.org/shenandoah-jdk21u/commit/1441c79fa23e987898a602a0d3f727263ad84806
Stats:     228 lines in 7 files changed: 148 ins; 71 del; 9 mod

Merge

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

PR: https://git.openjdk.org/shenandoah-jdk21u/pull/104

From wkemper at openjdk.org  Thu Sep 19 17:57:38 2024
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 19 Sep 2024 17:57:38 GMT
Subject: RFR: 8340400: Shenandoah: Whitebox breakpoint GC requests may
 cause assertions
In-Reply-To: <eFIBip-WT-4JsLJIJ9F-L66700DZjmakU3P4ZRcWjL0=.712ae3a2-65c6-4f78-a2f5-ab8a92a8aa3a@github.com>
References: <eFIBip-WT-4JsLJIJ9F-L66700DZjmakU3P4ZRcWjL0=.712ae3a2-65c6-4f78-a2f5-ab8a92a8aa3a@github.com>
Message-ID: <yPlca617eBiAIUar11blTD8XYHNpOk9jbGFa2sJ2gLo=.349e1c34-8435-4af1-b5eb-aaa44426c4f9@github.com>

On Wed, 18 Sep 2024 21:02:23 GMT, William Kemper <wkemper at openjdk.org> wrote:

> When a test requests a concurrent GC breakpoint, the calling thread arranges for itself to block until the concurrent GC thread notifies it that the GC has reached the requested breakpoint (phase). The code that handles the whitebox breakpoint request should therefore not block the caller. An attempt was made to do this, but the request just has the caller thread run in a busy loop without waiting. What's more, this loop resets the requested gc cause on every iteration, which may lead to gc cycles with a wb_breakpoint cause, but no breakpoint set - which violates assertions.

TestReferenceShortcutCycle and TestReferenceRefersToShenandoah would fail occasionally in the generational mode. I believe the generational mode was more susceptible to the issue because of differences in the generational mode controller. I don't recall seeing test failures in upstream, but as I read the code I believe the issue _could_ happen to other Shenandoah modes (or otherwise cause tests using whitebox breakpoints to behave in unexpected ways).

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

PR Comment: https://git.openjdk.org/jdk/pull/21074#issuecomment-2361831211

From wkemper at openjdk.org  Thu Sep 19 17:57:39 2024
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 19 Sep 2024 17:57:39 GMT
Subject: Integrated: 8340400: Shenandoah: Whitebox breakpoint GC requests may
 cause assertions
In-Reply-To: <eFIBip-WT-4JsLJIJ9F-L66700DZjmakU3P4ZRcWjL0=.712ae3a2-65c6-4f78-a2f5-ab8a92a8aa3a@github.com>
References: <eFIBip-WT-4JsLJIJ9F-L66700DZjmakU3P4ZRcWjL0=.712ae3a2-65c6-4f78-a2f5-ab8a92a8aa3a@github.com>
Message-ID: <IPTaYJc_qvzOiTde82xfhwxHbflXJloopTqQRIWZbQo=.7b7c9699-c997-4147-b283-f80645ac5c79@github.com>

On Wed, 18 Sep 2024 21:02:23 GMT, William Kemper <wkemper at openjdk.org> wrote:

> When a test requests a concurrent GC breakpoint, the calling thread arranges for itself to block until the concurrent GC thread notifies it that the GC has reached the requested breakpoint (phase). The code that handles the whitebox breakpoint request should therefore not block the caller. An attempt was made to do this, but the request just has the caller thread run in a busy loop without waiting. What's more, this loop resets the requested gc cause on every iteration, which may lead to gc cycles with a wb_breakpoint cause, but no breakpoint set - which violates assertions.

This pull request has now been integrated.

Changeset: 75d5e117
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/75d5e117770590d2432fcfe8d89734c7038d4e55
Stats:     13 lines in 1 file changed: 10 ins; 2 del; 1 mod

8340400: Shenandoah: Whitebox breakpoint GC requests may cause assertions

Reviewed-by: shade

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

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

From wkemper at openjdk.org  Thu Sep 19 21:50:35 2024
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 19 Sep 2024 21:50:35 GMT
Subject: RFR: 8340408: Shenandoah: Remove redundant task stats printing
 code in ShenandoahTaskQueue
In-Reply-To: <6PiT6kRNGaQjkJTNknVTqMV14SyYXwFosAz9Ts3Emfk=.46c01286-6733-424c-a0d6-e6ff8aa4726c@github.com>
References: <6PiT6kRNGaQjkJTNknVTqMV14SyYXwFosAz9Ts3Emfk=.46c01286-6733-424c-a0d6-e6ff8aa4726c@github.com>
Message-ID: <b8j5T3wNtPN9ysHoj8pDP3c3oWWnWG25E1gDGk1SpIs=.fc6b14f8-af4b-4dc1-a624-044957b4e61a@github.com>

On Thu, 19 Sep 2024 00:33:04 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> [JDK-8280397](https://bugs.openjdk.org/browse/JDK-8280397) made the code redundant. 
> 
> Adopt shared implementation.

Thanks for this! Can we use the labels as requested in the review comments?

src/hotspot/share/gc/shenandoah/shenandoahConcurrentMark.cpp line 228:

> 226:   finish_mark_work();
> 227:   assert(task_queues()->is_empty(), "Should be empty");
> 228:   TASKQUEUE_STATS_ONLY(task_queues()->print_and_reset_taskqueue_stats(""));

Could we pass `"Finish Mark"` for the label here.

src/hotspot/share/gc/shenandoah/shenandoahSTWMark.cpp line 136:

> 134: 
> 135:   assert(task_queues()->is_empty(), "Should be empty");
> 136:   TASKQUEUE_STATS_ONLY(task_queues()->print_and_reset_taskqueue_stats(""));

Could we pass `"Mark"` for the label here?

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

Changes requested by wkemper (Committer).

PR Review: https://git.openjdk.org/jdk/pull/21077#pullrequestreview-2316808410
PR Review Comment: https://git.openjdk.org/jdk/pull/21077#discussion_r1767638510
PR Review Comment: https://git.openjdk.org/jdk/pull/21077#discussion_r1767638220

From fyang at openjdk.org  Thu Sep 19 21:52:04 2024
From: fyang at openjdk.org (Fei Yang)
Date: Thu, 19 Sep 2024 21:52:04 GMT
Subject: Integrated: 8339643: Port JEP 404 to RISC-V
In-Reply-To: <J3I-KZdj2aYAEN7cFFDkuZEpp6WBM7AFaikL14CDdWM=.5f1201e3-3ca2-426e-b6ce-a4bd9aa9a879@github.com>
References: <J3I-KZdj2aYAEN7cFFDkuZEpp6WBM7AFaikL14CDdWM=.5f1201e3-3ca2-426e-b6ce-a4bd9aa9a879@github.com>
Message-ID: <lH7fcr3MhQ5G_qrbpNpz45l6dFRuVX-OGuflDIZ-vVI=.b4020201-fc8c-4d9f-ad09-520b09509381@github.com>

On Fri, 6 Sep 2024 11:18:35 GMT, Fei Yang <fyang at openjdk.org> wrote:

> The riscv64 implementation of [JDK-8337511](https://bugs.openjdk.org/browse/JDK-8337511) Implement JEP-404: Generational Shenandoah (Experimental).
> This is mainly adapted from the changes in aarch64.
> 
> Testing
> - [x] Gtest (release & fastdebug)
> - [x] hotspot_gc_shenandoah (release & fastdebug)

This pull request has now been integrated.

Changeset: d1bc34fb
Author:    Fei Yang <fyang at openjdk.org>
Committer: William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.org/shenandoah/commit/d1bc34fb4cbbaea51c470a6bc088e04427ea82d3
Stats:     88 lines in 4 files changed: 77 ins; 4 del; 7 mod

8339643: Port JEP 404 to RISC-V

Reviewed-by: wkemper, kdnilsen

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

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

From rkennke at openjdk.org  Fri Sep 20 12:33:50 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Fri, 20 Sep 2024 12:33:50 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v15]
In-Reply-To: <IvQ2g_HP080mVZMQYJM3SCnjeAwZnJHfDHGUzwkXpR4=.053ed2be-6e53-4b91-b048-8efb57645c9c@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <CCz9B03dUxzua_YHk9-nyyHS_FTa6axwrwYjACcz4Y0=.6052f53c-9ddb-4868-a817-aff4276a2b6a@github.com>
 <6UJOrZqmfsJj6pRzMjPdlYt191QgBV6fIv1qJAYsv60=.15284272-464f-4321-b76c-3412dafc6c63@github.com>
 <poutu1_cWKZJS_aUjdHdxXdoYBb0nS5Zohb1-_UwFiY=.403c84c9-a971-4b16-b436-e34cc9654321@github.com>
 <IvQ2g_HP080mVZMQYJM3SCnjeAwZnJHfDHGUzwkXpR4=.053ed2be-6e53-4b91-b048-8efb57645c9c@github.com>
Message-ID: <n5SsWdtVlbLQeGu2xxc39RFOkpcMUBUb16rd7IaZEAY=.a4d84480-b40f-4d74-9314-6b47c6551c20@github.com>

On Thu, 19 Sep 2024 17:20:36 GMT, Roberto Casta?eda Lozano <rcastanedalo at openjdk.org> wrote:

>> AFAIK, this happens only when using compressed oops with a heap-base in r27. When running with that setting, we would get addresses like r27[nklass] or r27[nklass]+offset, both with scale=8. You would need large heaps, perhaps >4GB, to get this coops setting. The problem with aarch64 is that we can't have an address like  r27[nklass]+offset, that's why we need to lea the r27[nklass] part first.
>> Yes, this also happens on x86, but x86 supports  rX[nklass]+offset addressing.
>
> Thanks @rkennke, I tried running test tiers 1-3 using different compressed OOPs configurations but could not reach this code, unfortunately. Could you provide a reproducer? The reason I am particularly interested is because I'd like to find whether there could be any problematic interaction with C2's implicit null check optimization.

I tried to reproduce for a few hours now using a custom testcase, with no success.
I am pretty sure that this can happen, that is why I added this code. Originally I had an assert there asserting that index is not used. I do remember that this happens very rarely, and I don't remember the exact condition. Looking at the possible operands in opclass memory, I think this can only happen when we load an nKlass from an address of the form [rX, rY], i.e. the address in rX indexed by rY. This is an odd thing to happen for loadNKlass, I think, because rY should always be klass_offset_in_bytes. Maybe this is possible when we get odd address merges where we get a PhiNode as the offset/index? I don't know.
I agree, this *might* lead to surprising problems with implicit null-checking, if it is expected that the first instruction in loadNKlass provokes the SIGSEGV. A way around this would be to declare an opclass that is a subset of 'memory' that excludes all operands with index, and match on that. I think this would force the lea as a separate instruction and ensure that we never see such a thing in loadNKlass. However, I would not feel very confident to do that without a reproducer. Let me dig a little further.

For reference, here is my unsuccessful reproducer: https://gist.github.com/rkennke/8a57610d74fcde07a9390f268ec35738

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1768538965

From wkemper at openjdk.org  Fri Sep 20 14:18:33 2024
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 20 Sep 2024 14:18:33 GMT
Subject: RFR: Merge openjdk/jdk:master
Message-ID: <k3izQynGjwMOhJNjpvcUIVd7_5WPxy856Fnm3Ar_qYE=.5e40a077-4d3e-4d68-8275-0f78707a8d77@github.com>

Merges tag jdk-24+16

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

Commit messages:
 - 8340276: Test java/lang/management/ThreadMXBean/Locks.java failed with NullPointerException
 - 8286851: Deprecate for removal several of the undocumented java launcher options
 - 8339416: [s390x] Provide implementation for resolve_global_jobject
 - 8339980: [s390x] ProblemList jdk/java/util/zip/CloseInflaterDeflaterTest.java
 - 8340360: Update -mx to -Xmx in UnninstallUIMemoryLeaks test
 - 8340078: Open source several 2D tests
 - 8339962: Open source AWT TextField tests - Set1
 - 8340391: Windows jcmd System.map and System.dump_map tests failing
 - 8340233: Missed ThreadWXEnable in jfrNativeLibraryLoadEvent.cpp
 - 8339992: RISC-V: some minor improvements of base64_vector_decode_round
 - ... and 78 more: https://git.openjdk.org/shenandoah/compare/3c40afa5...c58fbef0

The webrev contains the conflicts with master:
 - merge conflicts: https://webrevs.openjdk.org/?repo=shenandoah&pr=502&range=00.conflicts

Changes: https://git.openjdk.org/shenandoah/pull/502/files
  Stats: 148143 lines in 607 files changed: 143204 ins; 2003 del; 2936 mod
  Patch: https://git.openjdk.org/shenandoah/pull/502.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah.git pull/502/head:pull/502

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

From rkennke at openjdk.org  Fri Sep 20 15:29:52 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Fri, 20 Sep 2024 15:29:52 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v15]
In-Reply-To: <n5SsWdtVlbLQeGu2xxc39RFOkpcMUBUb16rd7IaZEAY=.a4d84480-b40f-4d74-9314-6b47c6551c20@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <CCz9B03dUxzua_YHk9-nyyHS_FTa6axwrwYjACcz4Y0=.6052f53c-9ddb-4868-a817-aff4276a2b6a@github.com>
 <6UJOrZqmfsJj6pRzMjPdlYt191QgBV6fIv1qJAYsv60=.15284272-464f-4321-b76c-3412dafc6c63@github.com>
 <poutu1_cWKZJS_aUjdHdxXdoYBb0nS5Zohb1-_UwFiY=.403c84c9-a971-4b16-b436-e34cc9654321@github.com>
 <IvQ2g_HP080mVZMQYJM3SCnjeAwZnJHfDHGUzwkXpR4=.053ed2be-6e53-4b91-b048-8efb57645c9c@github.com>
 <n5SsWdtVlbLQeGu2xxc39RFOkpcMUBUb16rd7IaZEAY=.a4d84480-b40f-4d74-9314-6b47c6551c20@github.com>
Message-ID: <kBBMPkYzFAS7ne_MN9yQpW1f60peFJsaxLxnSAD0reo=.f7abc0d7-dddd-4c13-a27f-a58772f7ba96@github.com>

On Fri, 20 Sep 2024 12:31:18 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> Thanks @rkennke, I tried running test tiers 1-3 using different compressed OOPs configurations but could not reach this code, unfortunately. Could you provide a reproducer? The reason I am particularly interested is because I'd like to find whether there could be any problematic interaction with C2's implicit null check optimization.
>
> I tried to reproduce for a few hours now using a custom testcase, with no success.
> I am pretty sure that this can happen, that is why I added this code. Originally I had an assert there asserting that index is not used. I do remember that this happens very rarely, and I don't remember the exact condition. Looking at the possible operands in opclass memory, I think this can only happen when we load an nKlass from an address of the form [rX, rY], i.e. the address in rX indexed by rY. This is an odd thing to happen for loadNKlass, I think, because rY should always be klass_offset_in_bytes. Maybe this is possible when we get odd address merges where we get a PhiNode as the offset/index? I don't know.
> I agree, this *might* lead to surprising problems with implicit null-checking, if it is expected that the first instruction in loadNKlass provokes the SIGSEGV. A way around this would be to declare an opclass that is a subset of 'memory' that excludes all operands with index, and match on that. I think this would force the lea as a separate instruction and ensure that we never see such a thing in loadNKlass. However, I would not feel very confident to do that without a reproducer. Let me dig a little further.
> 
> For reference, here is my unsuccessful reproducer: https://gist.github.com/rkennke/8a57610d74fcde07a9390f268ec35738

Something like this is what I have in mind. It seems to pass tier1 tests. I still haven't managed to reproduce the path that requires an index register, though.
https://github.com/rkennke/jdk/commit/2c4a7877e4ef94017c8155578d8cfc9342441656

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1768816377

From matsaave at openjdk.org  Fri Sep 20 17:21:51 2024
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Fri, 20 Sep 2024 17:21:51 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v23]
In-Reply-To: <0BrAbBTKmpqTGDrc--2znzO8t07yoqabwa6g2K05GHI=.d3c17fd5-4770-4623-8d2f-604816afc033@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <0BrAbBTKmpqTGDrc--2znzO8t07yoqabwa6g2K05GHI=.d3c17fd5-4770-4623-8d2f-604816afc033@github.com>
Message-ID: <tqr9Mxi8tb3Ng8WCDF6_mrCick03DcwMV6IQJVfcF64=.956103a6-0d69-4dac-a819-39be957cf188@github.com>

On Thu, 19 Sep 2024 12:08:46 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> This is the main body of the JEP 450: Compact Object Headers (Experimental).
>> 
>> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing.
>> 
>> Main changes:
>>  - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers.
>>  - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded.
>>  - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops).
>>  - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all).
>>  - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16).
>>  - Arrays will now store their length at offset 8.
>>  - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _co...
>
> Roman Kennke has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'lilliput/JEP-450-temporary-fix-branch-2' into JDK-8305895-v4
>  - review feedback

CDS changes look good! Have two style comments but otherwise this makes sense

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

Marked as reviewed by matsaave (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20677#pullrequestreview-2318793061

From matsaave at openjdk.org  Fri Sep 20 17:21:53 2024
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Fri, 20 Sep 2024 17:21:53 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v6]
In-Reply-To: <BGmZ04yibLn_KtPyQrA3sQv5OtMonrcDy3aN0vAj8NA=.5de6cae3-3a05-4a74-a15c-aade4176bdeb@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <BGmZ04yibLn_KtPyQrA3sQv5OtMonrcDy3aN0vAj8NA=.5de6cae3-3a05-4a74-a15c-aade4176bdeb@github.com>
Message-ID: <prghUAoX81SehIWD3kZW80POXP-2FuDwqTO2XaVZFDo=.8861307e-4f8d-4690-ac08-fb2e1923471e@github.com>

On Thu, 22 Aug 2024 20:08:43 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> This is the main body of the JEP 450: Compact Object Headers (Experimental).
>> 
>> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing.
>> 
>> Main changes:
>>  - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers.
>>  - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded.
>>  - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops).
>>  - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all).
>>  - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16).
>>  - Arrays will now store their length at offset 8.
>>  - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _co...
>
> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix bit counts in GCForwarding

src/hotspot/share/cds/archiveBuilder.cpp line 677:

> 675:     // Allocate space for the future InstanceKlass with proper alignment
> 676:     const size_t alignment =
> 677: #ifdef _LP64

I think the text alignment here is a bit confusing. Should 678 and 682 be at the same indentation?

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

> 346:   old_tag = (int)(intptr_t)nextPtr();
> 347:   // do_int(&old_tag);
> 348:   assert(tag == old_tag, "tag doesn't match (%d, expected %d)", old_tag, tag);

Is this assert message change a leftover from debugging or is it meant to be this way?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1768946883
PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1768923643

From coleenp at openjdk.org  Fri Sep 20 18:19:51 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 20 Sep 2024 18:19:51 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v23]
In-Reply-To: <0BrAbBTKmpqTGDrc--2znzO8t07yoqabwa6g2K05GHI=.d3c17fd5-4770-4623-8d2f-604816afc033@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <0BrAbBTKmpqTGDrc--2znzO8t07yoqabwa6g2K05GHI=.d3c17fd5-4770-4623-8d2f-604816afc033@github.com>
Message-ID: <VjSp2vvwfzZWKtreZyiwjxsSblAX5JHCpF3c0mcYUHs=.b154b3dd-a8f2-4fdf-8176-52709f906891@github.com>

On Thu, 19 Sep 2024 12:08:46 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> This is the main body of the JEP 450: Compact Object Headers (Experimental).
>> 
>> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing.
>> 
>> Main changes:
>>  - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers.
>>  - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded.
>>  - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops).
>>  - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all).
>>  - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16).
>>  - Arrays will now store their length at offset 8.
>>  - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _co...
>
> Roman Kennke has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'lilliput/JEP-450-temporary-fix-branch-2' into JDK-8305895-v4
>  - review feedback

I mostly reviewed the metaspace changes and suggest upstreaming the MetaBlock refactoring ahead of the rest of this patch.
Only one comment about the interpreter code (affecting 4 locations).

src/hotspot/cpu/aarch64/templateTable_aarch64.cpp line 3636:

> 3634:     } else {
> 3635:       __ sub(r3, r3, sizeof(oopDesc));
> 3636:     }

This looks like something that could be buggy if we're not careful.  We had a pass where we cleaned up sizeof(oopDesc) once.  Can this be in oopDesc as (this is not header_size() anymore?) some function with the right name?

src/hotspot/cpu/x86/templateTable_x86.cpp line 4121:

> 4119:       __ movptr(Address(rax, rdx, Address::times_8, sizeof(oopDesc) - 1*oopSize), rcx);
> 4120:       NOT_LP64(__ movptr(Address(rax, rdx, Address::times_8, sizeof(oopDesc) - 2*oopSize), rcx));
> 4121:     }

For this and above, I'd rather oopDesc encapsulate the header_size for UseCompactObjectHeaders condition in C++ code, and never see sizeof(oopDesc).

src/hotspot/share/memory/metaspace.cpp line 799:

> 797: 
> 798:     // Set up compressed class pointer encoding.
> 799:     // In CDS=off mode, we give the JVM some leeway to choose a favorable base/shift combination.

I don't know why this comment is here.  Seems out of place.

src/hotspot/share/memory/metaspace/freeBlocks.cpp line 57:

> 55:     }
> 56:   }
> 57:   return p;

This answers my prior question.  The waste is added back to the block list for non-class-arenas as well.

src/hotspot/share/memory/metaspace/metablock.hpp line 74:

> 72: #define METABLOCKFORMATARGS(__block__)  p2i((__block__).base()), (__block__).word_size()
> 73: 
> 74: } // namespace metaspace

I am wondering if some of these metaspace changes, that is, the addition of MetaBlock could be upstreamed ahead of the CompactObjectHeaders.  Some is refactoring so that you can use the wastage to allocate into class-arena but a lot of this seems neutral to compact object headers, and would reduce this patch and allow different people to focus on just this.

src/hotspot/share/memory/metaspace/metaspaceArena.cpp line 470:

> 468: 
> 469: // Returns true if the given block is contained in this arena
> 470: // Returns true if the given block is contained in this arena

Here's the same comment twice.

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

PR Review: https://git.openjdk.org/jdk/pull/20677#pullrequestreview-2318539468
PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1768775590
PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1768781956
PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1768979540
PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1769008437
PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1769012842
PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1769015008

From coleenp at openjdk.org  Fri Sep 20 18:19:52 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 20 Sep 2024 18:19:52 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v11]
In-Reply-To: <m9Xj-C2ZuCBJfaOrr8zH59Ny5LDERRs-Lw5oVzDGvII=.daaae9b4-b1a3-491c-a5d0-9e327443e3bd@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <DUgk6HT_Zk5KnbmAd_HzrJi4B8D1J-uuoAGzReWyI8s=.6c04f90a-bf1d-49af-a31d-5224973952d4@github.com>
 <b8u6PaStO4nt0AGnbZEkmXkzQKzXaB2c4lSiC9JWdTY=.a5805ef2-84d8-44c0-9dc0-3e90da3460aa@github.com>
 <m9Xj-C2ZuCBJfaOrr8zH59Ny5LDERRs-Lw5oVzDGvII=.daaae9b4-b1a3-491c-a5d0-9e327443e3bd@github.com>
Message-ID: <5Mh0IteE4Z7zDseCNMmYKOtyCMTQe0iuAp70kJf8pS0=.8215bcce-6387-46fb-97a0-d1e6a9498b61@github.com>

On Wed, 18 Sep 2024 13:57:29 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> src/hotspot/share/memory/classLoaderMetaspace.cpp line 87:
>> 
>>> 85:         klass_alignment_words,
>>> 86:         "class arena");
>>> 87:   }
>> 
>> As per my comment in the header file, change the code to this:
>> 
>> ```c++
>> if (class_context != nullptr) {
>>   // ... Same as in PR
>> } else {
>>   _class_space_arena = _non_class_space_arena;
>> }
>
> Rather not, see reasoning under https://github.com/openjdk/jdk/pull/20677/files#r1754330432

Yes, I'd rather _class_space_arena be nullptr if not used.

>> src/hotspot/share/memory/classLoaderMetaspace.cpp line 115:
>> 
>>> 113:   if (wastage.is_nonempty()) {
>>> 114:     non_class_space_arena()->deallocate(wastage);
>>> 115:   }
>> 
>> This code reads a bit strangely. I understand *what* it tries to do. It tries to give back any wasted memory from either the class space arena *or* the non class space arena to the non class space arena's freelist. I assume that we do this since any wastage is presumably too small to be used by our new 22-bit class pointers. However, this context will be lost on future readers. It should have at least a comment in the `if (wastage.is_nonempty())` clause explaining what we expect should happen and why. For example:
>> 
>> ```c++
>> // Any wasted memory is presumably too small for any class.
>> // Therefore, give it back to the non-class space arena's free list.
>
> Yes. Some background:
> 
> - wastage can only occur for larger Klass* alignments (aka class space arena alignment property), so only for +COH (note to self, maybe assert)
> - wastage is, by definition, not aligned to the required Klass* alignment, so it cannot be reused. Yes, its probably also too small
> 
> Yes, I will write a better comment.

Yes, this definitely needs a comment why since this is how we allocate small chunks of wasted because of hyper-aligning Klasses in class space.   Line 111 is somewhat surprising though.  I didn't expect there to be wastage from allocating to non-class-metaspace.

The unnerving bit of this is that CompressedKlassPointers::is_encodable() is true for memory allocated here.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1768897591
PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1768966812

From coleenp at openjdk.org  Fri Sep 20 18:19:53 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 20 Sep 2024 18:19:53 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v11]
In-Reply-To: <5Mh0IteE4Z7zDseCNMmYKOtyCMTQe0iuAp70kJf8pS0=.8215bcce-6387-46fb-97a0-d1e6a9498b61@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <DUgk6HT_Zk5KnbmAd_HzrJi4B8D1J-uuoAGzReWyI8s=.6c04f90a-bf1d-49af-a31d-5224973952d4@github.com>
 <b8u6PaStO4nt0AGnbZEkmXkzQKzXaB2c4lSiC9JWdTY=.a5805ef2-84d8-44c0-9dc0-3e90da3460aa@github.com>
 <m9Xj-C2ZuCBJfaOrr8zH59Ny5LDERRs-Lw5oVzDGvII=.daaae9b4-b1a3-491c-a5d0-9e327443e3bd@github.com>
 <5Mh0IteE4Z7zDseCNMmYKOtyCMTQe0iuAp70kJf8pS0=.8215bcce-6387-46fb-97a0-d1e6a9498b61@github.com>
Message-ID: <BEtvFqI5Oh4yHALynmunhsWEwWLdkF2FuyBqJlHwO3k=.0bfe0664-3325-436d-a56e-e997d7a2d1f7@github.com>

On Fri, 20 Sep 2024 17:34:09 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Yes. Some background:
>> 
>> - wastage can only occur for larger Klass* alignments (aka class space arena alignment property), so only for +COH (note to self, maybe assert)
>> - wastage is, by definition, not aligned to the required Klass* alignment, so it cannot be reused. Yes, its probably also too small
>> 
>> Yes, I will write a better comment.
>
> Yes, this definitely needs a comment why since this is how we allocate small chunks of wasted because of hyper-aligning Klasses in class space.   Line 111 is somewhat surprising though.  I didn't expect there to be wastage from allocating to non-class-metaspace.
> 
> The unnerving bit of this is that CompressedKlassPointers::is_encodable() is true for memory allocated here.

I think this should also assert or be condionalized on UseCompactObjectHeaders.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1768972448

From xpeng at openjdk.org  Fri Sep 20 18:31:55 2024
From: xpeng at openjdk.org (Xiaolong Peng)
Date: Fri, 20 Sep 2024 18:31:55 GMT
Subject: RFR: 8340490: Shenandoah: Optimize ShenandoahPacer
Message-ID: <mh4-1fuv1_9n0e_BCeIX-WHnXZN-1A7woAkyJinXkIU=.c03edc09-82fc-44c2-b09b-22d543fb4ec4@github.com>

In a simple latency benchmark for memory allocation, I found ShenandoahPacer contributed quite a lot to the long tail latency > 10ms, when there are multi mutator threads failed at fast path to claim budget [here](https://github.com/openjdk/jdk/blob/fdc16a373459cb2311316448c765b1bee5c73694/src/hotspot/share/gc/shenandoah/shenandoahPacer.cpp#L230), all of them will forcefully claim and them wait for up to 10ms([code link](https://github.com/openjdk/jdk/blob/fdc16a373459cb2311316448c765b1bee5c73694/src/hotspot/share/gc/shenandoah/shenandoahPacer.cpp#L239-L277))

The change in this PR makes ShenandoahPacer impact long tail latency much less, instead forcefully claim budget and them wait, it attempts to claim after waiting for 1ms, and keep doing this until: 1/ either spent 10ms waiting in total; 2/ or successfully claimed the budget.

Here the latency comparison for the optimization:
![hdr-histogram-optimize-pacer](https://github.com/user-attachments/assets/811f48c5-87eb-462d-8b27-d15bd08be7b0)

With the optimization, long tail latency from the test code below has been much improved from over 20ms to ~10ms on MacOS with M3 chip:

    static final int threadCount = Runtime.getRuntime().availableProcessors();
    static final LongAdder totalCount = new LongAdder();
    static volatile byte[] sink;
    public static void main(String[] args) {
        runAllocationTest(100000);
    }
    static void recordTimeToAllocate(final int dataSize, final Histogram histogram) {
        long startTime = System.nanoTime();
        sink = new byte[dataSize];
        long endTime = System.nanoTime();
        histogram.recordValue(endTime - startTime);
    }

    static void runAllocationTest(final int dataSize) {
        final long endTime = System.currentTimeMillis() + 30_000;
        final CountDownLatch startSignal = new CountDownLatch(1);
        final CountDownLatch finished = new CountDownLatch(threadCount);
        final Thread[] threads = new Thread[threadCount];
        final Histogram[] histograms = new Histogram[threadCount];
        final Histogram totalHistogram = new Histogram(3600000000000L, 3);
        for (int i = 0; i < threadCount; i++) {
            final var histogram = new Histogram(3600000000000L, 3);
            histograms[i] = histogram;
            threads[i] = new Thread(() -> {
                wait(startSignal);
                do {
                    recordTimeToAllocate(dataSize, histogram);
                } while (System.currentTimeMillis() < endTime);
                finished.countDown();
            });
            threads[i].start();
        }

        startSignal.countDown(); //Start to test
        wait(finished);
        
        for (Histogram histogram : histograms) {
            totalHistogram.add(histogram);
        }

        totalHistogram.outputPercentileDistribution(System.out, 1000.0);

    }

    public static void wait(final CountDownLatch latch) {
        try {
            latch.await();
        } catch (InterruptedException e) {
            throw new RuntimeException(e);
        }
    }


### Additional test
- [x] MacOS AArch64 server fastdebug, hotspot_gc_shenandoah

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

Commit messages:
 - use const
 - refactor
 - Clean code
 - try claim_for_alloc before calculating total_delay
 - try claim_for_alloc before calculating total_delay
 - clean up
 - 8340490: Shenandoah: Optimize ShenandoahPacer

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

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

From shade at openjdk.org  Fri Sep 20 18:31:56 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 20 Sep 2024 18:31:56 GMT
Subject: RFR: 8340490: Shenandoah: Optimize ShenandoahPacer
In-Reply-To: <mh4-1fuv1_9n0e_BCeIX-WHnXZN-1A7woAkyJinXkIU=.c03edc09-82fc-44c2-b09b-22d543fb4ec4@github.com>
References: <mh4-1fuv1_9n0e_BCeIX-WHnXZN-1A7woAkyJinXkIU=.c03edc09-82fc-44c2-b09b-22d543fb4ec4@github.com>
Message-ID: <61bsu02-sDgUFx45vjC3xAvAaDtIY405Qm8lh3Edp28=.5a1c2d42-a51c-4014-b5e3-64cbd02786ed@github.com>

On Thu, 19 Sep 2024 23:32:14 GMT, Xiaolong Peng <xpeng at openjdk.org> wrote:

> In a simple latency benchmark for memory allocation, I found ShenandoahPacer contributed quite a lot to the long tail latency > 10ms, when there are multi mutator threads failed at fast path to claim budget [here](https://github.com/openjdk/jdk/blob/fdc16a373459cb2311316448c765b1bee5c73694/src/hotspot/share/gc/shenandoah/shenandoahPacer.cpp#L230), all of them will forcefully claim and them wait for up to 10ms([code link](https://github.com/openjdk/jdk/blob/fdc16a373459cb2311316448c765b1bee5c73694/src/hotspot/share/gc/shenandoah/shenandoahPacer.cpp#L239-L277))
> 
> The change in this PR makes ShenandoahPacer impact long tail latency much less, instead forcefully claim budget and them wait, it attempts to claim after waiting for 1ms, and keep doing this until: 1/ either spent 10ms waiting in total; 2/ or successfully claimed the budget.
> 
> Here the latency comparison for the optimization:
> ![hdr-histogram-optimize-pacer](https://github.com/user-attachments/assets/811f48c5-87eb-462d-8b27-d15bd08be7b0)
> 
> With the optimization, long tail latency from the test code below has been much improved from over 20ms to ~10ms on MacOS with M3 chip:
> 
>     static final int threadCount = Runtime.getRuntime().availableProcessors();
>     static final LongAdder totalCount = new LongAdder();
>     static volatile byte[] sink;
>     public static void main(String[] args) {
>         runAllocationTest(100000);
>     }
>     static void recordTimeToAllocate(final int dataSize, final Histogram histogram) {
>         long startTime = System.nanoTime();
>         sink = new byte[dataSize];
>         long endTime = System.nanoTime();
>         histogram.recordValue(endTime - startTime);
>     }
> 
>     static void runAllocationTest(final int dataSize) {
>         final long endTime = System.currentTimeMillis() + 30_000;
>         final CountDownLatch startSignal = new CountDownLatch(1);
>         final CountDownLatch finished = new CountDownLatch(threadCount);
>         final Thread[] threads = new Thread[threadCount];
>         final Histogram[] histograms = new Histogram[threadCount];
>         final Histogram totalHistogram = new Histogram(3600000000000L, 3);
>         for (int i = 0; i < threadCount; i++) {
>             final var histogram = new Histogram(3600000000000L, 3);
>             histograms[i] = histogram;
>             threads[i] = new Thread(() -> {
>                 wait(startSignal);
>                 do {
>                     recordTimeToAllocate(dataSize, histogram);
>                 } while (System.currentTimeMillis() < e...

I am trying to remember why we even bothered to go into negative budget on this path, and then waited for it to recover. I think it is from here: https://mail.openjdk.org/pipermail/shenandoah-dev/2018-April/005559.html. AFAICS, the intent for that fix was to make sure that unsuccessful pacing claim the budget, which this patch also does. And given it apparently improves performance, I don't mind it going in.

Comprehension question: the actual improvement comes from waiting in 1ms slices, not from anything else? In retrospect, _it is_ silly to wait until the deadline before attempting to claim the pacing budget.

I am good with this, assuming performance runs show good results.

src/hotspot/share/gc/shenandoah/shenandoahPacer.cpp line 191:

> 189:   _need_notify_waiters.try_set();
> 190: }
> 191: template<bool FORCE>

Newline before `template`, please.

src/hotspot/share/gc/shenandoah/shenandoahPacer.cpp line 206:

> 204:     }
> 205:     new_val = cur - tax;
> 206:   } while (Atomic::load(&_budget) == cur &&

I don't think we need this load, since we have _just_ had another load nearby. This should be enough to resolve the contention issues TTAS pattern tries to avoid.

src/hotspot/share/gc/shenandoah/shenandoahPacer.cpp line 256:

> 254:   double total_delay = 0;
> 255: 
> 256:   double start = os::elapsedTime();

While we are here, let's avoid some integer divisions and floating-point math. Try to rewrite this using `jlong os::elapsed_counter()`, which returns integer nanoseconds? Do the math in `jlong`-s.

src/hotspot/share/gc/shenandoah/shenandoahPacer.cpp line 257:

> 255: 
> 256:   double start = os::elapsedTime();
> 257:   while (!claimed) {

I suggest we common some exit paths by writing the loop like this:


double start_time = os::elapsedTime();
while (!claimed && (os::elapsedTime() - start_time) < max_delay) {
  // We could instead assist GC, but this would suffice for now.
  wait(1);
  claimed = claim_for_alloc<false>(words);
}
if (!claimed) {
  // Spent local time budget to wait for enough GC progress.
  // Force allocating anyway, which may mean we outpace GC,
  // and start Degenerated GC cycle.
  claimed = claim_for_alloc<true>(words);
  assert(claimed, "Should always succeed");
}
ShenandoahThreadLocalData::add_paced_time(JavaThread::current(), os::elapsedTime() - start_time);

src/hotspot/share/gc/shenandoah/shenandoahPacer.cpp line 265:

> 263:     // and start Degenerated GC cycle.
> 264:     claimed = claim_for_alloc<true>(words);
> 265:     assert(claimed, "Should always succeed");

Come to think about it, we don't need to check for return value here. We don't check in other place where we call `claim_for_alloc<true>(words);`

src/hotspot/share/gc/shenandoah/shenandoahPacer.cpp line 267:

> 265:     assert(claimed, "Should always succeed");
> 266:   }
> 267:   ShenandoahThreadLocalData::add_paced_time(JavaThread::current(), (double)(os::elapsed_counter() - start_time) / (double) NANOSECS_PER_SEC);

We already have `current` (`JavaThread::current()`) in scope here, use that :)
I also think a second cast to `(double) NANOSECS_PER_SEC` is redundant.

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

PR Review: https://git.openjdk.org/jdk/pull/21099#pullrequestreview-2317722311
Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21099#pullrequestreview-2318988155
PR Review Comment: https://git.openjdk.org/jdk/pull/21099#discussion_r1768272092
PR Review Comment: https://git.openjdk.org/jdk/pull/21099#discussion_r1768271671
PR Review Comment: https://git.openjdk.org/jdk/pull/21099#discussion_r1768281644
PR Review Comment: https://git.openjdk.org/jdk/pull/21099#discussion_r1768291970
PR Review Comment: https://git.openjdk.org/jdk/pull/21099#discussion_r1769025976
PR Review Comment: https://git.openjdk.org/jdk/pull/21099#discussion_r1769027052

From xpeng at openjdk.org  Fri Sep 20 18:31:56 2024
From: xpeng at openjdk.org (Xiaolong Peng)
Date: Fri, 20 Sep 2024 18:31:56 GMT
Subject: RFR: 8340490: Shenandoah: Optimize ShenandoahPacer
In-Reply-To: <61bsu02-sDgUFx45vjC3xAvAaDtIY405Qm8lh3Edp28=.5a1c2d42-a51c-4014-b5e3-64cbd02786ed@github.com>
References: <mh4-1fuv1_9n0e_BCeIX-WHnXZN-1A7woAkyJinXkIU=.c03edc09-82fc-44c2-b09b-22d543fb4ec4@github.com>
 <61bsu02-sDgUFx45vjC3xAvAaDtIY405Qm8lh3Edp28=.5a1c2d42-a51c-4014-b5e3-64cbd02786ed@github.com>
Message-ID: <CBJLCwYKqrdTQ9T49jBynZGf7rNcDAyGipaOlUNRcmc=.3625732b-d75c-4ada-961b-ee2ee9122c21@github.com>

On Fri, 20 Sep 2024 09:46:50 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> I am trying to remember why we even bothered to go into negative budget on this path, and then waited for it to recover. I think it is from here: https://mail.openjdk.org/pipermail/shenandoah-dev/2018-April/005559.html. AFAICS, the intent for that fix was to make sure that unsuccessful pacing claim the budget, which this patch also does. And given it apparently improves performance, I don't mind it going in.
> 
> Comprehension question: the actual improvement comes from waiting in 1ms slices, not from anything else? In retrospect, _it is_ silly to wait until the deadline before attempting to claim the pacing budget.

> src/hotspot/share/gc/shenandoah/shenandoahPacer.cpp line 206:
> 
>> 204:     }
>> 205:     new_val = cur - tax;
>> 206:   } while (Atomic::load(&_budget) == cur &&
> 
> I don't think we need this load, since we have _just_ had another load nearby. This should be enough to resolve the contention issues TTAS pattern tries to avoid.

Thanks, reverted TTAS pattern.

> src/hotspot/share/gc/shenandoah/shenandoahPacer.cpp line 257:
> 
>> 255: 
>> 256:   double start = os::elapsedTime();
>> 257:   while (!claimed) {
> 
> I suggest we common some exit paths by writing the loop like this:
> 
> 
> double start_time = os::elapsedTime();
> while (!claimed && (os::elapsedTime() - start_time) < max_delay) {
>   // We could instead assist GC, but this would suffice for now.
>   wait(1);
>   claimed = claim_for_alloc<false>(words);
> }
> if (!claimed) {
>   // Spent local time budget to wait for enough GC progress.
>   // Force allocating anyway, which may mean we outpace GC,
>   // and start Degenerated GC cycle.
>   claimed = claim_for_alloc<true>(words);
>   assert(claimed, "Should always succeed");
> }
> ShenandoahThreadLocalData::add_paced_time(JavaThread::current(), os::elapsedTime() - start_time);

Thanks, refactored the code along with the change to use os::elapsed_counter(), only need handle the nanos to seconds conversion when calling  ShenandoahThreadLocalData::add_paced_time at the last.

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

PR Comment: https://git.openjdk.org/jdk/pull/21099#issuecomment-2364294440
PR Review Comment: https://git.openjdk.org/jdk/pull/21099#discussion_r1769018442
PR Review Comment: https://git.openjdk.org/jdk/pull/21099#discussion_r1769021455

From xpeng at openjdk.org  Fri Sep 20 18:47:50 2024
From: xpeng at openjdk.org (Xiaolong Peng)
Date: Fri, 20 Sep 2024 18:47:50 GMT
Subject: RFR: 8340490: Shenandoah: Optimize ShenandoahPacer [v2]
In-Reply-To: <mh4-1fuv1_9n0e_BCeIX-WHnXZN-1A7woAkyJinXkIU=.c03edc09-82fc-44c2-b09b-22d543fb4ec4@github.com>
References: <mh4-1fuv1_9n0e_BCeIX-WHnXZN-1A7woAkyJinXkIU=.c03edc09-82fc-44c2-b09b-22d543fb4ec4@github.com>
Message-ID: <U4-6cg1j9inHQdKJDt0mYEl9DFc6nQ9sbdiao4hSH_4=.9e421feb-a9c7-4c77-b745-e307749b052f@github.com>

> In a simple latency benchmark for memory allocation, I found ShenandoahPacer contributed quite a lot to the long tail latency > 10ms, when there are multi mutator threads failed at fast path to claim budget [here](https://github.com/openjdk/jdk/blob/fdc16a373459cb2311316448c765b1bee5c73694/src/hotspot/share/gc/shenandoah/shenandoahPacer.cpp#L230), all of them will forcefully claim and them wait for up to 10ms([code link](https://github.com/openjdk/jdk/blob/fdc16a373459cb2311316448c765b1bee5c73694/src/hotspot/share/gc/shenandoah/shenandoahPacer.cpp#L239-L277))
> 
> The change in this PR makes ShenandoahPacer impact long tail latency much less, instead forcefully claim budget and them wait, it attempts to claim after waiting for 1ms, and keep doing this until: 1/ either spent 10ms waiting in total; 2/ or successfully claimed the budget.
> 
> Here the latency comparison for the optimization:
> ![hdr-histogram-optimize-pacer](https://github.com/user-attachments/assets/811f48c5-87eb-462d-8b27-d15bd08be7b0)
> 
> With the optimization, long tail latency from the test code below has been much improved from over 20ms to ~10ms on MacOS with M3 chip:
> 
>     static final int threadCount = Runtime.getRuntime().availableProcessors();
>     static final LongAdder totalCount = new LongAdder();
>     static volatile byte[] sink;
>     public static void main(String[] args) {
>         runAllocationTest(100000);
>     }
>     static void recordTimeToAllocate(final int dataSize, final Histogram histogram) {
>         long startTime = System.nanoTime();
>         sink = new byte[dataSize];
>         long endTime = System.nanoTime();
>         histogram.recordValue(endTime - startTime);
>     }
> 
>     static void runAllocationTest(final int dataSize) {
>         final long endTime = System.currentTimeMillis() + 30_000;
>         final CountDownLatch startSignal = new CountDownLatch(1);
>         final CountDownLatch finished = new CountDownLatch(threadCount);
>         final Thread[] threads = new Thread[threadCount];
>         final Histogram[] histograms = new Histogram[threadCount];
>         final Histogram totalHistogram = new Histogram(3600000000000L, 3);
>         for (int i = 0; i < threadCount; i++) {
>             final var histogram = new Histogram(3600000000000L, 3);
>             histograms[i] = histogram;
>             threads[i] = new Thread(() -> {
>                 wait(startSignal);
>                 do {
>                     recordTimeToAllocate(dataSize, histogram);
>                 } while (System.currentTimeMillis() < e...

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

  clean up

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21099/files
  - new: https://git.openjdk.org/jdk/pull/21099/files/1de70211..58196a4f

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

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

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

From xpeng at openjdk.org  Fri Sep 20 18:47:50 2024
From: xpeng at openjdk.org (Xiaolong Peng)
Date: Fri, 20 Sep 2024 18:47:50 GMT
Subject: RFR: 8340490: Shenandoah: Optimize ShenandoahPacer [v2]
In-Reply-To: <CBJLCwYKqrdTQ9T49jBynZGf7rNcDAyGipaOlUNRcmc=.3625732b-d75c-4ada-961b-ee2ee9122c21@github.com>
References: <mh4-1fuv1_9n0e_BCeIX-WHnXZN-1A7woAkyJinXkIU=.c03edc09-82fc-44c2-b09b-22d543fb4ec4@github.com>
 <61bsu02-sDgUFx45vjC3xAvAaDtIY405Qm8lh3Edp28=.5a1c2d42-a51c-4014-b5e3-64cbd02786ed@github.com>
 <CBJLCwYKqrdTQ9T49jBynZGf7rNcDAyGipaOlUNRcmc=.3625732b-d75c-4ada-961b-ee2ee9122c21@github.com>
Message-ID: <-6wa5ftQJ3WdXiX-SsMY-nXgnTWCl9ZzDTt89akghyM=.7e53fed3-2f4c-4c40-9465-15c97bf8e089@github.com>

On Fri, 20 Sep 2024 18:27:14 GMT, Xiaolong Peng <xpeng at openjdk.org> wrote:

> I am trying to remember why we even bothered to go into negative budget on this path, and then waited for it to recover. I think it is from here: https://mail.openjdk.org/pipermail/shenandoah-dev/2018-April/005559.html. AFAICS, the intent for that fix was to make sure that unsuccessful pacing claim the budget, which this patch also does. And given it apparently improves performance, I don't mind it going in.
> 
> Comprehension question: the actual improvement comes from waiting in 1ms slices, not from anything else? In retrospect, _it is_ silly to wait until the deadline before attempting to claim the pacing budget.

It is primarily from the  algorithm change with 1ms slices. 

The behavior has been changed in the new algorithm with 1ms slices, e.g. when 10 threads seeming insufficient budget at the same time, assuming each of them claim 100 budget, in old algorithm all of the 10 threads forcefully claim the budget and result in `-1000` budget, them it need other mutators to release at least `1000` or they have to wait for up to 10ms even they may be woken up by the ShenandoahPeriodicPacerNotifyTask. In new algorithm, each threads will try to claim 100 budget every 1ms and don't need to wait other mutators to release at least `1000`, as soon as enough budget(>100) is returned, some thread(s) will compete others and proceed.

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

PR Comment: https://git.openjdk.org/jdk/pull/21099#issuecomment-2364322181

From xpeng at openjdk.org  Fri Sep 20 18:51:35 2024
From: xpeng at openjdk.org (Xiaolong Peng)
Date: Fri, 20 Sep 2024 18:51:35 GMT
Subject: RFR: 8340490: Shenandoah: Optimize ShenandoahPacer [v2]
In-Reply-To: <61bsu02-sDgUFx45vjC3xAvAaDtIY405Qm8lh3Edp28=.5a1c2d42-a51c-4014-b5e3-64cbd02786ed@github.com>
References: <mh4-1fuv1_9n0e_BCeIX-WHnXZN-1A7woAkyJinXkIU=.c03edc09-82fc-44c2-b09b-22d543fb4ec4@github.com>
 <61bsu02-sDgUFx45vjC3xAvAaDtIY405Qm8lh3Edp28=.5a1c2d42-a51c-4014-b5e3-64cbd02786ed@github.com>
Message-ID: <p1_dfGVCQ8Hswy1n4E2HPW22LVPjwPVba5cecSQxrPg=.22aeb487-488f-46e7-a86a-be1f4a6baedd@github.com>

On Fri, 20 Sep 2024 18:27:20 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> I am good with this, assuming performance runs show good results.

Latency wise, in most time it is better than old impl. 

In my specific test with 8G heap on MacOS, throughput is very close to the test w/ ShenandoahPacing disabled, and about 25%~30% improvement comparing the old implementation.

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

PR Comment: https://git.openjdk.org/jdk/pull/21099#issuecomment-2364332905

From coleenp at openjdk.org  Fri Sep 20 19:02:49 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 20 Sep 2024 19:02:49 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v9]
In-Reply-To: <BNQiyA0NCBO-oFZU4Nz3yvaMxDzICFxfqDKWt4wCL_U=.9405414d-f961-4168-8d26-ef5f58069161@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <6Rant6SjxpFIHHWNthWc_plOdnGpWPvqj3rxRe144po=.bcdbad7a-e93a-41a3-b958-6ae602c7e083@github.com>
 <NR6CKOtdUaVarB7hiAUIAsIMe03qiTQr5VcEOWGt8mA=.164efc10-f0ff-4ddf-80b8-c56599c0ba7d@github.com>
 <BNQiyA0NCBO-oFZU4Nz3yvaMxDzICFxfqDKWt4wCL_U=.9405414d-f961-4168-8d26-ef5f58069161@github.com>
Message-ID: <UQKdVMOsFJuEegNqlRHnj7Cqyo_MCOKpCiL30W_KWjk=.26f653ea-4858-4748-b374-454610acd3bd@github.com>

On Wed, 18 Sep 2024 12:54:34 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> src/hotspot/share/oops/markWord.inline.hpp line 90:
>> 
>>> 88:   ShouldNotReachHere();
>>> 89:   return markWord();
>>> 90: #endif
>> 
>> Is the ifdef _LP64 necessary, since UseCompactObjectHeaders should always be false for 32 bits?
>
> Kindof. The problem is that klass_shift is larger than 31, and shifting with it would thus be UB and generate a compiler warning. I opted to simply not compile any of that code in 32bit builds. We could also define klass_shift differently on 32bit.
> Long-term (maybe with Lilliput2/4-byte-headers?) it would be nice to consolidate the header layout between 32 and 64 bit builds and not make any distinction anywhere. E.g. define markWord (or objectHeader?) in a single way, and use that to extract all the relevant stuff. It's not totally unlikely that we deprecate 32-bit builds before that can happen, though.

Ok.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1769069007

From coleenp at openjdk.org  Fri Sep 20 19:09:50 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 20 Sep 2024 19:09:50 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v9]
In-Reply-To: <2w9H6VAbxm7BgSGRwKAxbI56bG-k4bE_ZDviGrBF36o=.3d4cb47f-0f84-479a-a809-6d0186dfad2d@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <6Rant6SjxpFIHHWNthWc_plOdnGpWPvqj3rxRe144po=.bcdbad7a-e93a-41a3-b958-6ae602c7e083@github.com>
 <NR6CKOtdUaVarB7hiAUIAsIMe03qiTQr5VcEOWGt8mA=.164efc10-f0ff-4ddf-80b8-c56599c0ba7d@github.com>
 <BNQiyA0NCBO-oFZU4Nz3yvaMxDzICFxfqDKWt4wCL_U=.9405414d-f961-4168-8d26-ef5f58069161@github.com>
 <igBchd3diNsHdnQwZS2sj4tjaKejOq4f4EZovOmpmRQ=.abf79fee-9592-4555-ac01-de0170665ae4@github.com>
 <BkuKSFHleaF8I2tWCDIC-rGlWnfGhbK1zQ6CLlB-rVE=.9c7976e3-b0e9-4356-8d4b-d880aa30bffa@github.com>
 <ubcY5Q-aPRCLmhZV9MjBfzzbs84FegDvNkHx8nwPUd0=.46503fd8-d274-4558-bd0f-cc0c4f199667@github.com>
 <2w9H6VAbxm7BgSGRwKAxbI56bG-k4bE_ZDviGrBF36o=.3d4cb47f-0f84-479a-a809-6d0186dfad2d@github.com>
Message-ID: <VLGyxnaSrbWp2xvih098AS__7lRE9tBq5hk8QhHSK94=.be7bb13d-7001-48ba-a1a9-8952b43873fc@github.com>

On Thu, 19 Sep 2024 14:22:51 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> We haven't decided whether or not we will git rid of ```Klass::_prototype_header``` before intergrating this PR, or not. @stefank could point you to a WIP branch, if that's helpful.
>
> This is my current work-in-progress code:
> https://github.com/stefank/jdk/compare/pull/20677...stefank:jdk:lilliput_remove_prototype_header_wip_2
> 
> I've made some large rewrites and I'm currently running it through functional testing.

The refactoring is better in this last version with encode_and_store_compact_object_header, although some comments around the c2 version would be good.  Still don't know what the c2 version does.  Someone else should review that.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1769075714

From wkemper at openjdk.org  Fri Sep 20 21:09:21 2024
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 20 Sep 2024 21:09:21 GMT
Subject: RFR: 8339616: GenShen: Introduce new state to distinguish
 promote-in-place phase as distinct from concurrent evacuation
Message-ID: <aIsN7f4PqFD3OyCLy71olfuSQHgZqiWm7DuQ41CAlfQ=.66676bc3-eba6-4b32-801a-a43fc7dc52b2@github.com>

The generational mode for Shenandoah is able to promote regions in place (effectively moving an entire region of live objects, without evacuating any objects). It does this during a normal evacuation phase. However, in some cases, Shenandoah may choose to skip the evacuation phase, _even when there are entire regions to promote_. Prior to this PR, Shenandoah would essentially force itself into an evacuation phase, with nothing to evacuate. Though this was expedient, it cause all manner of knock-on effects and unintended consequences with barriers and asserts and the state of the heap. Here, we have reverted that business and created a path for this special "only doing in place promotions" cycle that does not cause the heap to expect to evacuate objects or find forwarding pointers in them.

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

Commit messages:
 - Handle cancellation corner case, improve names and comments
 - Change size verification mode when there are only in-place promotions after final mark
 - Do not treat promote-in-place only as an evacuation phase
 - Merge remote-tracking branch 'shenandoah/master' into restore-barrier-fwd-assert
 - Remove misleading comment, restore original assert

Changes: https://git.openjdk.org/shenandoah/pull/503/files
  Webrev: https://webrevs.openjdk.org/?repo=shenandoah&pr=503&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8339616
  Stats: 86 lines in 8 files changed: 48 ins; 18 del; 20 mod
  Patch: https://git.openjdk.org/shenandoah/pull/503.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah.git pull/503/head:pull/503

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

From kdnilsen at openjdk.org  Fri Sep 20 21:28:55 2024
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Fri, 20 Sep 2024 21:28:55 GMT
Subject: RFR: 8339616: GenShen: Introduce new state to distinguish
 promote-in-place phase as distinct from concurrent evacuation
In-Reply-To: <aIsN7f4PqFD3OyCLy71olfuSQHgZqiWm7DuQ41CAlfQ=.66676bc3-eba6-4b32-801a-a43fc7dc52b2@github.com>
References: <aIsN7f4PqFD3OyCLy71olfuSQHgZqiWm7DuQ41CAlfQ=.66676bc3-eba6-4b32-801a-a43fc7dc52b2@github.com>
Message-ID: <28_b0IU7E1EZnjNmZm7a85wzUBCDcZeudwfP8qcgW6w=.a4ec348e-8843-4657-b78d-4628ca7ab926@github.com>

On Fri, 20 Sep 2024 21:04:50 GMT, William Kemper <wkemper at openjdk.org> wrote:

> The generational mode for Shenandoah is able to promote regions in place (effectively moving an entire region of live objects, without evacuating any objects). It does this during a normal evacuation phase. However, in some cases, Shenandoah may choose to skip the evacuation phase, _even when there are entire regions to promote_. Prior to this PR, Shenandoah would essentially force itself into an evacuation phase, with nothing to evacuate. Though this was expedient, it cause all manner of knock-on effects and unintended consequences with barriers and asserts and the state of the heap. Here, we have reverted that business and created a path for this special "only doing in place promotions" cycle that does not cause the heap to expect to evacuate objects or find forwarding pointers in them.

Marked as reviewed by kdnilsen (Committer).

src/hotspot/share/gc/shenandoah/shenandoahConcurrentGC.cpp line 539:

> 537: 
> 538:   // Ultimately, the same closure handles in-place promotions for tenured regions. No objects will be moved.
> 539:   // The threads will still participate in the oom-evac-protocol, although no memory will be allocated for

Since there is no allocation for promote-in-place promotions, it seems there would be no need for these threads to participate in oom-evac protocol.  (But maybe they still monitor the conditions that would indicate oom-evac just so we can reuse the same code.)

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

PR Review: https://git.openjdk.org/shenandoah/pull/503#pullrequestreview-2319381049
PR Review Comment: https://git.openjdk.org/shenandoah/pull/503#discussion_r1769270584

From wkemper at openjdk.org  Fri Sep 20 21:33:32 2024
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 20 Sep 2024 21:33:32 GMT
Subject: RFR: Merge openjdk/jdk:master [v2]
In-Reply-To: <k3izQynGjwMOhJNjpvcUIVd7_5WPxy856Fnm3Ar_qYE=.5e40a077-4d3e-4d68-8275-0f78707a8d77@github.com>
References: <k3izQynGjwMOhJNjpvcUIVd7_5WPxy856Fnm3Ar_qYE=.5e40a077-4d3e-4d68-8275-0f78707a8d77@github.com>
Message-ID: <Gj35Vl3nUyv8snkYEpM6_NeEpc8zyybje-Vgyn42WMo=.8155dba2-e036-4e42-a661-9fcc216b3aff@github.com>

> Merges tag jdk-24+16

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

 - Merge remote-tracking branch 'shenandoah/master' into merge-jdk-24+16
 - 8340276: Test java/lang/management/ThreadMXBean/Locks.java failed with NullPointerException
   
   Reviewed-by: cjplummer, lmesnik
 - 8286851: Deprecate for removal several of the undocumented java launcher options
   
   Reviewed-by: dholmes
 - 8339416: [s390x] Provide implementation for resolve_global_jobject
   
   Reviewed-by: mdoerr, lucy
 - 8339980: [s390x] ProblemList jdk/java/util/zip/CloseInflaterDeflaterTest.java
   
   Reviewed-by: lucy
 - 8340360: Update -mx to -Xmx in UnninstallUIMemoryLeaks test
   
   Reviewed-by: serb, prr
 - 8340078: Open source several 2D tests
   
   Reviewed-by: honkar
 - 8339962: Open source AWT TextField tests - Set1
   
   Reviewed-by: jdv, dnguyen, prr
 - 8340391: Windows jcmd System.map and System.dump_map tests failing
   
   Reviewed-by: cjplummer
 - 8340233: Missed ThreadWXEnable in jfrNativeLibraryLoadEvent.cpp
   
   Reviewed-by: mgronlun
 - ... and 79 more: https://git.openjdk.org/shenandoah/compare/d1bc34fb...f7ef5ebc

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

Changes: https://git.openjdk.org/shenandoah/pull/502/files
  Webrev: https://webrevs.openjdk.org/?repo=shenandoah&pr=502&range=01
  Stats: 148140 lines in 607 files changed: 143202 ins; 2003 del; 2935 mod
  Patch: https://git.openjdk.org/shenandoah/pull/502.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah.git pull/502/head:pull/502

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

From wkemper at openjdk.org  Fri Sep 20 21:36:07 2024
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 20 Sep 2024 21:36:07 GMT
Subject: RFR: 8339616: GenShen: Introduce new state to distinguish
 promote-in-place phase as distinct from concurrent evacuation
In-Reply-To: <28_b0IU7E1EZnjNmZm7a85wzUBCDcZeudwfP8qcgW6w=.a4ec348e-8843-4657-b78d-4628ca7ab926@github.com>
References: <aIsN7f4PqFD3OyCLy71olfuSQHgZqiWm7DuQ41CAlfQ=.66676bc3-eba6-4b32-801a-a43fc7dc52b2@github.com>
 <28_b0IU7E1EZnjNmZm7a85wzUBCDcZeudwfP8qcgW6w=.a4ec348e-8843-4657-b78d-4628ca7ab926@github.com>
Message-ID: <i3bYVec0FD1SqCYmGTtM7liLaRmpHhJPhh2qxajjXZs=.4d72e9a2-fe1f-4599-b613-14464c16b1b3@github.com>

On Fri, 20 Sep 2024 21:22:54 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> The generational mode for Shenandoah is able to promote regions in place (effectively moving an entire region of live objects, without evacuating any objects). It does this during a normal evacuation phase. However, in some cases, Shenandoah may choose to skip the evacuation phase, _even when there are entire regions to promote_. Prior to this PR, Shenandoah would essentially force itself into an evacuation phase, with nothing to evacuate. Though this was expedient, it cause all manner of knock-on effects and unintended consequences with barriers and asserts and the state of the heap. Here, we have reverted that business and created a path for this special "only doing in place promotions" cycle that does not cause the heap to expect to evacuate objects or find forwarding pointers in them.
>
> src/hotspot/share/gc/shenandoah/shenandoahConcurrentGC.cpp line 539:
> 
>> 537: 
>> 538:   // Ultimately, the same closure handles in-place promotions for tenured regions. No objects will be moved.
>> 539:   // The threads will still participate in the oom-evac-protocol, although no memory will be allocated for
> 
> Since there is no allocation for promote-in-place promotions, it seems there would be no need for these threads to participate in oom-evac protocol.  (But maybe they still monitor the conditions that would indicate oom-evac just so we can reuse the same code.)

Yes, I was being lazy for the sake of code reuse. This also only happens when it is an abbreviate cycle _and_ there are regions to promote. I'll see what it looks like to not enter the oom-evac-protocol for this case.

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

PR Review Comment: https://git.openjdk.org/shenandoah/pull/503#discussion_r1769277338

From wkemper at openjdk.org  Fri Sep 20 23:11:22 2024
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 20 Sep 2024 23:11:22 GMT
Subject: RFR: 8339616: GenShen: Introduce new state to distinguish
 promote-in-place phase as distinct from concurrent evacuation [v2]
In-Reply-To: <aIsN7f4PqFD3OyCLy71olfuSQHgZqiWm7DuQ41CAlfQ=.66676bc3-eba6-4b32-801a-a43fc7dc52b2@github.com>
References: <aIsN7f4PqFD3OyCLy71olfuSQHgZqiWm7DuQ41CAlfQ=.66676bc3-eba6-4b32-801a-a43fc7dc52b2@github.com>
Message-ID: <p0OKDQA4gzb8ma9L0JIg2PAeYE0utMoN9pkdubZpDdM=.b68eb985-8421-4c3e-8c50-7a2afe660f01@github.com>

> The generational mode for Shenandoah is able to promote regions in place (effectively moving an entire region of live objects, without evacuating any objects). It does this during a normal evacuation phase. However, in some cases, Shenandoah may choose to skip the evacuation phase, _even when there are entire regions to promote_. Prior to this PR, Shenandoah would essentially force itself into an evacuation phase, with nothing to evacuate. Though this was expedient, it cause all manner of knock-on effects and unintended consequences with barriers and asserts and the state of the heap. Here, we have reverted that business and created a path for this special "only doing in place promotions" cycle that does not cause the heap to expect to evacuate objects or find forwarding pointers in them.

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

  Do not enter oom-during-evac protocol when only promoting regions in place

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

Changes:
  - all: https://git.openjdk.org/shenandoah/pull/503/files
  - new: https://git.openjdk.org/shenandoah/pull/503/files/ffc2926e..0ed07e92

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

  Stats: 45 lines in 8 files changed: 26 ins; 11 del; 8 mod
  Patch: https://git.openjdk.org/shenandoah/pull/503.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah.git pull/503/head:pull/503

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

From shade at openjdk.org  Sat Sep 21 05:54:42 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Sat, 21 Sep 2024 05:54:42 GMT
Subject: RFR: 8340490: Shenandoah: Optimize ShenandoahPacer [v2]
In-Reply-To: <p1_dfGVCQ8Hswy1n4E2HPW22LVPjwPVba5cecSQxrPg=.22aeb487-488f-46e7-a86a-be1f4a6baedd@github.com>
References: <mh4-1fuv1_9n0e_BCeIX-WHnXZN-1A7woAkyJinXkIU=.c03edc09-82fc-44c2-b09b-22d543fb4ec4@github.com>
 <61bsu02-sDgUFx45vjC3xAvAaDtIY405Qm8lh3Edp28=.5a1c2d42-a51c-4014-b5e3-64cbd02786ed@github.com>
 <p1_dfGVCQ8Hswy1n4E2HPW22LVPjwPVba5cecSQxrPg=.22aeb487-488f-46e7-a86a-be1f4a6baedd@github.com>
Message-ID: <Xf89-L8wLAMbngt5PxoN3B0sX94chZQz5zjqfuiBYZM=.6c6387e8-572a-4c47-8de2-d4f407924c88@github.com>

On Fri, 20 Sep 2024 18:48:45 GMT, Xiaolong Peng <xpeng at openjdk.org> wrote:

> > I am good with this, assuming performance runs show good results.
> 
> Latency wise, in most time it is better than old impl.

It is great it improves targeted tests, and it makes sense from the first principles. Run our usual performance pipeline to sanity check if this affects any other benchmarks in any meaningful way.

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

PR Comment: https://git.openjdk.org/jdk/pull/21099#issuecomment-2365015599

From stuefe at openjdk.org  Sun Sep 22 12:01:51 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Sun, 22 Sep 2024 12:01:51 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v6]
In-Reply-To: <prghUAoX81SehIWD3kZW80POXP-2FuDwqTO2XaVZFDo=.8861307e-4f8d-4690-ac08-fb2e1923471e@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <BGmZ04yibLn_KtPyQrA3sQv5OtMonrcDy3aN0vAj8NA=.5de6cae3-3a05-4a74-a15c-aade4176bdeb@github.com>
 <prghUAoX81SehIWD3kZW80POXP-2FuDwqTO2XaVZFDo=.8861307e-4f8d-4690-ac08-fb2e1923471e@github.com>
Message-ID: <VBo_MMmdcMSNwpXxmwt4i0qTN8WWvzguRIWGgMIeBNs=.b9131817-3f3e-446a-a5f4-021251136431@github.com>

On Fri, 20 Sep 2024 16:56:58 GMT, Matias Saavedra Silva <matsaave at openjdk.org> wrote:

>> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix bit counts in GCForwarding
>
> src/hotspot/share/cds/archiveUtils.cpp line 348:
> 
>> 346:   old_tag = (int)(intptr_t)nextPtr();
>> 347:   // do_int(&old_tag);
>> 348:   assert(tag == old_tag, "tag doesn't match (%d, expected %d)", old_tag, tag);
> 
> Is this assert message change a leftover from debugging or is it meant to be this way?

Its a leftover, but otoh it does not hurt. I found myself re-adding it several times to analyze CDS issues during development, so I decided to just leave it in.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1770536320

From zgu at openjdk.org  Mon Sep 23 12:37:36 2024
From: zgu at openjdk.org (Zhengyu Gu)
Date: Mon, 23 Sep 2024 12:37:36 GMT
Subject: RFR: 8340408: Shenandoah: Remove redundant task stats printing
 code in ShenandoahTaskQueue
In-Reply-To: <b8j5T3wNtPN9ysHoj8pDP3c3oWWnWG25E1gDGk1SpIs=.fc6b14f8-af4b-4dc1-a624-044957b4e61a@github.com>
References: <6PiT6kRNGaQjkJTNknVTqMV14SyYXwFosAz9Ts3Emfk=.46c01286-6733-424c-a0d6-e6ff8aa4726c@github.com>
 <b8j5T3wNtPN9ysHoj8pDP3c3oWWnWG25E1gDGk1SpIs=.fc6b14f8-af4b-4dc1-a624-044957b4e61a@github.com>
Message-ID: <dn5pBKouiC38iMzyt1yR6YAakV_lMs0JdhdREVpqsZw=.e24b27d9-3bbe-439f-9d97-64dbced92444@github.com>

On Thu, 19 Sep 2024 21:46:43 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> [JDK-8280397](https://bugs.openjdk.org/browse/JDK-8280397) made the code redundant. 
>> 
>> Adopt shared implementation.
>
> src/hotspot/share/gc/shenandoah/shenandoahConcurrentMark.cpp line 228:
> 
>> 226:   finish_mark_work();
>> 227:   assert(task_queues()->is_empty(), "Should be empty");
>> 228:   TASKQUEUE_STATS_ONLY(task_queues()->print_and_reset_taskqueue_stats(""));
> 
> Could we pass `"Finish Mark"` for the label here.

The label is used for queue names in other GCs, instead of phases. I passed empty string to be consistent with old label.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21077#discussion_r1771319732

From rkennke at openjdk.org  Mon Sep 23 14:30:41 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Mon, 23 Sep 2024 14:30:41 GMT
Subject: RFR: 8340183: Shenandoah: Incorrect match for clone barrier in
 is_gc_barrier_node
In-Reply-To: <lMJ7zz1QZt3FMIqVLhEpYe6aqMc_uqU_d0P2mWQI4IY=.136a8eb3-b7ae-43f4-b268-5f7a6d189e09@github.com>
References: <lMJ7zz1QZt3FMIqVLhEpYe6aqMc_uqU_d0P2mWQI4IY=.136a8eb3-b7ae-43f4-b268-5f7a6d189e09@github.com>
Message-ID: <56gDsD_PGk6_iCgfzeI2NIEC-FpUrjRyW8WUzKy5oXs=.5965cafb-3926-4134-88e6-6d9cf72fef1d@github.com>

On Mon, 16 Sep 2024 10:35:15 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> The name of the call we emit is "shenandoah_clone":
> https://github.com/openjdk/jdk/blob/545951889c1ea68646be600decaf2bf4c049600b/src/hotspot/share/gc/shenandoah/c2/shenandoahBarrierSetC2.cpp#L806
> 
> ...yet we test for "shenandoah_clone_barrier" here:
> https://github.com/openjdk/jdk/blob/545951889c1ea68646be600decaf2bf4c049600b/src/hotspot/share/gc/shenandoah/c2/shenandoahBarrierSetC2.cpp#L688
> 
> I think we are better off polling the call target instead of relying on call name. This change also eliminates `shenandoah_cas_obj` matcher, for which we do not have the emitted call ever since we started doing CAS expansions inline.
> 
> Additional testing:
>  - [x] Linux x86_64 server fastdebug, `hotspot_gc_shenandoah`
>  - [ ] Linux x86_64 server fastdebug, `all` with `-XX:+UseShenandoahGC`

Looks good, thank you!

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

Marked as reviewed by rkennke (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21014#pullrequestreview-2322461615

From shade at openjdk.org  Mon Sep 23 14:35:41 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 23 Sep 2024 14:35:41 GMT
Subject: RFR: 8340183: Shenandoah: Incorrect match for clone barrier in
 is_gc_barrier_node
In-Reply-To: <lMJ7zz1QZt3FMIqVLhEpYe6aqMc_uqU_d0P2mWQI4IY=.136a8eb3-b7ae-43f4-b268-5f7a6d189e09@github.com>
References: <lMJ7zz1QZt3FMIqVLhEpYe6aqMc_uqU_d0P2mWQI4IY=.136a8eb3-b7ae-43f4-b268-5f7a6d189e09@github.com>
Message-ID: <Lh5UMiuFh_ThUfKAXgVpnP8MS5TCdz03WqoYJD28CoI=.86bc7534-600a-413e-a471-4460826a1be4@github.com>

On Mon, 16 Sep 2024 10:35:15 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> The name of the call we emit is "shenandoah_clone":
> https://github.com/openjdk/jdk/blob/545951889c1ea68646be600decaf2bf4c049600b/src/hotspot/share/gc/shenandoah/c2/shenandoahBarrierSetC2.cpp#L806
> 
> ...yet we test for "shenandoah_clone_barrier" here:
> https://github.com/openjdk/jdk/blob/545951889c1ea68646be600decaf2bf4c049600b/src/hotspot/share/gc/shenandoah/c2/shenandoahBarrierSetC2.cpp#L688
> 
> I think we are better off polling the call target instead of relying on call name. This change also eliminates `shenandoah_cas_obj` matcher, for which we do not have the emitted call ever since we started doing CAS expansions inline.
> 
> Additional testing:
>  - [x] Linux x86_64 server fastdebug, `hotspot_gc_shenandoah`
>  - [ ] Linux x86_64 server fastdebug, `all` with `-XX:+UseShenandoahGC`

Thanks!

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

PR Comment: https://git.openjdk.org/jdk/pull/21014#issuecomment-2368467997

From shade at openjdk.org  Mon Sep 23 14:35:42 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 23 Sep 2024 14:35:42 GMT
Subject: Integrated: 8340183: Shenandoah: Incorrect match for clone barrier in
 is_gc_barrier_node
In-Reply-To: <lMJ7zz1QZt3FMIqVLhEpYe6aqMc_uqU_d0P2mWQI4IY=.136a8eb3-b7ae-43f4-b268-5f7a6d189e09@github.com>
References: <lMJ7zz1QZt3FMIqVLhEpYe6aqMc_uqU_d0P2mWQI4IY=.136a8eb3-b7ae-43f4-b268-5f7a6d189e09@github.com>
Message-ID: <Y6P4jC25XkAQoNTV3KcizrE8jZtmZFPCdjkbbhpzXYo=.6386e4ad-8393-49b4-8e85-4d1f5464731f@github.com>

On Mon, 16 Sep 2024 10:35:15 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> The name of the call we emit is "shenandoah_clone":
> https://github.com/openjdk/jdk/blob/545951889c1ea68646be600decaf2bf4c049600b/src/hotspot/share/gc/shenandoah/c2/shenandoahBarrierSetC2.cpp#L806
> 
> ...yet we test for "shenandoah_clone_barrier" here:
> https://github.com/openjdk/jdk/blob/545951889c1ea68646be600decaf2bf4c049600b/src/hotspot/share/gc/shenandoah/c2/shenandoahBarrierSetC2.cpp#L688
> 
> I think we are better off polling the call target instead of relying on call name. This change also eliminates `shenandoah_cas_obj` matcher, for which we do not have the emitted call ever since we started doing CAS expansions inline.
> 
> Additional testing:
>  - [x] Linux x86_64 server fastdebug, `hotspot_gc_shenandoah`
>  - [ ] Linux x86_64 server fastdebug, `all` with `-XX:+UseShenandoahGC`

This pull request has now been integrated.

Changeset: ea8f35b9
Author:    Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ea8f35b98e618bfa55371e45b3ef61fa5289dd94
Stats:     20 lines in 3 files changed: 6 ins; 10 del; 4 mod

8340183: Shenandoah: Incorrect match for clone barrier in is_gc_barrier_node

Reviewed-by: roland, rkennke

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

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

From wkemper at openjdk.org  Mon Sep 23 17:17:34 2024
From: wkemper at openjdk.org (William Kemper)
Date: Mon, 23 Sep 2024 17:17:34 GMT
Subject: RFR: 8340408: Shenandoah: Remove redundant task stats printing
 code in ShenandoahTaskQueue
In-Reply-To: <6PiT6kRNGaQjkJTNknVTqMV14SyYXwFosAz9Ts3Emfk=.46c01286-6733-424c-a0d6-e6ff8aa4726c@github.com>
References: <6PiT6kRNGaQjkJTNknVTqMV14SyYXwFosAz9Ts3Emfk=.46c01286-6733-424c-a0d6-e6ff8aa4726c@github.com>
Message-ID: <M0N8WW5VcJLovtxOJKwFMl0Mtpi9xvBhlgUg-ZYaEaM=.9c64f316-c138-4bef-a6ab-cac3260ef334@github.com>

On Thu, 19 Sep 2024 00:33:04 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> [JDK-8280397](https://bugs.openjdk.org/browse/JDK-8280397) made the code redundant. 
> 
> Adopt shared implementation.

Marked as reviewed by wkemper (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/21077#pullrequestreview-2322876022

From wkemper at openjdk.org  Mon Sep 23 17:17:35 2024
From: wkemper at openjdk.org (William Kemper)
Date: Mon, 23 Sep 2024 17:17:35 GMT
Subject: RFR: 8340408: Shenandoah: Remove redundant task stats printing
 code in ShenandoahTaskQueue
In-Reply-To: <dn5pBKouiC38iMzyt1yR6YAakV_lMs0JdhdREVpqsZw=.e24b27d9-3bbe-439f-9d97-64dbced92444@github.com>
References: <6PiT6kRNGaQjkJTNknVTqMV14SyYXwFosAz9Ts3Emfk=.46c01286-6733-424c-a0d6-e6ff8aa4726c@github.com>
 <b8j5T3wNtPN9ysHoj8pDP3c3oWWnWG25E1gDGk1SpIs=.fc6b14f8-af4b-4dc1-a624-044957b4e61a@github.com>
 <dn5pBKouiC38iMzyt1yR6YAakV_lMs0JdhdREVpqsZw=.e24b27d9-3bbe-439f-9d97-64dbced92444@github.com>
Message-ID: <WKZQMA4H0GiO6DFwQPdvQ5fiM4gLukIRZW4rpLl1nRo=.218b9316-6495-4426-8dfc-8ee3d6d7fb98@github.com>

On Mon, 23 Sep 2024 12:35:16 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

>> src/hotspot/share/gc/shenandoah/shenandoahConcurrentMark.cpp line 228:
>> 
>>> 226:   finish_mark_work();
>>> 227:   assert(task_queues()->is_empty(), "Should be empty");
>>> 228:   TASKQUEUE_STATS_ONLY(task_queues()->print_and_reset_taskqueue_stats(""));
>> 
>> Could we pass `"Finish Mark"` for the label here.
>
> The label is used for queue names in other GCs, instead of phases. I passed empty string to be consistent with old label.

Okay.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21077#discussion_r1771815824

From shade at openjdk.org  Mon Sep 23 17:26:37 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 23 Sep 2024 17:26:37 GMT
Subject: RFR: 8340408: Shenandoah: Remove redundant task stats printing
 code in ShenandoahTaskQueue
In-Reply-To: <6PiT6kRNGaQjkJTNknVTqMV14SyYXwFosAz9Ts3Emfk=.46c01286-6733-424c-a0d6-e6ff8aa4726c@github.com>
References: <6PiT6kRNGaQjkJTNknVTqMV14SyYXwFosAz9Ts3Emfk=.46c01286-6733-424c-a0d6-e6ff8aa4726c@github.com>
Message-ID: <nnnTNDbAJwVdzMij-79dhOPpMRu55AYW_S9Z0yEsmho=.a1cbc740-9182-4004-8cf9-9a8a112420a1@github.com>

On Thu, 19 Sep 2024 00:33:04 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> [JDK-8280397](https://bugs.openjdk.org/browse/JDK-8280397) made the code redundant. 
> 
> Adopt shared implementation.

Marked as reviewed by shade (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/21077#pullrequestreview-2322894077

From wkemper at openjdk.org  Mon Sep 23 17:27:04 2024
From: wkemper at openjdk.org (William Kemper)
Date: Mon, 23 Sep 2024 17:27:04 GMT
Subject: Integrated: Merge openjdk/jdk:master
In-Reply-To: <k3izQynGjwMOhJNjpvcUIVd7_5WPxy856Fnm3Ar_qYE=.5e40a077-4d3e-4d68-8275-0f78707a8d77@github.com>
References: <k3izQynGjwMOhJNjpvcUIVd7_5WPxy856Fnm3Ar_qYE=.5e40a077-4d3e-4d68-8275-0f78707a8d77@github.com>
Message-ID: <G4uTb71yIRGYSKo4FP82HP0K6ILecTTUjb2QqNB7zQg=.e01ed79e-ca68-492b-8e07-b0d6b1e22051@github.com>

On Fri, 20 Sep 2024 14:12:48 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Merges tag jdk-24+16

This pull request has now been integrated.

Changeset: 22824daf
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.org/shenandoah/commit/22824dafdfd0997162e29b1257e8b862feb91181
Stats:     148140 lines in 607 files changed: 143202 ins; 2003 del; 2935 mod

Merge

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

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

From shade at openjdk.org  Mon Sep 23 18:11:07 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 23 Sep 2024 18:11:07 GMT
Subject: RFR: 8339616: GenShen: Introduce new state to distinguish
 promote-in-place phase as distinct from concurrent evacuation [v2]
In-Reply-To: <p0OKDQA4gzb8ma9L0JIg2PAeYE0utMoN9pkdubZpDdM=.b68eb985-8421-4c3e-8c50-7a2afe660f01@github.com>
References: <aIsN7f4PqFD3OyCLy71olfuSQHgZqiWm7DuQ41CAlfQ=.66676bc3-eba6-4b32-801a-a43fc7dc52b2@github.com>
 <p0OKDQA4gzb8ma9L0JIg2PAeYE0utMoN9pkdubZpDdM=.b68eb985-8421-4c3e-8c50-7a2afe660f01@github.com>
Message-ID: <DvGMki7MVDvhtxldguSA7o68mIiHr66HGn0ce5S3dW8=.ba31a76e-f215-4762-8362-afcff980d26e@github.com>

On Fri, 20 Sep 2024 23:11:22 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> The generational mode for Shenandoah is able to promote regions in place (effectively moving an entire region of live objects, without evacuating any objects). It does this during a normal evacuation phase. However, in some cases, Shenandoah may choose to skip the evacuation phase, _even when there are entire regions to promote_. Prior to this PR, Shenandoah would essentially force itself into an evacuation phase, with nothing to evacuate. Though this was expedient, it caused all manner of knock-on effects and unintended consequences with barriers and asserts and the state of the heap. Here, we have reverted that business and created a path for this special "only doing in place promotions" cycle that does not cause the heap to expect to evacuate objects or find forwarding pointers in them.
>
> William Kemper has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Do not enter oom-during-evac protocol when only promoting regions in place

Looks okay, but a few cosmetics:

src/hotspot/share/gc/shenandoah/shenandoahGenerationalEvacuationTask.cpp line 82:

> 80:   if (_only_promote_regions) {
> 81:     // No allocations will be made, do not enter oom-during-evac protocol.
> 82:     do_evacuations();

It really looks to me that promotion-in-place should be in a separate task? Or the name of the task should reflect it also does promotions? Or at least the "real evacuation" paths in `do_evacuations` be asserted with `!_only_promote_regions`?

src/hotspot/share/gc/shenandoah/shenandoahVerifier.cpp line 1082:

> 1080:           _verify_liveness_complete,   // liveness data must be complete here
> 1081:           _verify_regions_disable,     // trash regions not yet recycled
> 1082:           sizeness,          // expect generation and heap sizes to match exactly

So... the comment is outdated? I suggest to split `ShenandoahVerifier::verify_after_concmark` into two methods, and clearly point out the expected state in comments then.

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

Marked as reviewed by shade (Committer).

PR Review: https://git.openjdk.org/shenandoah/pull/503#pullrequestreview-2322981435
PR Review Comment: https://git.openjdk.org/shenandoah/pull/503#discussion_r1771876993
PR Review Comment: https://git.openjdk.org/shenandoah/pull/503#discussion_r1771879017

From ysr at openjdk.org  Mon Sep 23 19:28:57 2024
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Mon, 23 Sep 2024 19:28:57 GMT
Subject: RFR: 8339616: GenShen: Introduce new state to distinguish
 promote-in-place phase as distinct from concurrent evacuation [v2]
In-Reply-To: <p0OKDQA4gzb8ma9L0JIg2PAeYE0utMoN9pkdubZpDdM=.b68eb985-8421-4c3e-8c50-7a2afe660f01@github.com>
References: <aIsN7f4PqFD3OyCLy71olfuSQHgZqiWm7DuQ41CAlfQ=.66676bc3-eba6-4b32-801a-a43fc7dc52b2@github.com>
 <p0OKDQA4gzb8ma9L0JIg2PAeYE0utMoN9pkdubZpDdM=.b68eb985-8421-4c3e-8c50-7a2afe660f01@github.com>
Message-ID: <qzcVG8SqZTJlqcrk6Uh4ENIXvqp_0OdzMc6FUq931e8=.8b833571-6e54-4dd1-abd0-d0020dcc22d1@github.com>

On Fri, 20 Sep 2024 23:11:22 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> The generational mode for Shenandoah is able to promote regions in place (effectively moving an entire region of live objects, without evacuating any objects). It does this during a normal evacuation phase. However, in some cases, Shenandoah may choose to skip the evacuation phase, _even when there are entire regions to promote_. Prior to this PR, Shenandoah would essentially force itself into an evacuation phase, with nothing to evacuate. Though this was expedient, it caused all manner of knock-on effects and unintended consequences with barriers and asserts and the state of the heap. Here, we have reverted that business and created a path for this special "only doing in place promotions" cycle that does not cause the heap to expect to evacuate objects or find forwarding pointers in them.
>
> William Kemper has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Do not enter oom-during-evac protocol when only promoting regions in place

src/hotspot/share/gc/shenandoah/shenandoahConcurrentGC.cpp line 526:

> 524: void ShenandoahConcurrentGC::entry_promote_in_place() {
> 525:   shenandoah_assert_generational();
> 526: 

Do you also want to assert that collection set is empty?

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

PR Review Comment: https://git.openjdk.org/shenandoah/pull/503#discussion_r1771966914

From ysr at openjdk.org  Mon Sep 23 19:35:08 2024
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Mon, 23 Sep 2024 19:35:08 GMT
Subject: RFR: 8339616: GenShen: Introduce new state to distinguish
 promote-in-place phase as distinct from concurrent evacuation [v2]
In-Reply-To: <p0OKDQA4gzb8ma9L0JIg2PAeYE0utMoN9pkdubZpDdM=.b68eb985-8421-4c3e-8c50-7a2afe660f01@github.com>
References: <aIsN7f4PqFD3OyCLy71olfuSQHgZqiWm7DuQ41CAlfQ=.66676bc3-eba6-4b32-801a-a43fc7dc52b2@github.com>
 <p0OKDQA4gzb8ma9L0JIg2PAeYE0utMoN9pkdubZpDdM=.b68eb985-8421-4c3e-8c50-7a2afe660f01@github.com>
Message-ID: <m6x4LqWneCwZGK_VlAkGtgX7G7xaZd7yNiotrl4HJIU=.d90b69c1-28c1-4e89-b895-9ccd550fb3be@github.com>

On Fri, 20 Sep 2024 23:11:22 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> The generational mode for Shenandoah is able to promote regions in place (effectively moving an entire region of live objects, without evacuating any objects). It does this during a normal evacuation phase. However, in some cases, Shenandoah may choose to skip the evacuation phase, _even when there are entire regions to promote_. Prior to this PR, Shenandoah would essentially force itself into an evacuation phase, with nothing to evacuate. Though this was expedient, it caused all manner of knock-on effects and unintended consequences with barriers and asserts and the state of the heap. Here, we have reverted that business and created a path for this special "only doing in place promotions" cycle that does not cause the heap to expect to evacuate objects or find forwarding pointers in them.
>
> William Kemper has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Do not enter oom-during-evac protocol when only promoting regions in place

Nice clean-up/disentaglement that makes for clearer and more maintainable code. Thank you!

Left a couple of comments/remarks.

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

Marked as reviewed by ysr (Committer).

PR Review: https://git.openjdk.org/shenandoah/pull/503#pullrequestreview-2323142361

From ysr at openjdk.org  Mon Sep 23 19:35:08 2024
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Mon, 23 Sep 2024 19:35:08 GMT
Subject: RFR: 8339616: GenShen: Introduce new state to distinguish
 promote-in-place phase as distinct from concurrent evacuation [v2]
In-Reply-To: <qzcVG8SqZTJlqcrk6Uh4ENIXvqp_0OdzMc6FUq931e8=.8b833571-6e54-4dd1-abd0-d0020dcc22d1@github.com>
References: <aIsN7f4PqFD3OyCLy71olfuSQHgZqiWm7DuQ41CAlfQ=.66676bc3-eba6-4b32-801a-a43fc7dc52b2@github.com>
 <p0OKDQA4gzb8ma9L0JIg2PAeYE0utMoN9pkdubZpDdM=.b68eb985-8421-4c3e-8c50-7a2afe660f01@github.com>
 <qzcVG8SqZTJlqcrk6Uh4ENIXvqp_0OdzMc6FUq931e8=.8b833571-6e54-4dd1-abd0-d0020dcc22d1@github.com>
Message-ID: <tNojpkJk6A5G3EfFYPKN1weyaTzUclWAjuyTwoPz1ko=.e7cd376a-20d8-48d3-84d0-5d9641874c71@github.com>

On Mon, 23 Sep 2024 19:25:45 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

>> William Kemper has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Do not enter oom-during-evac protocol when only promoting regions in place
>
> src/hotspot/share/gc/shenandoah/shenandoahConcurrentGC.cpp line 526:
> 
>> 524: void ShenandoahConcurrentGC::entry_promote_in_place() {
>> 525:   shenandoah_assert_generational();
>> 526: 
> 
> Do you also want to assert that collection set is empty?

The other approach might be to _always_ have a separate pre-evac phase that promotes in place before actual evac to follow (even when collection set is non-empty).

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

PR Review Comment: https://git.openjdk.org/shenandoah/pull/503#discussion_r1771971900

From wkemper at openjdk.org  Mon Sep 23 20:25:34 2024
From: wkemper at openjdk.org (William Kemper)
Date: Mon, 23 Sep 2024 20:25:34 GMT
Subject: RFR: 8339616: GenShen: Introduce new state to distinguish
 promote-in-place phase as distinct from concurrent evacuation [v3]
In-Reply-To: <aIsN7f4PqFD3OyCLy71olfuSQHgZqiWm7DuQ41CAlfQ=.66676bc3-eba6-4b32-801a-a43fc7dc52b2@github.com>
References: <aIsN7f4PqFD3OyCLy71olfuSQHgZqiWm7DuQ41CAlfQ=.66676bc3-eba6-4b32-801a-a43fc7dc52b2@github.com>
Message-ID: <SZm5Vhlzo4G5aM_d0iVcBuaErUAKp5wFNV_BYYbZjCU=.1d169343-79c5-4a39-a6fc-ac1621b0ba12@github.com>

> The generational mode for Shenandoah is able to promote regions in place (effectively moving an entire region of live objects, without evacuating any objects). It does this during a normal evacuation phase. However, in some cases, Shenandoah may choose to skip the evacuation phase, _even when there are entire regions to promote_. Prior to this PR, Shenandoah would essentially force itself into an evacuation phase, with nothing to evacuate. Though this was expedient, it caused all manner of knock-on effects and unintended consequences with barriers and asserts and the state of the heap. Here, we have reverted that business and created a path for this special "only doing in place promotions" cycle that does not cause the heap to expect to evacuate objects or find forwarding pointers in them.

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

 - Split verification for only promote-in-place into a separate method
 - Assert that collection set is empty when only promoting regions
 - Make the distinction between only in-place-promotions and evacuations more clear

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

Changes:
  - all: https://git.openjdk.org/shenandoah/pull/503/files
  - new: https://git.openjdk.org/shenandoah/pull/503/files/0ed07e92..d1b0293d

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

  Stats: 105 lines in 6 files changed: 60 ins; 5 del; 40 mod
  Patch: https://git.openjdk.org/shenandoah/pull/503.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah.git pull/503/head:pull/503

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

From wkemper at openjdk.org  Mon Sep 23 20:54:00 2024
From: wkemper at openjdk.org (William Kemper)
Date: Mon, 23 Sep 2024 20:54:00 GMT
Subject: RFR: 8339616: GenShen: Introduce new state to distinguish
 promote-in-place phase as distinct from concurrent evacuation [v2]
In-Reply-To: <tNojpkJk6A5G3EfFYPKN1weyaTzUclWAjuyTwoPz1ko=.e7cd376a-20d8-48d3-84d0-5d9641874c71@github.com>
References: <aIsN7f4PqFD3OyCLy71olfuSQHgZqiWm7DuQ41CAlfQ=.66676bc3-eba6-4b32-801a-a43fc7dc52b2@github.com>
 <p0OKDQA4gzb8ma9L0JIg2PAeYE0utMoN9pkdubZpDdM=.b68eb985-8421-4c3e-8c50-7a2afe660f01@github.com>
 <qzcVG8SqZTJlqcrk6Uh4ENIXvqp_0OdzMc6FUq931e8=.8b833571-6e54-4dd1-abd0-d0020dcc22d1@github.com>
 <tNojpkJk6A5G3EfFYPKN1weyaTzUclWAjuyTwoPz1ko=.e7cd376a-20d8-48d3-84d0-5d9641874c71@github.com>
Message-ID: <P3aqXzMdLJ2dFimkjdyNM8fru8fOGgPb8pKQILM2gA0=.2e5204e3-eab8-4488-99c0-cb285a641a9e@github.com>

On Mon, 23 Sep 2024 19:30:38 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

>> src/hotspot/share/gc/shenandoah/shenandoahConcurrentGC.cpp line 526:
>> 
>>> 524: void ShenandoahConcurrentGC::entry_promote_in_place() {
>>> 525:   shenandoah_assert_generational();
>>> 526: 
>> 
>> Do you also want to assert that collection set is empty?
>
> The other approach might be to _always_ have a separate pre-evac phase that promotes in place before actual evac to follow (even when collection set is non-empty).

Yes, added this assertion in f409f645e1.

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

PR Review Comment: https://git.openjdk.org/shenandoah/pull/503#discussion_r1772060956

From wkemper at openjdk.org  Mon Sep 23 20:54:01 2024
From: wkemper at openjdk.org (William Kemper)
Date: Mon, 23 Sep 2024 20:54:01 GMT
Subject: RFR: 8339616: GenShen: Introduce new state to distinguish
 promote-in-place phase as distinct from concurrent evacuation [v2]
In-Reply-To: <DvGMki7MVDvhtxldguSA7o68mIiHr66HGn0ce5S3dW8=.ba31a76e-f215-4762-8362-afcff980d26e@github.com>
References: <aIsN7f4PqFD3OyCLy71olfuSQHgZqiWm7DuQ41CAlfQ=.66676bc3-eba6-4b32-801a-a43fc7dc52b2@github.com>
 <p0OKDQA4gzb8ma9L0JIg2PAeYE0utMoN9pkdubZpDdM=.b68eb985-8421-4c3e-8c50-7a2afe660f01@github.com>
 <DvGMki7MVDvhtxldguSA7o68mIiHr66HGn0ce5S3dW8=.ba31a76e-f215-4762-8362-afcff980d26e@github.com>
Message-ID: <5oD1lPvbrsa-qVV8GaOPBeK6FeZQVhaBC4FngoW3Q1o=.4f982cca-93a5-4465-be13-f1eeba27734f@github.com>

On Mon, 23 Sep 2024 18:06:21 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> William Kemper has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Do not enter oom-during-evac protocol when only promoting regions in place
>
> src/hotspot/share/gc/shenandoah/shenandoahGenerationalEvacuationTask.cpp line 82:
> 
>> 80:   if (_only_promote_regions) {
>> 81:     // No allocations will be made, do not enter oom-during-evac protocol.
>> 82:     do_evacuations();
> 
> It really looks to me that promotion-in-place should be in a separate task? Or the name of the task should reflect it also does promotions? Or at least the "real evacuation" paths in `do_evacuations` be asserted with `!_only_promote_regions`?

I didn't go so far as to split them into separate tasks, but I did factor the different paths into separate methods. Also added an assert that the collection set is empty when we are only promoting regions in place.

> src/hotspot/share/gc/shenandoah/shenandoahVerifier.cpp line 1082:
> 
>> 1080:           _verify_liveness_complete,   // liveness data must be complete here
>> 1081:           _verify_regions_disable,     // trash regions not yet recycled
>> 1082:           sizeness,          // expect generation and heap sizes to match exactly
> 
> So... the comment is outdated? I suggest to split `ShenandoahVerifier::verify_after_concmark` into two methods, and clearly point out the expected state in comments then.

Done.

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

PR Review Comment: https://git.openjdk.org/shenandoah/pull/503#discussion_r1772059438
PR Review Comment: https://git.openjdk.org/shenandoah/pull/503#discussion_r1772059545

From rcastanedalo at openjdk.org  Tue Sep 24 09:01:53 2024
From: rcastanedalo at openjdk.org (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Tue, 24 Sep 2024 09:01:53 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v15]
In-Reply-To: <kBBMPkYzFAS7ne_MN9yQpW1f60peFJsaxLxnSAD0reo=.f7abc0d7-dddd-4c13-a27f-a58772f7ba96@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <CCz9B03dUxzua_YHk9-nyyHS_FTa6axwrwYjACcz4Y0=.6052f53c-9ddb-4868-a817-aff4276a2b6a@github.com>
 <6UJOrZqmfsJj6pRzMjPdlYt191QgBV6fIv1qJAYsv60=.15284272-464f-4321-b76c-3412dafc6c63@github.com>
 <poutu1_cWKZJS_aUjdHdxXdoYBb0nS5Zohb1-_UwFiY=.403c84c9-a971-4b16-b436-e34cc9654321@github.com>
 <IvQ2g_HP080mVZMQYJM3SCnjeAwZnJHfDHGUzwkXpR4=.053ed2be-6e53-4b91-b048-8efb57645c9c@github.com>
 <n5SsWdtVlbLQeGu2xxc39RFOkpcMUBUb16rd7IaZEAY=.a4d84480-b40f-4d74-9314-6b47c6551c20@github.com>
 <kBBMPkYzFAS7ne_MN9yQpW1f60peFJsaxLxnSAD0reo=.f7abc0d7-dddd-4c13-a27f-a58772f7ba96@github.com>
Message-ID: <Rp36TAlybOuvz86lsu_c81LwnhHMP91ljeMUtfmxGE0=.0344a557-48b1-4f37-94ab-7ca5ce38a9b1@github.com>

On Fri, 20 Sep 2024 15:26:36 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> I tried to reproduce for a few hours now using a custom testcase, with no success.
>> I am pretty sure that this can happen, that is why I added this code. Originally I had an assert there asserting that index is not used. I do remember that this happens very rarely, and I don't remember the exact condition. Looking at the possible operands in opclass memory, I think this can only happen when we load an nKlass from an address of the form [rX, rY], i.e. the address in rX indexed by rY. This is an odd thing to happen for loadNKlass, I think, because rY should always be klass_offset_in_bytes. Maybe this is possible when we get odd address merges where we get a PhiNode as the offset/index? I don't know.
>> I agree, this *might* lead to surprising problems with implicit null-checking, if it is expected that the first instruction in loadNKlass provokes the SIGSEGV. A way around this would be to declare an opclass that is a subset of 'memory' that excludes all operands with index, and match on that. I think this would force the lea as a separate instruction and ensure that we never see such a thing in loadNKlass. However, I would not feel very confident to do that without a reproducer. Let me dig a little further.
>> 
>> For reference, here is my unsuccessful reproducer: https://gist.github.com/rkennke/8a57610d74fcde07a9390f268ec35738
>
> Something like this is what I have in mind. It seems to pass tier1 tests. I still haven't managed to reproduce the path that requires an index register, though.
> https://github.com/rkennke/jdk/commit/2c4a7877e4ef94017c8155578d8cfc9342441656

Thanks for the update! If there is a path requiring an index register, I would agree on limiting the memory opclass to exclude indices as you suggest.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1772945253

From shade at openjdk.org  Tue Sep 24 11:19:09 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 24 Sep 2024 11:19:09 GMT
Subject: RFR: 8340181: Shenandoah: Cleanup ShenandoahRuntime stubs
Message-ID: <ouGDYCKqo9EzfJXsxc6HBULKYcyeCopgyYLuYs05B2o=.be5eadfe-4b07-4429-9257-9b7be0b69264@github.com>

Noticed this while working on Leyden, which has to enumerate Shenandoah stubs for code archival to work.

`ShenandoahRuntime::shenandoah_clone_barrier` is excessive name. `ShenandoahRuntime::arraycopy_barrier_oop_entry` and friends is not covered by `JRT_LEAF`. This change hopefully homogenizes the namings for the stubs.

Additional testing:
 - [x] Linux x86_64 server fastdebug, `hotspot_gc_shenandoah` 
 - [x] Linux AArch64 server fastdebug, `hotspot_gc_shenandoah`

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

Commit messages:
 - More build fixes
 - Fix

Changes: https://git.openjdk.org/jdk/pull/21152/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21152&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8340181
  Stats: 71 lines in 9 files changed: 7 ins; 11 del; 53 mod
  Patch: https://git.openjdk.org/jdk/pull/21152.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21152/head:pull/21152

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

From rkennke at openjdk.org  Tue Sep 24 11:42:30 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Tue, 24 Sep 2024 11:42:30 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v24]
In-Reply-To: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
Message-ID: <7N9vxRKxAK2GCBNlnU5E0Bj0sGV6_T-2QX9fKCCxlWg=.bdee038b-cee3-4c52-825c-d381d3616092@github.com>

> This is the main body of the JEP 450: Compact Object Headers (Experimental).
> 
> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing.
> 
> Main changes:
>  - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers.
>  - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded.
>  - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops).
>  - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all).
>  - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16).
>  - Arrays will now store their length at offset 8.
>  - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _coh variants of CDS archiv...

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

  Improve matching of loadNKlassCompactHeaders on aarch64

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20677/files
  - new: https://git.openjdk.org/jdk/pull/20677/files/0d8a9236..2c4a7877

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20677&range=23
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20677&range=22-23

  Stats: 17 lines in 3 files changed: 5 ins; 5 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/20677.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20677/head:pull/20677

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

From zgu at openjdk.org  Tue Sep 24 13:19:43 2024
From: zgu at openjdk.org (Zhengyu Gu)
Date: Tue, 24 Sep 2024 13:19:43 GMT
Subject: Integrated: 8340408: Shenandoah: Remove redundant task stats printing
 code in ShenandoahTaskQueue
In-Reply-To: <6PiT6kRNGaQjkJTNknVTqMV14SyYXwFosAz9Ts3Emfk=.46c01286-6733-424c-a0d6-e6ff8aa4726c@github.com>
References: <6PiT6kRNGaQjkJTNknVTqMV14SyYXwFosAz9Ts3Emfk=.46c01286-6733-424c-a0d6-e6ff8aa4726c@github.com>
Message-ID: <v_Fid1_HS99nipTKX2neDPZKrTPeVlNnIeBGfS_SVFk=.850a7c0c-a6ca-4a5e-b289-18da9354e043@github.com>

On Thu, 19 Sep 2024 00:33:04 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> [JDK-8280397](https://bugs.openjdk.org/browse/JDK-8280397) made the code redundant. 
> 
> Adopt shared implementation.

This pull request has now been integrated.

Changeset: 279086d4
Author:    Zhengyu Gu <zgu at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/279086d4ce7e05972e099022e8045f39680dd4e8
Stats:     49 lines in 4 files changed: 0 ins; 47 del; 2 mod

8340408: Shenandoah: Remove redundant task stats printing code in ShenandoahTaskQueue

Reviewed-by: shade, wkemper

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

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

From coleenp at openjdk.org  Tue Sep 24 15:40:55 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 24 Sep 2024 15:40:55 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v23]
In-Reply-To: <VjSp2vvwfzZWKtreZyiwjxsSblAX5JHCpF3c0mcYUHs=.b154b3dd-a8f2-4fdf-8176-52709f906891@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <0BrAbBTKmpqTGDrc--2znzO8t07yoqabwa6g2K05GHI=.d3c17fd5-4770-4623-8d2f-604816afc033@github.com>
 <VjSp2vvwfzZWKtreZyiwjxsSblAX5JHCpF3c0mcYUHs=.b154b3dd-a8f2-4fdf-8176-52709f906891@github.com>
Message-ID: <X5Y3hEUvZJkXEwR0yijyK-ZABZgLf5NE-Glvc9qSUBk=.08666f11-c243-4d1b-a99e-d18c224e8063@github.com>

On Fri, 20 Sep 2024 18:11:43 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Roman Kennke has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Merge remote-tracking branch 'lilliput/JEP-450-temporary-fix-branch-2' into JDK-8305895-v4
>>  - review feedback
>
> src/hotspot/share/memory/metaspace/metablock.hpp line 74:
> 
>> 72: #define METABLOCKFORMATARGS(__block__)  p2i((__block__).base()), (__block__).word_size()
>> 73: 
>> 74: } // namespace metaspace
> 
> I am wondering if some of these metaspace changes, that is, the addition of MetaBlock could be upstreamed ahead of the CompactObjectHeaders.  Some is refactoring so that you can use the wastage to allocate into class-arena but a lot of this seems neutral to compact object headers, and would reduce this patch and allow different people to focus on just this.

For the record, I am fine with these metaspace changes going in with this PR if the timing for that is better.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1773607587

From duke at openjdk.org  Tue Sep 24 15:58:47 2024
From: duke at openjdk.org (duke)
Date: Tue, 24 Sep 2024 15:58:47 GMT
Subject: Withdrawn: 8279016: JFR Leak Profiler is broken with Shenandoah
In-Reply-To: <schCFz3_D2X157-vK6_OSAJGwXEyp9bycNYDvy6sOEM=.d988e2c3-d502-4cd2-94bc-69c810323df4@github.com>
References: <schCFz3_D2X157-vK6_OSAJGwXEyp9bycNYDvy6sOEM=.d988e2c3-d502-4cd2-94bc-69c810323df4@github.com>
Message-ID: <YZJPOl0Xs2CLciM4YLZPPEeiShixBZiNXoj9c1qsoYM=.4fdd6dc8-38d9-4065-9356-fe0510ac4fa6@github.com>

On Thu, 25 Jul 2024 11:26:45 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> While testing unrelated Shenandoah patch, I caught a GC assert when Leak Profiler was running ([JDK-8337194](https://bugs.openjdk.org/browse/JDK-8337194)). 
> 
> Leak Profiler is notorious in using the mark words for its own needs. We have been trying to mitigate its impact on GCs by moving to separate bitsets for tracking marked objects, or by treating "marked without fwdptr" as "JFR marked" and handling it. But this is not reliable, since things like [putting indexes in mark word](https://github.com/openjdk/jdk/blob/3baff2af6a30cc6cb2e0d4391db1cf7e61c33f64/src/hotspot/share/jfr/leakprofiler/chains/edgeStore.cpp#L275-L280) sneak in. This is okay for Leak Profiler alone, since it restores the mark words after the operation completes, but that is still not enough when GC is already running.
> 
> I say we side-step this whack-a-mole by cleanly bailing from JFR op, when we know it is unsafe to do. I thought to use `VM_Operation::doit_prologue`, but I think GC start may sneak in between checking in prologue and op start.
> 
> This realistically only affects Shenandoah. All other STW collectors would never see what Leak Profiler did with mark words. ZGC would not see it, since it does not care about mark words for its own operation.
> 
> Additional testing:
>  - [x] `jdk/jfr/event/oldobject/` pass by default (100x times)
>  - [x] `jdk/jfr/event/oldobject/` pass with `-XX:+UseShenandoah` (1000x)

This pull request has been closed without being integrated.

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

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

From shade at openjdk.org  Tue Sep 24 16:02:39 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 24 Sep 2024 16:02:39 GMT
Subject: RFR: 8279016: JFR Leak Profiler is broken with Shenandoah [v5]
In-Reply-To: <bDGA4fxN1X5ozK0MpKDGjgsvXXp0g3loxTbj8FU4XP0=.c774114e-d792-4eaf-b2d3-f3b918e96476@github.com>
References: <schCFz3_D2X157-vK6_OSAJGwXEyp9bycNYDvy6sOEM=.d988e2c3-d502-4cd2-94bc-69c810323df4@github.com>
 <bDGA4fxN1X5ozK0MpKDGjgsvXXp0g3loxTbj8FU4XP0=.c774114e-d792-4eaf-b2d3-f3b918e96476@github.com>
Message-ID: <gxlfCSwQGWR3x8u6XdYymqS1BqvZojAHIAvI3FH6yuw=.111ed7b4-1872-4e1b-aecd-e9ab855fb17e@github.com>

On Tue, 30 Jul 2024 10:46:10 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> While testing unrelated Shenandoah patch, I caught a GC assert when Leak Profiler was running ([JDK-8337194](https://bugs.openjdk.org/browse/JDK-8337194)). 
>> 
>> Leak Profiler is notorious in using the mark words for its own needs. We have been trying to mitigate its impact on GCs by moving to separate bitsets for tracking marked objects, or by treating "marked without fwdptr" as "JFR marked" and handling it. But this is not reliable, since things like [putting indexes in mark word](https://github.com/openjdk/jdk/blob/3baff2af6a30cc6cb2e0d4391db1cf7e61c33f64/src/hotspot/share/jfr/leakprofiler/chains/edgeStore.cpp#L275-L280) sneak in. This is okay for Leak Profiler alone, since it restores the mark words after the operation completes, but that is still not enough when GC is already running.
>> 
>> I say we side-step this whack-a-mole by cleanly bailing from JFR op, when we know it is unsafe to do. I thought to use `VM_Operation::doit_prologue`, but I think GC start may sneak in between checking in prologue and op start.
>> 
>> This realistically only affects Shenandoah. All other STW collectors would never see what Leak Profiler did with mark words. ZGC would not see it, since it does not care about mark words for its own operation.
>> 
>> Additional testing:
>>  - [x] `jdk/jfr/event/oldobject/` pass by default (100x times)
>>  - [x] `jdk/jfr/event/oldobject/` pass with `-XX:+UseShenandoah` (1000x)
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Tighten up comments prose

Nope.

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

PR Comment: https://git.openjdk.org/jdk/pull/20328#issuecomment-2371709722

From shade at openjdk.org  Tue Sep 24 16:06:01 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 24 Sep 2024 16:06:01 GMT
Subject: RFR: 8339616: GenShen: Introduce new state to distinguish
 promote-in-place phase as distinct from concurrent evacuation [v3]
In-Reply-To: <SZm5Vhlzo4G5aM_d0iVcBuaErUAKp5wFNV_BYYbZjCU=.1d169343-79c5-4a39-a6fc-ac1621b0ba12@github.com>
References: <aIsN7f4PqFD3OyCLy71olfuSQHgZqiWm7DuQ41CAlfQ=.66676bc3-eba6-4b32-801a-a43fc7dc52b2@github.com>
 <SZm5Vhlzo4G5aM_d0iVcBuaErUAKp5wFNV_BYYbZjCU=.1d169343-79c5-4a39-a6fc-ac1621b0ba12@github.com>
Message-ID: <XC6BwmG0cxIS6OHWHKgZLbOvvI_ogaM-8Enet1pyebE=.c929cd8b-dc58-48c8-95c8-8ded6e521d23@github.com>

On Mon, 23 Sep 2024 20:25:34 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> The generational mode for Shenandoah is able to promote regions in place (effectively moving an entire region of live objects, without evacuating any objects). It does this during a normal evacuation phase. However, in some cases, Shenandoah may choose to skip the evacuation phase, _even when there are entire regions to promote_. Prior to this PR, Shenandoah would essentially force itself into an evacuation phase, with nothing to evacuate. Though this was expedient, it caused all manner of knock-on effects and unintended consequences with barriers and asserts and the state of the heap. Here, we have reverted that business and created a path for this special "only doing in place promotions" cycle that does not cause the heap to expect to evacuate objects or find forwarding pointers in them.
>
> William Kemper has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Split verification for only promote-in-place into a separate method
>  - Assert that collection set is empty when only promoting regions
>  - Make the distinction between only in-place-promotions and evacuations more clear

One final thing.

src/hotspot/share/gc/shenandoah/shenandoahVerifier.cpp line 1086:

> 1084: }
> 1085: 
> 1086: void ShenandoahVerifier::verify_before_region_promotions() {

I think the better name is `::verify_after_concmark_with_promotions`. It is still "after mark" check first and foremost.

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

Marked as reviewed by shade (Committer).

PR Review: https://git.openjdk.org/shenandoah/pull/503#pullrequestreview-2325745220
PR Review Comment: https://git.openjdk.org/shenandoah/pull/503#discussion_r1773645447

From wkemper at openjdk.org  Tue Sep 24 16:21:04 2024
From: wkemper at openjdk.org (William Kemper)
Date: Tue, 24 Sep 2024 16:21:04 GMT
Subject: RFR: 8339616: GenShen: Introduce new state to distinguish
 promote-in-place phase as distinct from concurrent evacuation [v3]
In-Reply-To: <XC6BwmG0cxIS6OHWHKgZLbOvvI_ogaM-8Enet1pyebE=.c929cd8b-dc58-48c8-95c8-8ded6e521d23@github.com>
References: <aIsN7f4PqFD3OyCLy71olfuSQHgZqiWm7DuQ41CAlfQ=.66676bc3-eba6-4b32-801a-a43fc7dc52b2@github.com>
 <SZm5Vhlzo4G5aM_d0iVcBuaErUAKp5wFNV_BYYbZjCU=.1d169343-79c5-4a39-a6fc-ac1621b0ba12@github.com>
 <XC6BwmG0cxIS6OHWHKgZLbOvvI_ogaM-8Enet1pyebE=.c929cd8b-dc58-48c8-95c8-8ded6e521d23@github.com>
Message-ID: <DEJWjNrllQXH4-PREvihTfDhz292JSptvIlADV8p1fI=.bde08dc9-db81-4b50-8899-2f0fc1bd75ba@github.com>

On Tue, 24 Sep 2024 16:03:04 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> William Kemper has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - Split verification for only promote-in-place into a separate method
>>  - Assert that collection set is empty when only promoting regions
>>  - Make the distinction between only in-place-promotions and evacuations more clear
>
> src/hotspot/share/gc/shenandoah/shenandoahVerifier.cpp line 1086:
> 
>> 1084: }
>> 1085: 
>> 1086: void ShenandoahVerifier::verify_before_region_promotions() {
> 
> I think the better name is `::verify_after_concmark_with_promotions`. It is still "after mark" check first and foremost.

Okay

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

PR Review Comment: https://git.openjdk.org/shenandoah/pull/503#discussion_r1773666007

From wkemper at openjdk.org  Tue Sep 24 17:05:31 2024
From: wkemper at openjdk.org (William Kemper)
Date: Tue, 24 Sep 2024 17:05:31 GMT
Subject: RFR: 8339616: GenShen: Introduce new state to distinguish
 promote-in-place phase as distinct from concurrent evacuation [v4]
In-Reply-To: <aIsN7f4PqFD3OyCLy71olfuSQHgZqiWm7DuQ41CAlfQ=.66676bc3-eba6-4b32-801a-a43fc7dc52b2@github.com>
References: <aIsN7f4PqFD3OyCLy71olfuSQHgZqiWm7DuQ41CAlfQ=.66676bc3-eba6-4b32-801a-a43fc7dc52b2@github.com>
Message-ID: <Ed2io6F6_BlEH92gz06JW6jYdXKGzZhL0J1HMEZlzkU=.a42eb37d-6958-4a56-aaa4-0cdc86bdc609@github.com>

> The generational mode for Shenandoah is able to promote regions in place (effectively moving an entire region of live objects, without evacuating any objects). It does this during a normal evacuation phase. However, in some cases, Shenandoah may choose to skip the evacuation phase, _even when there are entire regions to promote_. Prior to this PR, Shenandoah would essentially force itself into an evacuation phase, with nothing to evacuate. Though this was expedient, it caused all manner of knock-on effects and unintended consequences with barriers and asserts and the state of the heap. Here, we have reverted that business and created a path for this special "only doing in place promotions" cycle that does not cause the heap to expect to evacuate objects or find forwarding pointers in them.

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

  Use a better name for verification after concurrent mark when in-place promotions will happen

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

Changes:
  - all: https://git.openjdk.org/shenandoah/pull/503/files
  - new: https://git.openjdk.org/shenandoah/pull/503/files/d1b0293d..da8761e8

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

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

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

From shade at openjdk.org  Tue Sep 24 17:09:03 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 24 Sep 2024 17:09:03 GMT
Subject: RFR: 8339616: GenShen: Introduce new state to distinguish
 promote-in-place phase as distinct from concurrent evacuation [v4]
In-Reply-To: <Ed2io6F6_BlEH92gz06JW6jYdXKGzZhL0J1HMEZlzkU=.a42eb37d-6958-4a56-aaa4-0cdc86bdc609@github.com>
References: <aIsN7f4PqFD3OyCLy71olfuSQHgZqiWm7DuQ41CAlfQ=.66676bc3-eba6-4b32-801a-a43fc7dc52b2@github.com>
 <Ed2io6F6_BlEH92gz06JW6jYdXKGzZhL0J1HMEZlzkU=.a42eb37d-6958-4a56-aaa4-0cdc86bdc609@github.com>
Message-ID: <ZL2Amdjba3EpTpRIB09-nhq9NwIKCyEXwZjlmzPjyrk=.81b981dc-1cd3-469a-a232-883949df623c@github.com>

On Tue, 24 Sep 2024 17:05:31 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> The generational mode for Shenandoah is able to promote regions in place (effectively moving an entire region of live objects, without evacuating any objects). It does this during a normal evacuation phase. However, in some cases, Shenandoah may choose to skip the evacuation phase, _even when there are entire regions to promote_. Prior to this PR, Shenandoah would essentially force itself into an evacuation phase, with nothing to evacuate. Though this was expedient, it caused all manner of knock-on effects and unintended consequences with barriers and asserts and the state of the heap. Here, we have reverted that business and created a path for this special "only doing in place promotions" cycle that does not cause the heap to expect to evacuate objects or find forwarding pointers in them.
>
> William Kemper has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use a better name for verification after concurrent mark when in-place promotions will happen

Marked as reviewed by shade (Committer).

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

PR Review: https://git.openjdk.org/shenandoah/pull/503#pullrequestreview-2325888059

From adinn at openjdk.org  Wed Sep 25 09:51:34 2024
From: adinn at openjdk.org (Andrew Dinn)
Date: Wed, 25 Sep 2024 09:51:34 GMT
Subject: RFR: 8340181: Shenandoah: Cleanup ShenandoahRuntime stubs
In-Reply-To: <ouGDYCKqo9EzfJXsxc6HBULKYcyeCopgyYLuYs05B2o=.be5eadfe-4b07-4429-9257-9b7be0b69264@github.com>
References: <ouGDYCKqo9EzfJXsxc6HBULKYcyeCopgyYLuYs05B2o=.be5eadfe-4b07-4429-9257-9b7be0b69264@github.com>
Message-ID: <hiLTXcbDvqbJG1jb1KgIb6zvBKjcGTDeRQw7C5FKOAA=.c3ccd259-a766-46be-8695-e5bc5812c396@github.com>

On Tue, 24 Sep 2024 08:52:21 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Noticed this while working on Leyden, which has to enumerate Shenandoah stubs for code archival to work.
> 
> `ShenandoahRuntime::shenandoah_clone_barrier` is excessive name. `ShenandoahRuntime::arraycopy_barrier_oop_entry` and friends is not covered by `JRT_LEAF`. This change hopefully homogenizes the namings for the stubs.
> 
> Additional testing:
>  - [x] Linux x86_64 server fastdebug, `hotspot_gc_shenandoah` 
>  - [x] Linux AArch64 server fastdebug, `hotspot_gc_shenandoah`

Thanks for cleaning this up. Looks good.

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

Marked as reviewed by adinn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21152#pullrequestreview-2327757323

From rkennke at openjdk.org  Wed Sep 25 12:34:36 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Wed, 25 Sep 2024 12:34:36 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v25]
In-Reply-To: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
Message-ID: <EQf5fU43OLq4Oarrg-8e7E7DowLm77XO5seh3Lr61D8=.787cea42-e961-4fab-a222-92145c53d3c8@github.com>

> This is the main body of the JEP 450: Compact Object Headers (Experimental).
> 
> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing.
> 
> Main changes:
>  - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers.
>  - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded.
>  - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops).
>  - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all).
>  - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16).
>  - Arrays will now store their length at offset 8.
>  - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _coh variants of CDS archiv...

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

  Enforce lightweight locking on 32-bit platforms

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20677/files
  - new: https://git.openjdk.org/jdk/pull/20677/files/2c4a7877..cd69da86

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20677&range=24
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20677&range=23-24

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

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

From rkennke at openjdk.org  Wed Sep 25 12:53:17 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Wed, 25 Sep 2024 12:53:17 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v26]
In-Reply-To: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
Message-ID: <fEpfi4CzTFr1Pl-IyOAVyHNXWlVz33lHKQyzVY0kBc8=.cc39355b-ee7a-4118-952a-28e4184eec84@github.com>

> This is the main body of the JEP 450: Compact Object Headers (Experimental).
> 
> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing.
> 
> Main changes:
>  - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers.
>  - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded.
>  - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops).
>  - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all).
>  - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16).
>  - Arrays will now store their length at offset 8.
>  - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _coh variants of CDS archiv...

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

  Allow LM_MONITOR on 32-bit platforms

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20677/files
  - new: https://git.openjdk.org/jdk/pull/20677/files/cd69da86..4904d433

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20677&range=25
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20677&range=24-25

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

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

From wkemper at openjdk.org  Wed Sep 25 13:20:00 2024
From: wkemper at openjdk.org (William Kemper)
Date: Wed, 25 Sep 2024 13:20:00 GMT
Subject: Integrated: 8339616: GenShen: Introduce new state to distinguish
 promote-in-place phase as distinct from concurrent evacuation
In-Reply-To: <aIsN7f4PqFD3OyCLy71olfuSQHgZqiWm7DuQ41CAlfQ=.66676bc3-eba6-4b32-801a-a43fc7dc52b2@github.com>
References: <aIsN7f4PqFD3OyCLy71olfuSQHgZqiWm7DuQ41CAlfQ=.66676bc3-eba6-4b32-801a-a43fc7dc52b2@github.com>
Message-ID: <YhRlgYepx3Z4JiecD2UOFD_13Rz4WV6sdPks9ikQZI8=.a97ded61-0eb0-48ee-9a5a-5d7ed6793873@github.com>

On Fri, 20 Sep 2024 21:04:50 GMT, William Kemper <wkemper at openjdk.org> wrote:

> The generational mode for Shenandoah is able to promote regions in place (effectively moving an entire region of live objects, without evacuating any objects). It does this during a normal evacuation phase. However, in some cases, Shenandoah may choose to skip the evacuation phase, _even when there are entire regions to promote_. Prior to this PR, Shenandoah would essentially force itself into an evacuation phase, with nothing to evacuate. Though this was expedient, it caused all manner of knock-on effects and unintended consequences with barriers and asserts and the state of the heap. Here, we have reverted that business and created a path for this special "only doing in place promotions" cycle that does not cause the heap to expect to evacuate objects or find forwarding pointers in them.

This pull request has now been integrated.

Changeset: fdd5ed99
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.org/shenandoah/commit/fdd5ed9906e1437e9ba4c0c6eeb4af3dd74b3adc
Stats:     211 lines in 14 files changed: 131 ins; 31 del; 49 mod

8339616: GenShen: Introduce new state to distinguish promote-in-place phase as distinct from concurrent evacuation

Reviewed-by: kdnilsen, shade, ysr

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

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

From rcastanedalo at openjdk.org  Wed Sep 25 13:54:59 2024
From: rcastanedalo at openjdk.org (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Wed, 25 Sep 2024 13:54:59 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v26]
In-Reply-To: <P6u4aaxhJr4zjXT4_J993iocS4F11e7lfHjnnGqIJKc=.1bf65c03-fe7f-4b1a-ba08-26c64dafa3f7@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <DUgk6HT_Zk5KnbmAd_HzrJi4B8D1J-uuoAGzReWyI8s=.6c04f90a-bf1d-49af-a31d-5224973952d4@github.com>
 <GQVVR0K-mDh4evKvrKG9eXwwF4j7zAg-8ai4__gWNGE=.3c502820-717b-44b7-b82d-a24dd7fdd9d5@github.com>
 <-CikzUsH1qKbMujGJQFhaPlKaCUDzqH-jEZNM5BZVQQ=.22d236a1-a69a-42e0-86d1-aa738c6e6e6d@github.com>
 <P6u4aaxhJr4zjXT4_J993iocS4F11e7lfHjnnGqIJKc=.1bf65c03-fe7f-4b1a-ba08-26c64dafa3f7@github.com>
Message-ID: <2adTLZAwTvFTVNGeR5e9Cef5uNqpsz2haeobLIDZiNI=.cb2bbf0d-5c1b-4583-b4bd-898e0c5cdbb7@github.com>

On Fri, 13 Sep 2024 06:43:34 GMT, Roberto Casta?eda Lozano <rcastanedalo at openjdk.org> wrote:

>> I don't remember if this change was a reaction to an error or if I just guarded `CompressedKlassPointers::shift()` with +UseCCP because that is the prerequisite now. Probably the latter. I can remove this. Probably should assert then for +UseCCP.
>
> I see, thanks. In that case, I would suggest removing the explicit `UseCompressedClassPointers` test, since it should be implied by `t->isa_narrowklass()`. `check_init()` within `CompressedKlassPointers::shift()` would already fail for the unexpected case where `t->isa_narrowklass() && !UseCompressedClassPointers`, no?

I think it would be good to remove the explicit `UseCompressedClassPointers` test as argued above (i.e. revert this change), unless there is any other reason to keep it that I am missing out?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1775277784

From rcastanedalo at openjdk.org  Wed Sep 25 14:19:54 2024
From: rcastanedalo at openjdk.org (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Wed, 25 Sep 2024 14:19:54 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v26]
In-Reply-To: <fEpfi4CzTFr1Pl-IyOAVyHNXWlVz33lHKQyzVY0kBc8=.cc39355b-ee7a-4118-952a-28e4184eec84@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <fEpfi4CzTFr1Pl-IyOAVyHNXWlVz33lHKQyzVY0kBc8=.cc39355b-ee7a-4118-952a-28e4184eec84@github.com>
Message-ID: <McrslKGfzgS8urELrWmDFf9M9d2qfRxlMPMIlANo3qI=.c9eb879b-1949-4541-86c4-6aacba9075ae@github.com>

On Wed, 25 Sep 2024 12:53:17 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> This is the main body of the JEP 450: Compact Object Headers (Experimental).
>> 
>> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing.
>> 
>> Main changes:
>>  - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers.
>>  - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded.
>>  - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops).
>>  - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all).
>>  - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16).
>>  - Arrays will now store their length at offset 8.
>>  - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _co...
>
> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Allow LM_MONITOR on 32-bit platforms

src/hotspot/share/opto/memnode.cpp line 2256:

> 2254:   if (!UseCompactObjectHeaders && alloc != nullptr) {
> 2255:     return TypeX::make(markWord::prototype().value());
> 2256:   }

Suggestion: make these four lines conditional on `!UseCompactObjectHeaders`, like so:

  if (!UseCompactObjectHeaders) {
    Node* alloc = is_new_object_mark_load();
    if (alloc != nullptr) {
      return TypeX::make(markWord::prototype().value());
    }
  }

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1775322670

From wkemper at openjdk.org  Wed Sep 25 17:40:14 2024
From: wkemper at openjdk.org (William Kemper)
Date: Wed, 25 Sep 2024 17:40:14 GMT
Subject: RFR: 8339616: GenShen: Introduce new state to distinguish
 promote-in-place phase as distinct from concurrent evacuation
Message-ID: <2h8iLF343Jl5NLJ_0eylBTGwvwTLL0moMugjvgrVEFo=.db59ee35-aed2-4153-a047-b98cb7408a77@github.com>

Not clean, but not hard to resolve conflicts.

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

Commit messages:
 - Backport fdd5ed9906e1437e9ba4c0c6eeb4af3dd74b3adc

Changes: https://git.openjdk.org/shenandoah-jdk21u/pull/105/files
  Webrev: https://webrevs.openjdk.org/?repo=shenandoah-jdk21u&pr=105&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8339616
  Stats: 217 lines in 14 files changed: 131 ins; 37 del; 49 mod
  Patch: https://git.openjdk.org/shenandoah-jdk21u/pull/105.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah-jdk21u.git pull/105/head:pull/105

PR: https://git.openjdk.org/shenandoah-jdk21u/pull/105

From kdnilsen at openjdk.org  Wed Sep 25 18:01:58 2024
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Wed, 25 Sep 2024 18:01:58 GMT
Subject: RFR: 8339616: GenShen: Introduce new state to distinguish
 promote-in-place phase as distinct from concurrent evacuation
In-Reply-To: <2h8iLF343Jl5NLJ_0eylBTGwvwTLL0moMugjvgrVEFo=.db59ee35-aed2-4153-a047-b98cb7408a77@github.com>
References: <2h8iLF343Jl5NLJ_0eylBTGwvwTLL0moMugjvgrVEFo=.db59ee35-aed2-4153-a047-b98cb7408a77@github.com>
Message-ID: <hTi6G2g6eo779wOkVx8RsSsNqwQchxovqpzkXojubUY=.3bf5d9d6-055c-4729-a83e-bcc7e20d10c8@github.com>

On Wed, 25 Sep 2024 17:32:58 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Not clean, but not hard to resolve conflicts.

Marked as reviewed by kdnilsen (Committer).

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

PR Review: https://git.openjdk.org/shenandoah-jdk21u/pull/105#pullrequestreview-2329107237

From wkemper at openjdk.org  Wed Sep 25 18:15:04 2024
From: wkemper at openjdk.org (William Kemper)
Date: Wed, 25 Sep 2024 18:15:04 GMT
Subject: Integrated: 8339616: GenShen: Introduce new state to distinguish
 promote-in-place phase as distinct from concurrent evacuation
In-Reply-To: <2h8iLF343Jl5NLJ_0eylBTGwvwTLL0moMugjvgrVEFo=.db59ee35-aed2-4153-a047-b98cb7408a77@github.com>
References: <2h8iLF343Jl5NLJ_0eylBTGwvwTLL0moMugjvgrVEFo=.db59ee35-aed2-4153-a047-b98cb7408a77@github.com>
Message-ID: <GN-eHWX8w_ypXMPOTBC0VM3hHXWXVxZLhiaMbhcB-Lw=.45be3b5b-01fc-450b-bf86-bcaa7f99717e@github.com>

On Wed, 25 Sep 2024 17:32:58 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Not clean, but not hard to resolve conflicts.

This pull request has now been integrated.

Changeset: 3d9f0abc
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.org/shenandoah-jdk21u/commit/3d9f0abc75bb756dc4f58dd73190e4d24f837642
Stats:     217 lines in 14 files changed: 131 ins; 37 del; 49 mod

8339616: GenShen: Introduce new state to distinguish promote-in-place phase as distinct from concurrent evacuation

Reviewed-by: kdnilsen
Backport-of: fdd5ed9906e1437e9ba4c0c6eeb4af3dd74b3adc

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

PR: https://git.openjdk.org/shenandoah-jdk21u/pull/105

From rcastanedalo at openjdk.org  Thu Sep 26 09:07:56 2024
From: rcastanedalo at openjdk.org (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Thu, 26 Sep 2024 09:07:56 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v26]
In-Reply-To: <fEpfi4CzTFr1Pl-IyOAVyHNXWlVz33lHKQyzVY0kBc8=.cc39355b-ee7a-4118-952a-28e4184eec84@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <fEpfi4CzTFr1Pl-IyOAVyHNXWlVz33lHKQyzVY0kBc8=.cc39355b-ee7a-4118-952a-28e4184eec84@github.com>
Message-ID: <DKuidQyyiiJOsrerLCeziselVyG9Ztpzsyc64ZNjlI4=.722fc4f7-d7cc-49df-9d82-5c1094508f74@github.com>

On Wed, 25 Sep 2024 12:53:17 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> This is the main body of the JEP 450: Compact Object Headers (Experimental).
>> 
>> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing.
>> 
>> Main changes:
>>  - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers.
>>  - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded.
>>  - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops).
>>  - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all).
>>  - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16).
>>  - Arrays will now store their length at offset 8.
>>  - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _co...
>
> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Allow LM_MONITOR on 32-bit platforms

src/hotspot/cpu/x86/macroAssembler_x86.cpp line 5692:

> 5690: 
> 5691: void MacroAssembler::load_klass(Register dst, Register src, Register tmp) {
> 5692:   BLOCK_COMMENT("load_klass");

I am not sure that the complexity of `MacroAssembler::load_klass` and the two `MacroAssembler::cmp_klass` functions warrant adding block comments, but if you prefer to leave them in, could you use opening and closing comments, as in the other functions in this file (e.g. `MacroAssembler::_verify_oop`)? In that case, please update the comment in the two `MacroAssembler::cmp_klass` functions with a more descriptive name than `cmp_klass 1` and `cmp_klass 2`.

src/hotspot/cpu/x86/macroAssembler_x86.cpp line 5726:

> 5724: #ifdef _LP64
> 5725:   if (UseCompactObjectHeaders) {
> 5726:     load_nklass_compact(tmp, obj);

Suggestion: assert here that `tmp != noreg`, just like in `MacroAssembler::cmp_klass(Register src, Register dst, Register tmp1, Register tmp2)` below. Perhaps also assert that the input registers are different.

src/hotspot/cpu/x86/macroAssembler_x86.hpp line 379:

> 377:   // Uses tmp1 and tmp2 as temporary registers.
> 378:   void cmp_klass(Register src, Register dst, Register tmp1, Register tmp2);
> 379: 

The naming of these two functions could be made clearer and more consistent with their documentation. Please consider renaming the four-argument `cmp_klass` function to `cmp_klasses_from_objects` or similar. The notion of "source" and "destination" in the parameter names is unclear, I suggest to just call them `obj`, `obj1`, `obj2` etc. 
Please also make sure that the parameter names are consistent in the declaration and definition (e.g. `dst` vs `obj`).

src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 4008:

> 4006: #ifdef COMPILER2
> 4007:   if ((UseAVX == 2) && EnableX86ECoreOpts && !UseCompactObjectHeaders) {
> 4008:     generate_string_indexof(StubRoutines::_string_indexof_array);

This stub routine should be re-enabled if `UseCompactObjectHeaders` is to become non-experimental and enabled by default in the future. Is there a RFE for this task?

src/hotspot/share/opto/memnode.cpp line 1976:

> 1974:       // The field is Klass::_prototype_header.  Return its (constant) value.
> 1975:       assert(this->Opcode() == Op_LoadX, "must load a proper type from _prototype_header");
> 1976:       return TypeX::make(klass->prototype_header());

This code is dead, because by the time we call `load_array_final_field` from `LoadNode::Value` (its only caller) we know that if `UseCompactObjectHeaders`, then `tkls->offset() != in_bytes(Klass::prototype_header_offset()` (or else we would have returned from line 2161). Please remove it, or replace it with an assertion if you prefer.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1776676785
PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1776628929
PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1776644021
PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1776663594
PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1776621766

From rcastanedalo at openjdk.org  Thu Sep 26 09:54:57 2024
From: rcastanedalo at openjdk.org (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Thu, 26 Sep 2024 09:54:57 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v26]
In-Reply-To: <fEpfi4CzTFr1Pl-IyOAVyHNXWlVz33lHKQyzVY0kBc8=.cc39355b-ee7a-4118-952a-28e4184eec84@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <fEpfi4CzTFr1Pl-IyOAVyHNXWlVz33lHKQyzVY0kBc8=.cc39355b-ee7a-4118-952a-28e4184eec84@github.com>
Message-ID: <4sBfv1qLQjGZnrCuHBPuWp1PNkIDFLBjxMo3z_RR0Mo=.38e699ce-30bc-42fe-86b6-988df6700c82@github.com>

On Wed, 25 Sep 2024 12:53:17 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> This is the main body of the JEP 450: Compact Object Headers (Experimental).
>> 
>> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing.
>> 
>> Main changes:
>>  - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers.
>>  - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded.
>>  - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops).
>>  - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all).
>>  - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16).
>>  - Arrays will now store their length at offset 8.
>>  - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _co...
>
> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Allow LM_MONITOR on 32-bit platforms

src/hotspot/cpu/x86/x86_64.ad line 4388:

> 4386:   effect(KILL cr);
> 4387:   ins_cost(125); // XXX
> 4388:   format %{ "movl    $dst, $mem\t# compressed klass ptr" %}

For consistency with the aarch64 back-end:
Suggestion:

  format %{ "load_nklass_compact    $dst, $mem\t# compressed klass ptr" %}

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1776747538

From rkennke at openjdk.org  Thu Sep 26 11:41:53 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Thu, 26 Sep 2024 11:41:53 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v26]
In-Reply-To: <DKuidQyyiiJOsrerLCeziselVyG9Ztpzsyc64ZNjlI4=.722fc4f7-d7cc-49df-9d82-5c1094508f74@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <fEpfi4CzTFr1Pl-IyOAVyHNXWlVz33lHKQyzVY0kBc8=.cc39355b-ee7a-4118-952a-28e4184eec84@github.com>
 <DKuidQyyiiJOsrerLCeziselVyG9Ztpzsyc64ZNjlI4=.722fc4f7-d7cc-49df-9d82-5c1094508f74@github.com>
Message-ID: <hdttC4LhHE6y6Nbq0jjJwxxF4W0hTfJLK_siODDCBkM=.1667f495-fcd9-4b7f-8d58-24e27665eeb3@github.com>

On Thu, 26 Sep 2024 08:55:44 GMT, Roberto Casta?eda Lozano <rcastanedalo at openjdk.org> wrote:

>> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Allow LM_MONITOR on 32-bit platforms
>
> src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 4008:
> 
>> 4006: #ifdef COMPILER2
>> 4007:   if ((UseAVX == 2) && EnableX86ECoreOpts && !UseCompactObjectHeaders) {
>> 4008:     generate_string_indexof(StubRoutines::_string_indexof_array);
> 
> This stub routine should be re-enabled if `UseCompactObjectHeaders` is to become non-experimental and enabled by default in the future. Is there a RFE for this task?

This comes from an assert in `LibraryCallKit::inline_string_indexOfI` and I believe we can perhaps remove that assert and the !UCOH clause. I checked a couple of tests that tripped that assert, and they seem to work fine, and I also checked the code in `LibraryCallKit::inline_string_indexOfI` and `generate_string_indexof_stubs()` and could not find anything obvious that requires the base offset to be >=16. I am not sure why that assert is there. I am now running tier1-4 with that change: https://github.com/rkennke/jdk/commit/7001783e8c11718226506f42b7c1f1fda1af3ad0

If you know (or find) any reason why we need that assert, please let me know. Otherwise I'd remove it, if you don't have objections.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1776888460

From rcastanedalo at openjdk.org  Thu Sep 26 12:16:52 2024
From: rcastanedalo at openjdk.org (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Thu, 26 Sep 2024 12:16:52 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v26]
In-Reply-To: <fEpfi4CzTFr1Pl-IyOAVyHNXWlVz33lHKQyzVY0kBc8=.cc39355b-ee7a-4118-952a-28e4184eec84@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <fEpfi4CzTFr1Pl-IyOAVyHNXWlVz33lHKQyzVY0kBc8=.cc39355b-ee7a-4118-952a-28e4184eec84@github.com>
Message-ID: <W4Z02hPO5V8J_XtvI4eXZDw3P3Kt5i4ULGHOSVpC5xk=.4031d913-80b2-4ca2-951e-e8d0e4fc03d4@github.com>

On Wed, 25 Sep 2024 12:53:17 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> This is the main body of the JEP 450: Compact Object Headers (Experimental).
>> 
>> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing.
>> 
>> Main changes:
>>  - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers.
>>  - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded.
>>  - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops).
>>  - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all).
>>  - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16).
>>  - Arrays will now store their length at offset 8.
>>  - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _co...
>
> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Allow LM_MONITOR on 32-bit platforms

src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.cpp line 2570:

> 2568:   // we get the heapBase in obj, and the narrowOop+klass_offset_in_bytes/sizeof(narrowOop) in index.
> 2569:   // When that happens, we need to lea the address into a single register, and subtract the
> 2570:   // klass_offset_in_bytes, to get the address of the mark-word.

Parts of this comment are obsolete after commit 2c4a7877, please update the comment.

src/hotspot/cpu/aarch64/macroAssembler_aarch64.hpp line 882:

> 880:   void store_klass(Register dst, Register src);
> 881:   void cmp_klass(Register oop, Register trial_klass, Register tmp);
> 882:   void cmp_klass(Register src, Register dst, Register tmp1, Register tmp2);

Same suggestion as for the analogous x86 functions: consider renaming the four-argument `cmp_klass` function to `cmp_klasses_from_objects` or similar, and the `src` and `dst` parameters to `oop1` and `oop2` or similar if there is no notion of "source" and "destination".

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1776927247
PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1776942226

From rcastanedalo at openjdk.org  Thu Sep 26 13:07:55 2024
From: rcastanedalo at openjdk.org (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Thu, 26 Sep 2024 13:07:55 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v26]
In-Reply-To: <hdttC4LhHE6y6Nbq0jjJwxxF4W0hTfJLK_siODDCBkM=.1667f495-fcd9-4b7f-8d58-24e27665eeb3@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <fEpfi4CzTFr1Pl-IyOAVyHNXWlVz33lHKQyzVY0kBc8=.cc39355b-ee7a-4118-952a-28e4184eec84@github.com>
 <DKuidQyyiiJOsrerLCeziselVyG9Ztpzsyc64ZNjlI4=.722fc4f7-d7cc-49df-9d82-5c1094508f74@github.com>
 <hdttC4LhHE6y6Nbq0jjJwxxF4W0hTfJLK_siODDCBkM=.1667f495-fcd9-4b7f-8d58-24e27665eeb3@github.com>
Message-ID: <fWSdSqQfhOrGpFoExiaO4L-UDtR90_t0gRxp9YBO3_c=.0173618e-f392-4921-8fae-39d44b24de08@github.com>

On Thu, 26 Sep 2024 11:39:02 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 4008:
>> 
>>> 4006: #ifdef COMPILER2
>>> 4007:   if ((UseAVX == 2) && EnableX86ECoreOpts && !UseCompactObjectHeaders) {
>>> 4008:     generate_string_indexof(StubRoutines::_string_indexof_array);
>> 
>> This stub routine should be re-enabled if `UseCompactObjectHeaders` is to become non-experimental and enabled by default in the future. Is there a RFE for this task?
>
> This comes from an assert in `LibraryCallKit::inline_string_indexOfI` and I believe we can perhaps remove that assert and the !UCOH clause. I checked a couple of tests that tripped that assert, and they seem to work fine, and I also checked the code in `LibraryCallKit::inline_string_indexOfI` and `generate_string_indexof_stubs()` and could not find anything obvious that requires the base offset to be >=16. I am not sure why that assert is there. I am now running tier1-4 with that change: https://github.com/rkennke/jdk/commit/7001783e8c11718226506f42b7c1f1fda1af3ad0
> 
> If you know (or find) any reason why we need that assert, please let me know. Otherwise I'd remove it, if you don't have objections.

I am not familiar with the `indexOf` implementation, but here is a relevant comment that motivates the assertion: https://github.com/openjdk/jdk/pull/16753#discussion_r1592774634.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1777033220

From rkennke at openjdk.org  Thu Sep 26 14:00:58 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Thu, 26 Sep 2024 14:00:58 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v26]
In-Reply-To: <fWSdSqQfhOrGpFoExiaO4L-UDtR90_t0gRxp9YBO3_c=.0173618e-f392-4921-8fae-39d44b24de08@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <fEpfi4CzTFr1Pl-IyOAVyHNXWlVz33lHKQyzVY0kBc8=.cc39355b-ee7a-4118-952a-28e4184eec84@github.com>
 <DKuidQyyiiJOsrerLCeziselVyG9Ztpzsyc64ZNjlI4=.722fc4f7-d7cc-49df-9d82-5c1094508f74@github.com>
 <hdttC4LhHE6y6Nbq0jjJwxxF4W0hTfJLK_siODDCBkM=.1667f495-fcd9-4b7f-8d58-24e27665eeb3@github.com>
 <fWSdSqQfhOrGpFoExiaO4L-UDtR90_t0gRxp9YBO3_c=.0173618e-f392-4921-8fae-39d44b24de08@github.com>
Message-ID: <6PTWMepIDuZDdPfN3xNKV1vqUyO_R4yCSeiSTpYIyyQ=.61a5b462-7114-4385-a6d7-40e5c7b0005d@github.com>

On Thu, 26 Sep 2024 13:04:57 GMT, Roberto Casta?eda Lozano <rcastanedalo at openjdk.org> wrote:

>> This comes from an assert in `LibraryCallKit::inline_string_indexOfI` and I believe we can perhaps remove that assert and the !UCOH clause. I checked a couple of tests that tripped that assert, and they seem to work fine, and I also checked the code in `LibraryCallKit::inline_string_indexOfI` and `generate_string_indexof_stubs()` and could not find anything obvious that requires the base offset to be >=16. I am not sure why that assert is there. I am now running tier1-4 with that change: https://github.com/rkennke/jdk/commit/7001783e8c11718226506f42b7c1f1fda1af3ad0
>> 
>> If you know (or find) any reason why we need that assert, please let me know. Otherwise I'd remove it, if you don't have objections.
>
> I am not familiar with the `indexOf` implementation, but here is a relevant comment that motivates the assertion: https://github.com/openjdk/jdk/pull/16753#discussion_r1592774634.

Ok, this is indeed relevant and helpful. This could segfault if we happen to read from the very first object on the heap. I can solve this by allowing to copy only 8 bytes onto the stack: https://github.com/rkennke/jdk/commit/097c2afa04397773e514552dfb942aa889bfa2c1

Does this look correct to you? Or better to do it as a follow-up?
(It passes a couple of indexOf tests, will run tier1-4 on it).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1777134871

From rkennke at openjdk.org  Thu Sep 26 14:04:43 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Thu, 26 Sep 2024 14:04:43 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v27]
In-Reply-To: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
Message-ID: <vXY57OOQjLAnLf9faNtb5Zr_geVFfS2x_BURnooT9iU=.e7c87d03-e6c3-42b6-87ff-78f116bb5dcf@github.com>

> This is the main body of the JEP 450: Compact Object Headers (Experimental).
> 
> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing.
> 
> Main changes:
>  - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers.
>  - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded.
>  - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops).
>  - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all).
>  - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16).
>  - Arrays will now store their length at offset 8.
>  - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _coh variants of CDS archiv...

Roman Kennke has updated the pull request incrementally with two additional commits since the last revision:

 - @robcasloz review comments
 - Improve CollectedHeap::is_oop()

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20677/files
  - new: https://git.openjdk.org/jdk/pull/20677/files/4904d433..d48f55d6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20677&range=26
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20677&range=25-26

  Stats: 86 lines in 10 files changed: 20 ins; 21 del; 45 mod
  Patch: https://git.openjdk.org/jdk/pull/20677.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20677/head:pull/20677

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

From rcastanedalo at openjdk.org  Thu Sep 26 16:02:55 2024
From: rcastanedalo at openjdk.org (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Thu, 26 Sep 2024 16:02:55 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v26]
In-Reply-To: <6PTWMepIDuZDdPfN3xNKV1vqUyO_R4yCSeiSTpYIyyQ=.61a5b462-7114-4385-a6d7-40e5c7b0005d@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <fEpfi4CzTFr1Pl-IyOAVyHNXWlVz33lHKQyzVY0kBc8=.cc39355b-ee7a-4118-952a-28e4184eec84@github.com>
 <DKuidQyyiiJOsrerLCeziselVyG9Ztpzsyc64ZNjlI4=.722fc4f7-d7cc-49df-9d82-5c1094508f74@github.com>
 <hdttC4LhHE6y6Nbq0jjJwxxF4W0hTfJLK_siODDCBkM=.1667f495-fcd9-4b7f-8d58-24e27665eeb3@github.com>
 <fWSdSqQfhOrGpFoExiaO4L-UDtR90_t0gRxp9YBO3_c=.0173618e-f392-4921-8fae-39d44b24de08@github.com>
 <6PTWMepIDuZDdPfN3xNKV1vqUyO_R4yCSeiSTpYIyyQ=.61a5b462-7114-4385-a6d7-40e5c7b0005d@github.com>
Message-ID: <C5LwWrsa-VO87kdm_sYuisTGMsHoxv4Eoe0QikdkusE=.63b0993c-86c8-4ef6-a3cf-bc8a67e10815@github.com>

On Thu, 26 Sep 2024 13:58:02 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> Does this look correct to you? Or better to do it as a follow-up?

I do not feel confident enough to review this part. If you want to include https://github.com/rkennke/jdk/commit/097c2afa04397773e514552dfb942aa889bfa2c1 in this changeset, I would prefer that the original author of JDK-8320448 or at least someone from Intel reviews it, otherwise I think it is fine to leave it as a follow-up enhancement.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1777370316

From rkennke at openjdk.org  Thu Sep 26 16:18:58 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Thu, 26 Sep 2024 16:18:58 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v26]
In-Reply-To: <C5LwWrsa-VO87kdm_sYuisTGMsHoxv4Eoe0QikdkusE=.63b0993c-86c8-4ef6-a3cf-bc8a67e10815@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <fEpfi4CzTFr1Pl-IyOAVyHNXWlVz33lHKQyzVY0kBc8=.cc39355b-ee7a-4118-952a-28e4184eec84@github.com>
 <DKuidQyyiiJOsrerLCeziselVyG9Ztpzsyc64ZNjlI4=.722fc4f7-d7cc-49df-9d82-5c1094508f74@github.com>
 <hdttC4LhHE6y6Nbq0jjJwxxF4W0hTfJLK_siODDCBkM=.1667f495-fcd9-4b7f-8d58-24e27665eeb3@github.com>
 <fWSdSqQfhOrGpFoExiaO4L-UDtR90_t0gRxp9YBO3_c=.0173618e-f392-4921-8fae-39d44b24de08@github.com>
 <6PTWMepIDuZDdPfN3xNKV1vqUyO_R4yCSeiSTpYIyyQ=.61a5b462-7114-4385-a6d7-40e5c7b0005d@github.com>
 <C5LwWrsa-VO87kdm_sYuisTGMsHoxv4Eoe0QikdkusE=.63b0993c-86c8-4ef6-a3cf-bc8a67e10815@github.com>
Message-ID: <WOlTJMNHCr_Kk69sEIUwCVI3ZbiRlckY4TSBRfL7zoA=.1a4c59f1-a000-4d9f-abbc-36b24ed5105e@github.com>

On Thu, 26 Sep 2024 15:59:50 GMT, Roberto Casta?eda Lozano <rcastanedalo at openjdk.org> wrote:

>> Ok, this is indeed relevant and helpful. This could segfault if we happen to read from the very first object on the heap. I can solve this by allowing to copy only 8 bytes onto the stack: https://github.com/rkennke/jdk/commit/097c2afa04397773e514552dfb942aa889bfa2c1
>> 
>> Does this look correct to you? Or better to do it as a follow-up?
>> (It passes a couple of indexOf tests, will run tier1-4 on it).
>
>> Does this look correct to you? Or better to do it as a follow-up?
> 
> I do not feel confident enough to review this part. If you want to include https://github.com/rkennke/jdk/commit/097c2afa04397773e514552dfb942aa889bfa2c1 in this changeset, I would prefer that the original author of JDK-8320448 or at least someone from Intel reviews it, otherwise I think it is fine to leave it as a follow-up enhancement.

@sviswa7 or @asgibbons WDYT about including https://github.com/rkennke/jdk/commit/097c2afa04397773e514552dfb942aa889bfa2c1 as part of compact object headers implementation? Otherwise we would have to disable indexOf intrinsic when running with compact headers, because of the assumption that array headers are >= 16 bytes, which is no longer true with compact headers.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1777396409

From wkemper at openjdk.org  Thu Sep 26 17:00:22 2024
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 26 Sep 2024 17:00:22 GMT
Subject: RFR: 8341042: GenShen: Reset mark bitmaps for unaffiliated regions
 when preparing for a cycle
Message-ID: <d3rO5ElG2mI9E7Q-xw059F-w-8FGQb28yNpf5yHRxDU=.979ccf6f-10d4-4ed1-a247-a860db875230@github.com>

A recent change to reset unaffiliated bitmaps during the concurrent cleanup phase has caused a performance regression. Likely because concurrent cleanup only uses one thread (at this time). This issue is to revert the regression causing change while we work on a preferred solution.

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

Commit messages:
 - Reset bitmaps for unaffiliated regions in prepare_gc

Changes: https://git.openjdk.org/shenandoah/pull/504/files
  Webrev: https://webrevs.openjdk.org/?repo=shenandoah&pr=504&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8341042
  Stats: 7 lines in 2 files changed: 1 ins; 5 del; 1 mod
  Patch: https://git.openjdk.org/shenandoah/pull/504.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah.git pull/504/head:pull/504

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

From wkemper at openjdk.org  Thu Sep 26 17:07:20 2024
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 26 Sep 2024 17:07:20 GMT
Subject: RFR: 8341042: GenShen: Reset mark bitmaps for unaffiliated regions
 when preparing for a cycle
In-Reply-To: <d3rO5ElG2mI9E7Q-xw059F-w-8FGQb28yNpf5yHRxDU=.979ccf6f-10d4-4ed1-a247-a860db875230@github.com>
References: <d3rO5ElG2mI9E7Q-xw059F-w-8FGQb28yNpf5yHRxDU=.979ccf6f-10d4-4ed1-a247-a860db875230@github.com>
Message-ID: <nC1hiqhMAb34F6C4fuL6-pUG2qtbLztGKCie08mD_tk=.93e886dd-302a-40c3-8ad7-83b5bab8c7a7@github.com>

On Thu, 26 Sep 2024 16:55:55 GMT, William Kemper <wkemper at openjdk.org> wrote:

> A recent change to reset unaffiliated bitmaps during the concurrent cleanup phase has caused a performance regression. Likely because concurrent cleanup only uses one thread (at this time). This issue is to revert the regression causing change while we work on a preferred solution.

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

> 580:   set_top(bottom());
> 581:   clear_live_data();
> 582:   heap->marking_context()->clear_bitmap(this);

This is a merge error on this branch. `shenandoah-jdk21u` does not reset the bitmaps twice like this.

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

PR Review Comment: https://git.openjdk.org/shenandoah/pull/504#discussion_r1777458359

From phh at openjdk.org  Thu Sep 26 17:10:12 2024
From: phh at openjdk.org (Paul Hohensee)
Date: Thu, 26 Sep 2024 17:10:12 GMT
Subject: RFR: 8340181: Shenandoah: Cleanup ShenandoahRuntime stubs
In-Reply-To: <ouGDYCKqo9EzfJXsxc6HBULKYcyeCopgyYLuYs05B2o=.be5eadfe-4b07-4429-9257-9b7be0b69264@github.com>
References: <ouGDYCKqo9EzfJXsxc6HBULKYcyeCopgyYLuYs05B2o=.be5eadfe-4b07-4429-9257-9b7be0b69264@github.com>
Message-ID: <Nb2dCmR2ID9olo7m6SOs4tWBRcpmQCNBaHS-bu0jq8o=.6cfa3fd6-d349-43da-baeb-cc5ff93d5f44@github.com>

On Tue, 24 Sep 2024 08:52:21 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Noticed this while working on Leyden, which has to enumerate Shenandoah stubs for code archival to work.
> 
> `ShenandoahRuntime::shenandoah_clone_barrier` is excessive name. `ShenandoahRuntime::arraycopy_barrier_oop_entry` and friends is not covered by `JRT_LEAF`. This change hopefully homogenizes the namings for the stubs.
> 
> Additional testing:
>  - [x] Linux x86_64 server fastdebug, `hotspot_gc_shenandoah` 
>  - [x] Linux AArch64 server fastdebug, `hotspot_gc_shenandoah`

In case you need a second review.

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

Marked as reviewed by phh (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21152#pullrequestreview-2331900600

From kdnilsen at openjdk.org  Thu Sep 26 17:21:57 2024
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Thu, 26 Sep 2024 17:21:57 GMT
Subject: RFR: 8341042: GenShen: Reset mark bitmaps for unaffiliated regions
 when preparing for a cycle
In-Reply-To: <d3rO5ElG2mI9E7Q-xw059F-w-8FGQb28yNpf5yHRxDU=.979ccf6f-10d4-4ed1-a247-a860db875230@github.com>
References: <d3rO5ElG2mI9E7Q-xw059F-w-8FGQb28yNpf5yHRxDU=.979ccf6f-10d4-4ed1-a247-a860db875230@github.com>
Message-ID: <xP3M7xxPSaan3_R2eAKzA7wHQwAEVRv1prG3ks7jtqw=.8748638d-c878-4637-b7d3-7f580ef489bb@github.com>

On Thu, 26 Sep 2024 16:55:55 GMT, William Kemper <wkemper at openjdk.org> wrote:

> A recent change to reset unaffiliated bitmaps during the concurrent cleanup phase has caused a performance regression. Likely because concurrent cleanup only uses one thread (at this time). This issue is to revert the regression causing change while we work on a preferred solution.

Marked as reviewed by kdnilsen (Committer).

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

PR Review: https://git.openjdk.org/shenandoah/pull/504#pullrequestreview-2331922478

From sgibbons at openjdk.org  Thu Sep 26 17:27:50 2024
From: sgibbons at openjdk.org (Scott Gibbons)
Date: Thu, 26 Sep 2024 17:27:50 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v26]
In-Reply-To: <WOlTJMNHCr_Kk69sEIUwCVI3ZbiRlckY4TSBRfL7zoA=.1a4c59f1-a000-4d9f-abbc-36b24ed5105e@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <fEpfi4CzTFr1Pl-IyOAVyHNXWlVz33lHKQyzVY0kBc8=.cc39355b-ee7a-4118-952a-28e4184eec84@github.com>
 <DKuidQyyiiJOsrerLCeziselVyG9Ztpzsyc64ZNjlI4=.722fc4f7-d7cc-49df-9d82-5c1094508f74@github.com>
 <hdttC4LhHE6y6Nbq0jjJwxxF4W0hTfJLK_siODDCBkM=.1667f495-fcd9-4b7f-8d58-24e27665eeb3@github.com>
 <fWSdSqQfhOrGpFoExiaO4L-UDtR90_t0gRxp9YBO3_c=.0173618e-f392-4921-8fae-39d44b24de08@github.com>
 <6PTWMepIDuZDdPfN3xNKV1vqUyO_R4yCSeiSTpYIyyQ=.61a5b462-7114-4385-a6d7-40e5c7b0005d@github.com>
 <C5LwWrsa-VO87kdm_sYuisTGMsHoxv4Eoe0QikdkusE=.63b0993c-86c8-4ef6-a3cf-bc8a67e10815@github.com>
 <WOlTJMNHCr_Kk69sEIUwCVI3ZbiRlckY4TSBRfL7zoA=.1a4c59f1-a000-4d9f-abbc-36b24ed5105e@github.com>
Message-ID: <UjwpWz9Y3W8WRzYHZmDk9EvoiLSCZG1aai5oASGtDKA=.68cab6dd-e67d-4651-a9c9-75dccf42d85f@github.com>

On Thu, 26 Sep 2024 16:15:39 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>>> Does this look correct to you? Or better to do it as a follow-up?
>> 
>> I do not feel confident enough to review this part. If you want to include https://github.com/rkennke/jdk/commit/097c2afa04397773e514552dfb942aa889bfa2c1 in this changeset, I would prefer that the original author of JDK-8320448 or at least someone from Intel reviews it, otherwise I think it is fine to leave it as a follow-up enhancement.
>
> @sviswa7 or @asgibbons WDYT about including https://github.com/rkennke/jdk/commit/097c2afa04397773e514552dfb942aa889bfa2c1 as part of compact object headers implementation? Otherwise we would have to disable indexOf intrinsic when running with compact headers, because of the assumption that array headers are >= 16 bytes, which is no longer true with compact headers.

@rkennke I reviewed [rkennke@ 097c2af](https://github.com/rkennke/jdk/commit/097c2afa04397773e514552dfb942aa889bfa2c1) and the code looks good to me.  I would prefer this approach instead of not generating the IndexOf intrinsic.

Should the controlling `if` be conditioned on `UseCompactObjectHeaders` instead of `arrayOopDesc::base_offset_in_bytes`?  I can see benefits to either - which provides more clarity?  I like the assert as it makes the intention clear (thanks!).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1777485078

From xpeng at openjdk.org  Thu Sep 26 17:42:35 2024
From: xpeng at openjdk.org (Xiaolong Peng)
Date: Thu, 26 Sep 2024 17:42:35 GMT
Subject: RFR: 8340490: Shenandoah: Optimize ShenandoahPacer [v2]
In-Reply-To: <Xf89-L8wLAMbngt5PxoN3B0sX94chZQz5zjqfuiBYZM=.6c6387e8-572a-4c47-8de2-d4f407924c88@github.com>
References: <mh4-1fuv1_9n0e_BCeIX-WHnXZN-1A7woAkyJinXkIU=.c03edc09-82fc-44c2-b09b-22d543fb4ec4@github.com>
 <61bsu02-sDgUFx45vjC3xAvAaDtIY405Qm8lh3Edp28=.5a1c2d42-a51c-4014-b5e3-64cbd02786ed@github.com>
 <p1_dfGVCQ8Hswy1n4E2HPW22LVPjwPVba5cecSQxrPg=.22aeb487-488f-46e7-a86a-be1f4a6baedd@github.com>
 <Xf89-L8wLAMbngt5PxoN3B0sX94chZQz5zjqfuiBYZM=.6c6387e8-572a-4c47-8de2-d4f407924c88@github.com>
Message-ID: <dBqq5vX5rTQzA5tfApAmif_B_rXqVs2kuzq5_Q1hpIk=.a664e2b4-0476-44ae-a7db-34eb1b65f5ec@github.com>

On Sat, 21 Sep 2024 05:52:10 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> > > I am good with this, assuming performance runs show good results.
> > 
> > 
> > Latency wise, in most time it is better than old impl.
> 
> It is great it improves targeted tests, and it makes sense from the first principles. Run our usual performance pipeline to sanity check if this affects any other benchmarks in any meaningful way.

Performance pipeline showed improvments in most Dacapo benchmarks, we did found very small regression in Dacapo Spring max latency(<1%?), tried to reproduce it with bare metal instance and can't really stably reproduce the regression, sometime  better and sometime worse, it could be just noises.

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

PR Comment: https://git.openjdk.org/jdk/pull/21099#issuecomment-2377567597

From kdnilsen at openjdk.org  Thu Sep 26 17:57:36 2024
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Thu, 26 Sep 2024 17:57:36 GMT
Subject: RFR: 8340490: Shenandoah: Optimize ShenandoahPacer [v2]
In-Reply-To: <U4-6cg1j9inHQdKJDt0mYEl9DFc6nQ9sbdiao4hSH_4=.9e421feb-a9c7-4c77-b745-e307749b052f@github.com>
References: <mh4-1fuv1_9n0e_BCeIX-WHnXZN-1A7woAkyJinXkIU=.c03edc09-82fc-44c2-b09b-22d543fb4ec4@github.com>
 <U4-6cg1j9inHQdKJDt0mYEl9DFc6nQ9sbdiao4hSH_4=.9e421feb-a9c7-4c77-b745-e307749b052f@github.com>
Message-ID: <S0JZpd5zEqYPmQBxIgdAcKqqqHID9Bgm8TP_38lEUWQ=.0bff936d-6b39-4b54-bc6a-c33193c184b8@github.com>

On Fri, 20 Sep 2024 18:47:50 GMT, Xiaolong Peng <xpeng at openjdk.org> wrote:

>> In a simple latency benchmark for memory allocation, I found ShenandoahPacer contributed quite a lot to the long tail latency > 10ms, when there are multi mutator threads failed at fast path to claim budget [here](https://github.com/openjdk/jdk/blob/fdc16a373459cb2311316448c765b1bee5c73694/src/hotspot/share/gc/shenandoah/shenandoahPacer.cpp#L230), all of them will forcefully claim and them wait for up to 10ms([code link](https://github.com/openjdk/jdk/blob/fdc16a373459cb2311316448c765b1bee5c73694/src/hotspot/share/gc/shenandoah/shenandoahPacer.cpp#L239-L277))
>> 
>> The change in this PR makes ShenandoahPacer impact long tail latency much less, instead forcefully claim budget and them wait, it attempts to claim after waiting for 1ms, and keep doing this until: 1/ either spent 10ms waiting in total; 2/ or successfully claimed the budget.
>> 
>> Here the latency comparison for the optimization:
>> ![hdr-histogram-optimize-pacer](https://github.com/user-attachments/assets/811f48c5-87eb-462d-8b27-d15bd08be7b0)
>> 
>> With the optimization, long tail latency from the test code below has been much improved from over 20ms to ~10ms on MacOS with M3 chip:
>> 
>>     static final int threadCount = Runtime.getRuntime().availableProcessors();
>>     static final LongAdder totalCount = new LongAdder();
>>     static volatile byte[] sink;
>>     public static void main(String[] args) {
>>         runAllocationTest(100000);
>>     }
>>     static void recordTimeToAllocate(final int dataSize, final Histogram histogram) {
>>         long startTime = System.nanoTime();
>>         sink = new byte[dataSize];
>>         long endTime = System.nanoTime();
>>         histogram.recordValue(endTime - startTime);
>>     }
>> 
>>     static void runAllocationTest(final int dataSize) {
>>         final long endTime = System.currentTimeMillis() + 30_000;
>>         final CountDownLatch startSignal = new CountDownLatch(1);
>>         final CountDownLatch finished = new CountDownLatch(threadCount);
>>         final Thread[] threads = new Thread[threadCount];
>>         final Histogram[] histograms = new Histogram[threadCount];
>>         final Histogram totalHistogram = new Histogram(3600000000000L, 3);
>>         for (int i = 0; i < threadCount; i++) {
>>             final var histogram = new Histogram(3600000000000L, 3);
>>             histograms[i] = histogram;
>>             threads[i] = new Thread(() -> {
>>                 wait(startSignal);
>>                 do {
>>                     recordTimeToAllocate(dataS...
>
> Xiaolong Peng has updated the pull request incrementally with one additional commit since the last revision:
> 
>   clean up

Marked as reviewed by kdnilsen (Author).

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

PR Review: https://git.openjdk.org/jdk/pull/21099#pullrequestreview-2332001130

From wkemper at openjdk.org  Thu Sep 26 18:30:52 2024
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 26 Sep 2024 18:30:52 GMT
Subject: Integrated: 8341042: GenShen: Reset mark bitmaps for unaffiliated
 regions when preparing for a cycle
In-Reply-To: <d3rO5ElG2mI9E7Q-xw059F-w-8FGQb28yNpf5yHRxDU=.979ccf6f-10d4-4ed1-a247-a860db875230@github.com>
References: <d3rO5ElG2mI9E7Q-xw059F-w-8FGQb28yNpf5yHRxDU=.979ccf6f-10d4-4ed1-a247-a860db875230@github.com>
Message-ID: <OcbAr3duM03mqNXTyUTCTsVFhWNR1FvbDewELmGOCak=.838be613-33d1-4972-b411-39d7b1cc0109@github.com>

On Thu, 26 Sep 2024 16:55:55 GMT, William Kemper <wkemper at openjdk.org> wrote:

> A recent change to reset unaffiliated bitmaps during the concurrent cleanup phase has caused a performance regression. Likely because concurrent cleanup only uses one thread (at this time). This issue is to revert the regression causing change while we work on a preferred solution.

This pull request has now been integrated.

Changeset: 988b98bb
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.org/shenandoah/commit/988b98bb4964e15391a1f1a40d984c91480f1ccb
Stats:     7 lines in 2 files changed: 1 ins; 5 del; 1 mod

8341042: GenShen: Reset mark bitmaps for unaffiliated regions when preparing for a cycle

Reviewed-by: kdnilsen

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

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

From xpeng at openjdk.org  Thu Sep 26 18:57:35 2024
From: xpeng at openjdk.org (Xiaolong Peng)
Date: Thu, 26 Sep 2024 18:57:35 GMT
Subject: RFR: 8340490: Shenandoah: Optimize ShenandoahPacer [v2]
In-Reply-To: <Xf89-L8wLAMbngt5PxoN3B0sX94chZQz5zjqfuiBYZM=.6c6387e8-572a-4c47-8de2-d4f407924c88@github.com>
References: <mh4-1fuv1_9n0e_BCeIX-WHnXZN-1A7woAkyJinXkIU=.c03edc09-82fc-44c2-b09b-22d543fb4ec4@github.com>
 <61bsu02-sDgUFx45vjC3xAvAaDtIY405Qm8lh3Edp28=.5a1c2d42-a51c-4014-b5e3-64cbd02786ed@github.com>
 <p1_dfGVCQ8Hswy1n4E2HPW22LVPjwPVba5cecSQxrPg=.22aeb487-488f-46e7-a86a-be1f4a6baedd@github.com>
 <Xf89-L8wLAMbngt5PxoN3B0sX94chZQz5zjqfuiBYZM=.6c6387e8-572a-4c47-8de2-d4f407924c88@github.com>
Message-ID: <VhfOzl_EgVdGxX46fFI_-aQnfHkV8NUL85j29o_VlH0=.e6f9a5a3-e457-4fc6-8f34-e7c96e2e8166@github.com>

On Sat, 21 Sep 2024 05:52:10 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>>> I am good with this, assuming performance runs show good results.
>> 
>> Latency wise, in most time it is better than old impl. 
>> 
>> In my specific test with 8G heap on MacOS, throughput is very close to the test w/ ShenandoahPacing disabled, and about 25%~30% improvement comparing the old implementation.
>
>> > I am good with this, assuming performance runs show good results.
>> 
>> Latency wise, in most time it is better than old impl.
> 
> It is great it improves targeted tests, and it makes sense from the first principles. Run our usual performance pipeline to sanity check if this affects any other benchmarks in any meaningful way.

@shipilev Need you to review it again since I pushed minor refactor and format change as per your comments.

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

PR Comment: https://git.openjdk.org/jdk/pull/21099#issuecomment-2377706480

From wkemper at openjdk.org  Thu Sep 26 19:02:26 2024
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 26 Sep 2024 19:02:26 GMT
Subject: RFR: 8335356: Shenandoah: Improve concurrent cleanup locking
Message-ID: <IU3ODDtKAnipJnmwFoG1GbridST7z-LaQkspIoBjCmI=.2a5ed52e-084a-48ff-867d-78dbf905bcd4@github.com>

Not clean, but conflicts were easy to resolve.

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

Commit messages:
 - Backport b32e4a68bca588d908bd81a398eb3171a6876dc5

Changes: https://git.openjdk.org/shenandoah-jdk21u/pull/106/files
  Webrev: https://webrevs.openjdk.org/?repo=shenandoah-jdk21u&pr=106&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8335356
  Stats: 18 lines in 2 files changed: 13 ins; 1 del; 4 mod
  Patch: https://git.openjdk.org/shenandoah-jdk21u/pull/106.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah-jdk21u.git pull/106/head:pull/106

PR: https://git.openjdk.org/shenandoah-jdk21u/pull/106

From ysr at openjdk.org  Thu Sep 26 19:43:59 2024
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Thu, 26 Sep 2024 19:43:59 GMT
Subject: RFR: 8335356: Shenandoah: Improve concurrent cleanup locking
In-Reply-To: <IU3ODDtKAnipJnmwFoG1GbridST7z-LaQkspIoBjCmI=.2a5ed52e-084a-48ff-867d-78dbf905bcd4@github.com>
References: <IU3ODDtKAnipJnmwFoG1GbridST7z-LaQkspIoBjCmI=.2a5ed52e-084a-48ff-867d-78dbf905bcd4@github.com>
Message-ID: <TASkjllaiIwyS1kuEZW2yFx8XDfI_-z7LqQFmUggTIA=.c63c63b8-aedc-497b-a73d-ff04dc9ec2b5@github.com>

On Thu, 26 Sep 2024 18:56:20 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Not clean, but conflicts were easy to resolve.

This looks good. Would be good to backport this into JDK 21u-dev directly too.
(cc @pengxiaolong)

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

Marked as reviewed by ysr (Committer).

PR Review: https://git.openjdk.org/shenandoah-jdk21u/pull/106#pullrequestreview-2332206957

From wkemper at openjdk.org  Thu Sep 26 20:13:51 2024
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 26 Sep 2024 20:13:51 GMT
Subject: RFR: 8335356: Shenandoah: Improve concurrent cleanup locking
In-Reply-To: <IU3ODDtKAnipJnmwFoG1GbridST7z-LaQkspIoBjCmI=.2a5ed52e-084a-48ff-867d-78dbf905bcd4@github.com>
References: <IU3ODDtKAnipJnmwFoG1GbridST7z-LaQkspIoBjCmI=.2a5ed52e-084a-48ff-867d-78dbf905bcd4@github.com>
Message-ID: <_0WI1bBGjct7OsH1SOBL9t4kZ3tpoP4JNhEx-JFvWIU=.bae9919b-5cfd-40fc-ab5d-8d4f1e2f5310@github.com>

On Thu, 26 Sep 2024 18:56:20 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Not clean, but conflicts were easy to resolve.

Yes, I'll open a PR to integrate to 21u-dev also.

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

PR Comment: https://git.openjdk.org/shenandoah-jdk21u/pull/106#issuecomment-2377842658

From wkemper at openjdk.org  Thu Sep 26 20:13:52 2024
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 26 Sep 2024 20:13:52 GMT
Subject: Integrated: 8335356: Shenandoah: Improve concurrent cleanup locking
In-Reply-To: <IU3ODDtKAnipJnmwFoG1GbridST7z-LaQkspIoBjCmI=.2a5ed52e-084a-48ff-867d-78dbf905bcd4@github.com>
References: <IU3ODDtKAnipJnmwFoG1GbridST7z-LaQkspIoBjCmI=.2a5ed52e-084a-48ff-867d-78dbf905bcd4@github.com>
Message-ID: <tkLwNG3gRnbMhxVcjmMWWzk9IFL5hMhikvKZI-RYtzQ=.b1b1e0b2-8b47-45b5-9c45-fe525185a03b@github.com>

On Thu, 26 Sep 2024 18:56:20 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Not clean, but conflicts were easy to resolve.

This pull request has now been integrated.

Changeset: 2c22b6a3
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.org/shenandoah-jdk21u/commit/2c22b6a3a7da4c8cdcd83a81cb38801223a235cc
Stats:     18 lines in 2 files changed: 13 ins; 1 del; 4 mod

8335356: Shenandoah: Improve concurrent cleanup locking

Reviewed-by: ysr
Backport-of: b32e4a68bca588d908bd81a398eb3171a6876dc5

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

PR: https://git.openjdk.org/shenandoah-jdk21u/pull/106

From wkemper at openjdk.org  Thu Sep 26 20:51:59 2024
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 26 Sep 2024 20:51:59 GMT
Subject: RFR: 8341042: GenShen: Reset mark bitmaps for unaffiliated regions
 when preparing for a cycle
Message-ID: <H3-L2Y-5Yhrr_xx7GNL9Y0Yanjz6TjUhrN4_syo5KDE=.9989b312-18f7-4454-b81b-42e7ebae345f@github.com>

Conflict with whitespace change.

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

Commit messages:
 - Backport 988b98bb4964e15391a1f1a40d984c91480f1ccb

Changes: https://git.openjdk.org/shenandoah-jdk21u/pull/107/files
  Webrev: https://webrevs.openjdk.org/?repo=shenandoah-jdk21u&pr=107&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8341042
  Stats: 6 lines in 2 files changed: 1 ins; 4 del; 1 mod
  Patch: https://git.openjdk.org/shenandoah-jdk21u/pull/107.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah-jdk21u.git pull/107/head:pull/107

PR: https://git.openjdk.org/shenandoah-jdk21u/pull/107

From kdnilsen at openjdk.org  Thu Sep 26 20:51:59 2024
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Thu, 26 Sep 2024 20:51:59 GMT
Subject: RFR: 8341042: GenShen: Reset mark bitmaps for unaffiliated regions
 when preparing for a cycle
In-Reply-To: <H3-L2Y-5Yhrr_xx7GNL9Y0Yanjz6TjUhrN4_syo5KDE=.9989b312-18f7-4454-b81b-42e7ebae345f@github.com>
References: <H3-L2Y-5Yhrr_xx7GNL9Y0Yanjz6TjUhrN4_syo5KDE=.9989b312-18f7-4454-b81b-42e7ebae345f@github.com>
Message-ID: <7TwgU9v9zg6MFRRQc5qGdo6dz5eoPLDY4gJmzobdu0U=.7c74cd76-5516-44e2-b83e-fdb45d9a9792@github.com>

On Thu, 26 Sep 2024 20:46:40 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Conflict with whitespace change.

Marked as reviewed by kdnilsen (Committer).

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

PR Review: https://git.openjdk.org/shenandoah-jdk21u/pull/107#pullrequestreview-2332320731

From ysr at openjdk.org  Thu Sep 26 21:01:51 2024
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Thu, 26 Sep 2024 21:01:51 GMT
Subject: RFR: 8341042: GenShen: Reset mark bitmaps for unaffiliated regions
 when preparing for a cycle
In-Reply-To: <nC1hiqhMAb34F6C4fuL6-pUG2qtbLztGKCie08mD_tk=.93e886dd-302a-40c3-8ad7-83b5bab8c7a7@github.com>
References: <d3rO5ElG2mI9E7Q-xw059F-w-8FGQb28yNpf5yHRxDU=.979ccf6f-10d4-4ed1-a247-a860db875230@github.com>
 <nC1hiqhMAb34F6C4fuL6-pUG2qtbLztGKCie08mD_tk=.93e886dd-302a-40c3-8ad7-83b5bab8c7a7@github.com>
Message-ID: <ATdo6vtrTvC0rEwz0TjyyxXu4LWHrSDJQlrq9zOEi2o=.16b51b62-8044-43d9-8022-f6b78cf342a2@github.com>

On Thu, 26 Sep 2024 17:03:50 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> A recent change to reset unaffiliated bitmaps during the concurrent cleanup phase has caused a performance regression. Likely because concurrent cleanup only uses one thread (at this time). This issue is to revert the regression causing change while we work on a preferred solution.
>
> src/hotspot/share/gc/shenandoah/shenandoahHeapRegion.cpp line 582:
> 
>> 580:   set_top(bottom());
>> 581:   clear_live_data();
>> 582:   heap->marking_context()->clear_bitmap(this);
> 
> This is a merge error on this branch. `shenandoah-jdk21u` does not reset the bitmaps twice like this.

yikes :-)

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

PR Review Comment: https://git.openjdk.org/shenandoah/pull/504#discussion_r1777727656

From wkemper at openjdk.org  Thu Sep 26 21:40:01 2024
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 26 Sep 2024 21:40:01 GMT
Subject: Integrated: 8341042: GenShen: Reset mark bitmaps for unaffiliated
 regions when preparing for a cycle
In-Reply-To: <H3-L2Y-5Yhrr_xx7GNL9Y0Yanjz6TjUhrN4_syo5KDE=.9989b312-18f7-4454-b81b-42e7ebae345f@github.com>
References: <H3-L2Y-5Yhrr_xx7GNL9Y0Yanjz6TjUhrN4_syo5KDE=.9989b312-18f7-4454-b81b-42e7ebae345f@github.com>
Message-ID: <LLqyfNkvP1QEvo3FK2A8R5doM47ymbR-A08tsfhsprw=.65ed988e-6405-420b-b2e1-be881685e109@github.com>

On Thu, 26 Sep 2024 20:46:40 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Conflict with whitespace change.

This pull request has now been integrated.

Changeset: 5bbd3b97
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.org/shenandoah-jdk21u/commit/5bbd3b97caf82744bc58902a846cfc7a5bfb1f93
Stats:     6 lines in 2 files changed: 1 ins; 4 del; 1 mod

8341042: GenShen: Reset mark bitmaps for unaffiliated regions when preparing for a cycle

Reviewed-by: kdnilsen
Backport-of: 988b98bb4964e15391a1f1a40d984c91480f1ccb

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

PR: https://git.openjdk.org/shenandoah-jdk21u/pull/107

From shade at openjdk.org  Fri Sep 27 07:43:42 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 27 Sep 2024 07:43:42 GMT
Subject: RFR: 8340490: Shenandoah: Optimize ShenandoahPacer [v2]
In-Reply-To: <U4-6cg1j9inHQdKJDt0mYEl9DFc6nQ9sbdiao4hSH_4=.9e421feb-a9c7-4c77-b745-e307749b052f@github.com>
References: <mh4-1fuv1_9n0e_BCeIX-WHnXZN-1A7woAkyJinXkIU=.c03edc09-82fc-44c2-b09b-22d543fb4ec4@github.com>
 <U4-6cg1j9inHQdKJDt0mYEl9DFc6nQ9sbdiao4hSH_4=.9e421feb-a9c7-4c77-b745-e307749b052f@github.com>
Message-ID: <MQtbCrTMWUyadYeOA5725L_r1i5cGLZSeq4l71KgTeQ=.da2515ef-250f-4960-8b1c-f635d66ceab9@github.com>

On Fri, 20 Sep 2024 18:47:50 GMT, Xiaolong Peng <xpeng at openjdk.org> wrote:

>> In a simple latency benchmark for memory allocation, I found ShenandoahPacer contributed quite a lot to the long tail latency > 10ms, when there are multi mutator threads failed at fast path to claim budget [here](https://github.com/openjdk/jdk/blob/fdc16a373459cb2311316448c765b1bee5c73694/src/hotspot/share/gc/shenandoah/shenandoahPacer.cpp#L230), all of them will forcefully claim and them wait for up to 10ms([code link](https://github.com/openjdk/jdk/blob/fdc16a373459cb2311316448c765b1bee5c73694/src/hotspot/share/gc/shenandoah/shenandoahPacer.cpp#L239-L277))
>> 
>> The change in this PR makes ShenandoahPacer impact long tail latency much less, instead forcefully claim budget and them wait, it attempts to claim after waiting for 1ms, and keep doing this until: 1/ either spent 10ms waiting in total; 2/ or successfully claimed the budget.
>> 
>> Here the latency comparison for the optimization:
>> ![hdr-histogram-optimize-pacer](https://github.com/user-attachments/assets/811f48c5-87eb-462d-8b27-d15bd08be7b0)
>> 
>> With the optimization, long tail latency from the test code below has been much improved from over 20ms to ~10ms on MacOS with M3 chip:
>> 
>>     static final int threadCount = Runtime.getRuntime().availableProcessors();
>>     static final LongAdder totalCount = new LongAdder();
>>     static volatile byte[] sink;
>>     public static void main(String[] args) {
>>         runAllocationTest(100000);
>>     }
>>     static void recordTimeToAllocate(final int dataSize, final Histogram histogram) {
>>         long startTime = System.nanoTime();
>>         sink = new byte[dataSize];
>>         long endTime = System.nanoTime();
>>         histogram.recordValue(endTime - startTime);
>>     }
>> 
>>     static void runAllocationTest(final int dataSize) {
>>         final long endTime = System.currentTimeMillis() + 30_000;
>>         final CountDownLatch startSignal = new CountDownLatch(1);
>>         final CountDownLatch finished = new CountDownLatch(threadCount);
>>         final Thread[] threads = new Thread[threadCount];
>>         final Histogram[] histograms = new Histogram[threadCount];
>>         final Histogram totalHistogram = new Histogram(3600000000000L, 3);
>>         for (int i = 0; i < threadCount; i++) {
>>             final var histogram = new Histogram(3600000000000L, 3);
>>             histograms[i] = histogram;
>>             threads[i] = new Thread(() -> {
>>                 wait(startSignal);
>>                 do {
>>                     recordTimeToAllocate(dataS...
>
> Xiaolong Peng has updated the pull request incrementally with one additional commit since the last revision:
> 
>   clean up

Marked as reviewed by shade (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/21099#pullrequestreview-2333007889

From rkennke at openjdk.org  Fri Sep 27 08:27:57 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Fri, 27 Sep 2024 08:27:57 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v26]
In-Reply-To: <UjwpWz9Y3W8WRzYHZmDk9EvoiLSCZG1aai5oASGtDKA=.68cab6dd-e67d-4651-a9c9-75dccf42d85f@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <fEpfi4CzTFr1Pl-IyOAVyHNXWlVz33lHKQyzVY0kBc8=.cc39355b-ee7a-4118-952a-28e4184eec84@github.com>
 <DKuidQyyiiJOsrerLCeziselVyG9Ztpzsyc64ZNjlI4=.722fc4f7-d7cc-49df-9d82-5c1094508f74@github.com>
 <hdttC4LhHE6y6Nbq0jjJwxxF4W0hTfJLK_siODDCBkM=.1667f495-fcd9-4b7f-8d58-24e27665eeb3@github.com>
 <fWSdSqQfhOrGpFoExiaO4L-UDtR90_t0gRxp9YBO3_c=.0173618e-f392-4921-8fae-39d44b24de08@github.com>
 <6PTWMepIDuZDdPfN3xNKV1vqUyO_R4yCSeiSTpYIyyQ=.61a5b462-7114-4385-a6d7-40e5c7b0005d@github.com>
 <C5LwWrsa-VO87kdm_sYuisTGMsHoxv4Eoe0QikdkusE=.63b0993c-86c8-4ef6-a3cf-bc8a67e10815@github.com>
 <WOlTJMNHCr_Kk69sEIUwCVI3ZbiRlckY4TSBRfL7zoA=.1a4c59f1-a000-4d9f-abbc-36b24ed5105e@github.com>
 <UjwpWz9Y3W8WRzYHZmDk9EvoiLSCZG1aai5oASGtDKA=.68cab6dd-e67d-4651-a9c9-75dccf42d85f@github.com>
Message-ID: <l_7f8gGpIdG9H3Ini5vHWruIa0oDi7fkn2Lz5thDI5c=.969b804f-bae2-48e1-9c44-e631d90037e7@github.com>

On Thu, 26 Sep 2024 17:25:06 GMT, Scott Gibbons <sgibbons at openjdk.org> wrote:

>> @sviswa7 or @asgibbons WDYT about including https://github.com/rkennke/jdk/commit/097c2afa04397773e514552dfb942aa889bfa2c1 as part of compact object headers implementation? Otherwise we would have to disable indexOf intrinsic when running with compact headers, because of the assumption that array headers are >= 16 bytes, which is no longer true with compact headers.
>
> @rkennke I reviewed [rkennke@ 097c2af](https://github.com/rkennke/jdk/commit/097c2afa04397773e514552dfb942aa889bfa2c1) and the code looks good to me.  I would prefer this approach instead of not generating the IndexOf intrinsic.
> 
> Should the controlling `if` be conditioned on `UseCompactObjectHeaders` instead of `arrayOopDesc::base_offset_in_bytes`?  I can see benefits to either - which provides more clarity?  I like the assert as it makes the intention clear (thanks!).

I like to have the functional connection: if - for whatever reason - the array base offset is smaller than 16, we need to deal with that. The reason for this happens to be `UseCompactObjectHeaders`, but that may not be clear to the reader of the code. I could add an `assert(UseCompactObjectHeaders` in that branch to make that connection clear. Also consider that `UseCompactObjectHeaders` is intended to go away at some point.

I wonder if having 2 or 3 branches ahead of the main-loop (which probably doesn't do much, because haystack is <=32 bytes) is a useful approach, or if there may be a better way to get the bytes on the stack? I don't know enough about the implementation to make that judgement.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1778230714

From rkennke at openjdk.org  Fri Sep 27 09:41:17 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Fri, 27 Sep 2024 09:41:17 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v28]
In-Reply-To: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
Message-ID: <s4Shjqv28fYx8U5UNboZcK2F0dJrwKjJYxRUDn7lFNk=.6dd86afe-2a80-4393-8508-1478aa3de4b4@github.com>

> This is the main body of the JEP 450: Compact Object Headers (Experimental).
> 
> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing.
> 
> Main changes:
>  - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers.
>  - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded.
>  - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops).
>  - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all).
>  - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16).
>  - Arrays will now store their length at offset 8.
>  - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _coh variants of CDS archiv...

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

  Disable TestSplitPacks::test4a, failing on aarch64

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20677/files
  - new: https://git.openjdk.org/jdk/pull/20677/files/d48f55d6..059b1573

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20677&range=27
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20677&range=26-27

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

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

From wkemper at openjdk.org  Fri Sep 27 14:18:05 2024
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 27 Sep 2024 14:18:05 GMT
Subject: RFR: Merge openjdk/jdk:master
Message-ID: <yJ42M3jsHSGJzXQab6LBo9xLvFHsMkO-CQDDJv4UuJs=.72a08792-fd9d-4b8d-80cc-6c9c3db41681@github.com>

Merges tag jdk-24+17

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

Commit messages:
 - 8340923: The class LogSelection copies uninitialized memory
 - 8339260: Move rarely used constants out of ClassFile
 - 8340812: LambdaForm customization via MethodHandle::updateForm is not thread safe
 - 8339271: giflib attribution correction
 - 8340864: Remove unused lines related to vmClasses
 - 8340831: Simplify simple validation for class definition in MethodHandles.Lookup
 - 8340838: Clean up MutableCallSite to use explicit release fence instead of AtomicInteger
 - 8340956: ProblemList 4 java/nio/channels/DatagramChannel tests on macosx-all
 - 8340228: Open source couple more miscellaneous AWT tests
 - 8340684: Reading from an input stream backed by a closed ZipFile has no test coverage
 - ... and 100 more: https://git.openjdk.org/shenandoah/compare/c58fbef0...10da2c21

The merge commit only contains trivial merges, so no merge-specific webrevs have been generated.

Changes: https://git.openjdk.org/shenandoah/pull/505/files
  Stats: 17789 lines in 401 files changed: 13042 ins; 2473 del; 2274 mod
  Patch: https://git.openjdk.org/shenandoah/pull/505.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah.git pull/505/head:pull/505

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

From rcastanedalo at openjdk.org  Fri Sep 27 14:35:54 2024
From: rcastanedalo at openjdk.org (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Fri, 27 Sep 2024 14:35:54 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v28]
In-Reply-To: <-CikzUsH1qKbMujGJQFhaPlKaCUDzqH-jEZNM5BZVQQ=.22d236a1-a69a-42e0-86d1-aa738c6e6e6d@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <DUgk6HT_Zk5KnbmAd_HzrJi4B8D1J-uuoAGzReWyI8s=.6c04f90a-bf1d-49af-a31d-5224973952d4@github.com>
 <GQVVR0K-mDh4evKvrKG9eXwwF4j7zAg-8ai4__gWNGE=.3c502820-717b-44b7-b82d-a24dd7fdd9d5@github.com>
 <-CikzUsH1qKbMujGJQFhaPlKaCUDzqH-jEZNM5BZVQQ=.22d236a1-a69a-42e0-86d1-aa738c6e6e6d@github.com>
Message-ID: <K3AopS6Hcuvlj38a4botYqOe9BsSbP-SqSBgJOSm8xg=.b9186913-ed75-4c63-a8d0-93df079d3d03@github.com>

On Thu, 12 Sep 2024 15:42:59 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> src/hotspot/share/opto/machnode.cpp line 390:
>> 
>>> 388:     t = t->make_ptr();
>>> 389:   }
>>> 390:   if (t->isa_narrowklass() && CompressedKlassPointers::shift() == 0) {
>> 
>> Does this change have any effect? `UseCompressedClassPointers` should be implied by `t->isa_narrowklass()`.
>
> I don't remember if this change was a reaction to an error or if I just guarded `CompressedKlassPointers::shift()` with +UseCCP because that is the prerequisite now. Probably the latter. I can remove this. Probably should assert then for +UseCCP.

@tstuefe @rkennke what do you think about this suggestion? If there is a known case where `t->isa_narrowklass() && !UseCompressedClassPointers` holds, it should be investigated because it might be a symptom of a larger problem. If there is no such a case, I think the explicit `UseCompressedClassPointers` test should be removed to avoid confusion.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1778724120

From sgibbons at openjdk.org  Fri Sep 27 14:47:51 2024
From: sgibbons at openjdk.org (Scott Gibbons)
Date: Fri, 27 Sep 2024 14:47:51 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v26]
In-Reply-To: <l_7f8gGpIdG9H3Ini5vHWruIa0oDi7fkn2Lz5thDI5c=.969b804f-bae2-48e1-9c44-e631d90037e7@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <fEpfi4CzTFr1Pl-IyOAVyHNXWlVz33lHKQyzVY0kBc8=.cc39355b-ee7a-4118-952a-28e4184eec84@github.com>
 <DKuidQyyiiJOsrerLCeziselVyG9Ztpzsyc64ZNjlI4=.722fc4f7-d7cc-49df-9d82-5c1094508f74@github.com>
 <hdttC4LhHE6y6Nbq0jjJwxxF4W0hTfJLK_siODDCBkM=.1667f495-fcd9-4b7f-8d58-24e27665eeb3@github.com>
 <fWSdSqQfhOrGpFoExiaO4L-UDtR90_t0gRxp9YBO3_c=.0173618e-f392-4921-8fae-39d44b24de08@github.com>
 <6PTWMepIDuZDdPfN3xNKV1vqUyO_R4yCSeiSTpYIyyQ=.61a5b462-7114-4385-a6d7-40e5c7b0005d@github.com>
 <C5LwWrsa-VO87kdm_sYuisTGMsHoxv4Eoe0QikdkusE=.63b0993c-86c8-4ef6-a3cf-bc8a67e10815@github.com>
 <WOlTJMNHCr_Kk69sEIUwCVI3ZbiRlckY4TSBRfL7zoA=.1a4c59f1-a000-4d9f-abbc-36b24ed5105e@github.com>
 <UjwpWz9Y3W8WRzYHZmDk9EvoiLSCZG1aai5oASGtDKA=.68cab6dd-e67d-4651-a9c9-75dccf42d85f@github.com>
 <l_7f8gGpIdG9H3Ini5vHWruIa0oDi7fkn2Lz5thDI5c=.969b804f-bae2-48e1-9c44-e631d90037e7@github.com>
Message-ID: <BtvwMUG5tcy_zU4tRG3Q5VVw08qE_3gSE35wCxlDnj4=.954353e5-cab2-48f4-b0f2-5852e586ba20@github.com>

On Fri, 27 Sep 2024 08:24:50 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> @rkennke I reviewed [rkennke@ 097c2af](https://github.com/rkennke/jdk/commit/097c2afa04397773e514552dfb942aa889bfa2c1) and the code looks good to me.  I would prefer this approach instead of not generating the IndexOf intrinsic.
>> 
>> Should the controlling `if` be conditioned on `UseCompactObjectHeaders` instead of `arrayOopDesc::base_offset_in_bytes`?  I can see benefits to either - which provides more clarity?  I like the assert as it makes the intention clear (thanks!).
>
> I like to have the functional connection: if - for whatever reason - the array base offset is smaller than 16, we need to deal with that. The reason for this happens to be `UseCompactObjectHeaders`, but that may not be clear to the reader of the code. I could add an `assert(UseCompactObjectHeaders` in that branch to make that connection clear. Also consider that `UseCompactObjectHeaders` is intended to go away at some point.
> 
> I wonder if having 2 or 3 branches ahead of the main-loop (which probably doesn't do much, because haystack is <=32 bytes) is a useful approach, or if there may be a better way to get the bytes on the stack? I don't know enough about the implementation to make that judgement.

I believe the code in the patch is good enough as-is, especially if `UseCompactObjectHeaders` is slated to go away.  The existing `if` will prevent the < 16 byte header code from being emitted, which is the desired behavior - i.e., if the header size is >= 16, there will be no code emitted to the intrinsic for that block.  So there will not be an additional branch for the code when it is executed.

I'm good with a comment tying `UseCompactObjectHeaders` to the condition.  The comment can be removed when the flag is removed.  "Ship it" :-)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1778739517

From xpeng at openjdk.org  Fri Sep 27 15:07:39 2024
From: xpeng at openjdk.org (Xiaolong Peng)
Date: Fri, 27 Sep 2024 15:07:39 GMT
Subject: RFR: 8340490: Shenandoah: Optimize ShenandoahPacer [v2]
In-Reply-To: <U4-6cg1j9inHQdKJDt0mYEl9DFc6nQ9sbdiao4hSH_4=.9e421feb-a9c7-4c77-b745-e307749b052f@github.com>
References: <mh4-1fuv1_9n0e_BCeIX-WHnXZN-1A7woAkyJinXkIU=.c03edc09-82fc-44c2-b09b-22d543fb4ec4@github.com>
 <U4-6cg1j9inHQdKJDt0mYEl9DFc6nQ9sbdiao4hSH_4=.9e421feb-a9c7-4c77-b745-e307749b052f@github.com>
Message-ID: <u78zqLFbHxXy4xzEn55L21-pQYZ2aMkwYbVH--Kta2E=.eb298ecd-a0f8-4ad9-a72a-e00c448ac70b@github.com>

On Fri, 20 Sep 2024 18:47:50 GMT, Xiaolong Peng <xpeng at openjdk.org> wrote:

>> In a simple latency benchmark for memory allocation, I found ShenandoahPacer contributed quite a lot to the long tail latency > 10ms, when there are multi mutator threads failed at fast path to claim budget [here](https://github.com/openjdk/jdk/blob/fdc16a373459cb2311316448c765b1bee5c73694/src/hotspot/share/gc/shenandoah/shenandoahPacer.cpp#L230), all of them will forcefully claim and them wait for up to 10ms([code link](https://github.com/openjdk/jdk/blob/fdc16a373459cb2311316448c765b1bee5c73694/src/hotspot/share/gc/shenandoah/shenandoahPacer.cpp#L239-L277))
>> 
>> The change in this PR makes ShenandoahPacer impact long tail latency much less, instead forcefully claim budget and them wait, it attempts to claim after waiting for 1ms, and keep doing this until: 1/ either spent 10ms waiting in total; 2/ or successfully claimed the budget.
>> 
>> Here the latency comparison for the optimization:
>> ![hdr-histogram-optimize-pacer](https://github.com/user-attachments/assets/811f48c5-87eb-462d-8b27-d15bd08be7b0)
>> 
>> With the optimization, long tail latency from the test code below has been much improved from over 20ms to ~10ms on MacOS with M3 chip:
>> 
>>     static final int threadCount = Runtime.getRuntime().availableProcessors();
>>     static final LongAdder totalCount = new LongAdder();
>>     static volatile byte[] sink;
>>     public static void main(String[] args) {
>>         runAllocationTest(100000);
>>     }
>>     static void recordTimeToAllocate(final int dataSize, final Histogram histogram) {
>>         long startTime = System.nanoTime();
>>         sink = new byte[dataSize];
>>         long endTime = System.nanoTime();
>>         histogram.recordValue(endTime - startTime);
>>     }
>> 
>>     static void runAllocationTest(final int dataSize) {
>>         final long endTime = System.currentTimeMillis() + 30_000;
>>         final CountDownLatch startSignal = new CountDownLatch(1);
>>         final CountDownLatch finished = new CountDownLatch(threadCount);
>>         final Thread[] threads = new Thread[threadCount];
>>         final Histogram[] histograms = new Histogram[threadCount];
>>         final Histogram totalHistogram = new Histogram(3600000000000L, 3);
>>         for (int i = 0; i < threadCount; i++) {
>>             final var histogram = new Histogram(3600000000000L, 3);
>>             histograms[i] = histogram;
>>             threads[i] = new Thread(() -> {
>>                 wait(startSignal);
>>                 do {
>>                     recordTimeToAllocate(dataS...
>
> Xiaolong Peng has updated the pull request incrementally with one additional commit since the last revision:
> 
>   clean up

Thanks all for the reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/21099#issuecomment-2379487017

From duke at openjdk.org  Fri Sep 27 15:07:39 2024
From: duke at openjdk.org (duke)
Date: Fri, 27 Sep 2024 15:07:39 GMT
Subject: RFR: 8340490: Shenandoah: Optimize ShenandoahPacer [v2]
In-Reply-To: <U4-6cg1j9inHQdKJDt0mYEl9DFc6nQ9sbdiao4hSH_4=.9e421feb-a9c7-4c77-b745-e307749b052f@github.com>
References: <mh4-1fuv1_9n0e_BCeIX-WHnXZN-1A7woAkyJinXkIU=.c03edc09-82fc-44c2-b09b-22d543fb4ec4@github.com>
 <U4-6cg1j9inHQdKJDt0mYEl9DFc6nQ9sbdiao4hSH_4=.9e421feb-a9c7-4c77-b745-e307749b052f@github.com>
Message-ID: <u0tOhQutfah_3PKyXlNjU3KaF0rZmgTuitQSSdNJ61E=.00635052-61d8-4798-ae95-ea9a09788ead@github.com>

On Fri, 20 Sep 2024 18:47:50 GMT, Xiaolong Peng <xpeng at openjdk.org> wrote:

>> In a simple latency benchmark for memory allocation, I found ShenandoahPacer contributed quite a lot to the long tail latency > 10ms, when there are multi mutator threads failed at fast path to claim budget [here](https://github.com/openjdk/jdk/blob/fdc16a373459cb2311316448c765b1bee5c73694/src/hotspot/share/gc/shenandoah/shenandoahPacer.cpp#L230), all of them will forcefully claim and them wait for up to 10ms([code link](https://github.com/openjdk/jdk/blob/fdc16a373459cb2311316448c765b1bee5c73694/src/hotspot/share/gc/shenandoah/shenandoahPacer.cpp#L239-L277))
>> 
>> The change in this PR makes ShenandoahPacer impact long tail latency much less, instead forcefully claim budget and them wait, it attempts to claim after waiting for 1ms, and keep doing this until: 1/ either spent 10ms waiting in total; 2/ or successfully claimed the budget.
>> 
>> Here the latency comparison for the optimization:
>> ![hdr-histogram-optimize-pacer](https://github.com/user-attachments/assets/811f48c5-87eb-462d-8b27-d15bd08be7b0)
>> 
>> With the optimization, long tail latency from the test code below has been much improved from over 20ms to ~10ms on MacOS with M3 chip:
>> 
>>     static final int threadCount = Runtime.getRuntime().availableProcessors();
>>     static final LongAdder totalCount = new LongAdder();
>>     static volatile byte[] sink;
>>     public static void main(String[] args) {
>>         runAllocationTest(100000);
>>     }
>>     static void recordTimeToAllocate(final int dataSize, final Histogram histogram) {
>>         long startTime = System.nanoTime();
>>         sink = new byte[dataSize];
>>         long endTime = System.nanoTime();
>>         histogram.recordValue(endTime - startTime);
>>     }
>> 
>>     static void runAllocationTest(final int dataSize) {
>>         final long endTime = System.currentTimeMillis() + 30_000;
>>         final CountDownLatch startSignal = new CountDownLatch(1);
>>         final CountDownLatch finished = new CountDownLatch(threadCount);
>>         final Thread[] threads = new Thread[threadCount];
>>         final Histogram[] histograms = new Histogram[threadCount];
>>         final Histogram totalHistogram = new Histogram(3600000000000L, 3);
>>         for (int i = 0; i < threadCount; i++) {
>>             final var histogram = new Histogram(3600000000000L, 3);
>>             histograms[i] = histogram;
>>             threads[i] = new Thread(() -> {
>>                 wait(startSignal);
>>                 do {
>>                     recordTimeToAllocate(dataS...
>
> Xiaolong Peng has updated the pull request incrementally with one additional commit since the last revision:
> 
>   clean up

@pengxiaolong 
Your change (at version 58196a4f6f9f509525667dba1bd1fb2c2afa3e8e) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/21099#issuecomment-2379489972

From wkemper at openjdk.org  Fri Sep 27 15:47:34 2024
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 27 Sep 2024 15:47:34 GMT
Subject: RFR: 8340181: Shenandoah: Cleanup ShenandoahRuntime stubs
In-Reply-To: <ouGDYCKqo9EzfJXsxc6HBULKYcyeCopgyYLuYs05B2o=.be5eadfe-4b07-4429-9257-9b7be0b69264@github.com>
References: <ouGDYCKqo9EzfJXsxc6HBULKYcyeCopgyYLuYs05B2o=.be5eadfe-4b07-4429-9257-9b7be0b69264@github.com>
Message-ID: <OTx-GU16qyp4z0gKZnYwT3jaJei7BDzZAQaA-kRYPFY=.b50a4132-0b76-4ce3-bb1c-e6fe7be0e8e0@github.com>

On Tue, 24 Sep 2024 08:52:21 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Noticed this while working on Leyden, which has to enumerate Shenandoah stubs for code archival to work.
> 
> `ShenandoahRuntime::shenandoah_clone_barrier` is excessive name. `ShenandoahRuntime::arraycopy_barrier_oop_entry` and friends is not covered by `JRT_LEAF`. This change hopefully homogenizes the namings for the stubs.
> 
> Additional testing:
>  - [x] Linux x86_64 server fastdebug, `hotspot_gc_shenandoah` 
>  - [x] Linux AArch64 server fastdebug, `hotspot_gc_shenandoah`

Marked as reviewed by wkemper (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/21152#pullrequestreview-2334085291

From rkennke at openjdk.org  Fri Sep 27 16:25:54 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Fri, 27 Sep 2024 16:25:54 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v26]
In-Reply-To: <BtvwMUG5tcy_zU4tRG3Q5VVw08qE_3gSE35wCxlDnj4=.954353e5-cab2-48f4-b0f2-5852e586ba20@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <fEpfi4CzTFr1Pl-IyOAVyHNXWlVz33lHKQyzVY0kBc8=.cc39355b-ee7a-4118-952a-28e4184eec84@github.com>
 <DKuidQyyiiJOsrerLCeziselVyG9Ztpzsyc64ZNjlI4=.722fc4f7-d7cc-49df-9d82-5c1094508f74@github.com>
 <hdttC4LhHE6y6Nbq0jjJwxxF4W0hTfJLK_siODDCBkM=.1667f495-fcd9-4b7f-8d58-24e27665eeb3@github.com>
 <fWSdSqQfhOrGpFoExiaO4L-UDtR90_t0gRxp9YBO3_c=.0173618e-f392-4921-8fae-39d44b24de08@github.com>
 <6PTWMepIDuZDdPfN3xNKV1vqUyO_R4yCSeiSTpYIyyQ=.61a5b462-7114-4385-a6d7-40e5c7b0005d@github.com>
 <C5LwWrsa-VO87kdm_sYuisTGMsHoxv4Eoe0QikdkusE=.63b0993c-86c8-4ef6-a3cf-bc8a67e10815@github.com>
 <WOlTJMNHCr_Kk69sEIUwCVI3ZbiRlckY4TSBRfL7zoA=.1a4c59f1-a000-4d9f-abbc-36b24ed5105e@github.com>
 <UjwpWz9Y3W8WRzYHZmDk9EvoiLSCZG1aai5oASGtDKA=.68cab6dd-e67d-4651-a9c9-75dccf42d85f@github.com>
 <l_7f8gGpIdG9H3Ini5vHWruIa0oDi7fkn2Lz5thDI5c=.969b804f-bae2-48e1-9c44-e631d90037e7@github.com>
 <BtvwMUG5tcy_zU4tRG3Q5VVw08qE_3gSE35
 wCxlDnj4=.954353e5-cab2-48f4-b0f2-5852e586ba20@github.com>
Message-ID: <zi8MM6qUWhvxPSyb3ewa3baXWhmDIDlut2uYUQmWvcw=.7b32fa42-7a3f-43bb-8f15-fe6b8e66c49b@github.com>

On Fri, 27 Sep 2024 14:44:35 GMT, Scott Gibbons <sgibbons at openjdk.org> wrote:

>> I like to have the functional connection: if - for whatever reason - the array base offset is smaller than 16, we need to deal with that. The reason for this happens to be `UseCompactObjectHeaders`, but that may not be clear to the reader of the code. I could add an `assert(UseCompactObjectHeaders` in that branch to make that connection clear. Also consider that `UseCompactObjectHeaders` is intended to go away at some point.
>> 
>> I wonder if having 2 or 3 branches ahead of the main-loop (which probably doesn't do much, because haystack is <=32 bytes) is a useful approach, or if there may be a better way to get the bytes on the stack? I don't know enough about the implementation to make that judgement.
>
> I believe the code in the patch is good enough as-is, especially if `UseCompactObjectHeaders` is slated to go away.  The existing `if` will prevent the < 16 byte header code from being emitted, which is the desired behavior - i.e., if the header size is >= 16, there will be no code emitted to the intrinsic for that block.  So there will not be an additional branch for the code when it is executed.
> 
> I'm good with a comment tying `UseCompactObjectHeaders` to the condition.  The comment can be removed when the flag is removed.  "Ship it" :-)

Wait a second, I've probably not been clear. `UseCompactObjectHeaders` is slated to become *on by default* and then slated to go away. That means that array base offets <= 16 bytes will become the default. The generated code will be something like:


if (haystack_len <= 8) {
  // Copy 8 bytes onto stack
} else if (haystack_len <= 16) {
  // Copy 16 bytes onto stack
} else {
  // Copy 32 bytes onto stack
}


So that is 2 branches in this prologue code instead of originally 1.

However, I just noticed that what I proposed is not enough. Consider what happens when haystack_len is 17. This would take the last case and copy 32 bytes. But we only have 17+8=25 bytes that we can guarantee to be available for copying. If this happens to be the array at the very beginning of the heap (very rare/unlikely), this would segfault.

I think I need to mull over it some more to come up with a correct fix.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1778874906

From yzheng at openjdk.org  Fri Sep 27 16:34:55 2024
From: yzheng at openjdk.org (Yudi Zheng)
Date: Fri, 27 Sep 2024 16:34:55 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v9]
In-Reply-To: <2w9H6VAbxm7BgSGRwKAxbI56bG-k4bE_ZDviGrBF36o=.3d4cb47f-0f84-479a-a809-6d0186dfad2d@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <6Rant6SjxpFIHHWNthWc_plOdnGpWPvqj3rxRe144po=.bcdbad7a-e93a-41a3-b958-6ae602c7e083@github.com>
 <NR6CKOtdUaVarB7hiAUIAsIMe03qiTQr5VcEOWGt8mA=.164efc10-f0ff-4ddf-80b8-c56599c0ba7d@github.com>
 <BNQiyA0NCBO-oFZU4Nz3yvaMxDzICFxfqDKWt4wCL_U=.9405414d-f961-4168-8d26-ef5f58069161@github.com>
 <igBchd3diNsHdnQwZS2sj4tjaKejOq4f4EZovOmpmRQ=.abf79fee-9592-4555-ac01-de0170665ae4@github.com>
 <BkuKSFHleaF8I2tWCDIC-rGlWnfGhbK1zQ6CLlB-rVE=.9c7976e3-b0e9-4356-8d4b-d880aa30bffa@github.com>
 <ubcY5Q-aPRCLmhZV9MjBfzzbs84FegDvNkHx8nwPUd0=.46503fd8-d274-4558-bd0f-cc0c4f199667@github.com>
 <2w9H6VAbxm7BgSGRwKAxbI56bG-k4bE_ZDviGrBF36o=.3d4cb47f-0f84-479a-a809-6d0186dfad2d@github.com>
Message-ID: <CKaxMvoxrt7YLGw6Zee_SW8uBb8tg3j94mw-Mcf5u0I=.78240440-cee1-413b-ae49-1b85592d5ba7@github.com>

On Thu, 19 Sep 2024 14:22:51 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> We haven't decided whether or not we will git rid of ```Klass::_prototype_header``` before intergrating this PR, or not. @stefank could point you to a WIP branch, if that's helpful.
>
> This is my current work-in-progress code:
> https://github.com/stefank/jdk/compare/pull/20677...stefank:jdk:lilliput_remove_prototype_header_wip_2
> 
> I've made some large rewrites and I'm currently running it through functional testing.

If @stefank 's patch does not go in this PR, could you please export `Klass::_prototype_header` to JVMCI? Thanks!

diff --git a/src/hotspot/share/jvmci/vmStructs_jvmci.cpp b/src/hotspot/share/jvmci/vmStructs_jvmci.cpp
index 9d1b8a1cb9f..e462025074f 100644
--- a/src/hotspot/share/jvmci/vmStructs_jvmci.cpp
+++ b/src/hotspot/share/jvmci/vmStructs_jvmci.cpp
@@ -278,6 +278,7 @@
   nonstatic_field(Klass,                       _bitmap,                                       uintx)                                 \
   nonstatic_field(Klass,                       _hash_slot,                                    uint8_t)                               \
   nonstatic_field(Klass,                       _misc_flags._flags,                            u1)                                    \
+  nonstatic_field(Klass,                       _prototype_header,                             markWord)                              \
                                                                                                                                      \
   nonstatic_field(LocalVariableTableElement,   start_bci,                                     u2)                                    \
   nonstatic_field(LocalVariableTableElement,   length,                                        u2)                                    \

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1778884055

From xpeng at openjdk.org  Fri Sep 27 17:08:45 2024
From: xpeng at openjdk.org (Xiaolong Peng)
Date: Fri, 27 Sep 2024 17:08:45 GMT
Subject: Integrated: 8340490: Shenandoah: Optimize ShenandoahPacer
In-Reply-To: <mh4-1fuv1_9n0e_BCeIX-WHnXZN-1A7woAkyJinXkIU=.c03edc09-82fc-44c2-b09b-22d543fb4ec4@github.com>
References: <mh4-1fuv1_9n0e_BCeIX-WHnXZN-1A7woAkyJinXkIU=.c03edc09-82fc-44c2-b09b-22d543fb4ec4@github.com>
Message-ID: <aTtxcYcmm-03N8vsOsXZqy-F_0MeWpKggs1OcBvSdfA=.7cbc75c3-bd9a-40af-80dc-7bdca203f62b@github.com>

On Thu, 19 Sep 2024 23:32:14 GMT, Xiaolong Peng <xpeng at openjdk.org> wrote:

> In a simple latency benchmark for memory allocation, I found ShenandoahPacer contributed quite a lot to the long tail latency > 10ms, when there are multi mutator threads failed at fast path to claim budget [here](https://github.com/openjdk/jdk/blob/fdc16a373459cb2311316448c765b1bee5c73694/src/hotspot/share/gc/shenandoah/shenandoahPacer.cpp#L230), all of them will forcefully claim and them wait for up to 10ms([code link](https://github.com/openjdk/jdk/blob/fdc16a373459cb2311316448c765b1bee5c73694/src/hotspot/share/gc/shenandoah/shenandoahPacer.cpp#L239-L277))
> 
> The change in this PR makes ShenandoahPacer impact long tail latency much less, instead forcefully claim budget and them wait, it attempts to claim after waiting for 1ms, and keep doing this until: 1/ either spent 10ms waiting in total; 2/ or successfully claimed the budget.
> 
> Here the latency comparison for the optimization:
> ![hdr-histogram-optimize-pacer](https://github.com/user-attachments/assets/811f48c5-87eb-462d-8b27-d15bd08be7b0)
> 
> With the optimization, long tail latency from the test code below has been much improved from over 20ms to ~10ms on MacOS with M3 chip:
> 
>     static final int threadCount = Runtime.getRuntime().availableProcessors();
>     static final LongAdder totalCount = new LongAdder();
>     static volatile byte[] sink;
>     public static void main(String[] args) {
>         runAllocationTest(100000);
>     }
>     static void recordTimeToAllocate(final int dataSize, final Histogram histogram) {
>         long startTime = System.nanoTime();
>         sink = new byte[dataSize];
>         long endTime = System.nanoTime();
>         histogram.recordValue(endTime - startTime);
>     }
> 
>     static void runAllocationTest(final int dataSize) {
>         final long endTime = System.currentTimeMillis() + 30_000;
>         final CountDownLatch startSignal = new CountDownLatch(1);
>         final CountDownLatch finished = new CountDownLatch(threadCount);
>         final Thread[] threads = new Thread[threadCount];
>         final Histogram[] histograms = new Histogram[threadCount];
>         final Histogram totalHistogram = new Histogram(3600000000000L, 3);
>         for (int i = 0; i < threadCount; i++) {
>             final var histogram = new Histogram(3600000000000L, 3);
>             histograms[i] = histogram;
>             threads[i] = new Thread(() -> {
>                 wait(startSignal);
>                 do {
>                     recordTimeToAllocate(dataSize, histogram);
>                 } while (System.currentTimeMillis() < e...

This pull request has now been integrated.

Changeset: 65200a95
Author:    Xiaolong Peng <xpeng at openjdk.org>
Committer: Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/65200a9589e46956a2194b20c4c90d003351a539
Stats:     41 lines in 3 files changed: 8 ins; 16 del; 17 mod

8340490: Shenandoah: Optimize ShenandoahPacer

Reviewed-by: shade, kdnilsen

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

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

From wkemper at openjdk.org  Fri Sep 27 18:20:23 2024
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 27 Sep 2024 18:20:23 GMT
Subject: RFR: Merge openjdk/jdk:master [v2]
In-Reply-To: <yJ42M3jsHSGJzXQab6LBo9xLvFHsMkO-CQDDJv4UuJs=.72a08792-fd9d-4b8d-80cc-6c9c3db41681@github.com>
References: <yJ42M3jsHSGJzXQab6LBo9xLvFHsMkO-CQDDJv4UuJs=.72a08792-fd9d-4b8d-80cc-6c9c3db41681@github.com>
Message-ID: <m7jz3BClKvclNuO0GoVdbwIV6rUBTTS1UqEX-pvx9i0=.06353edb-1953-4514-b2ff-9837a1338cfd@github.com>

> Merges tag jdk-24+17

William Kemper has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase.

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

Changes:
  - all: https://git.openjdk.org/shenandoah/pull/505/files
  - new: https://git.openjdk.org/shenandoah/pull/505/files/10da2c21..10da2c21

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

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

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

From wkemper at openjdk.org  Fri Sep 27 18:20:24 2024
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 27 Sep 2024 18:20:24 GMT
Subject: Integrated: Merge openjdk/jdk:master
In-Reply-To: <yJ42M3jsHSGJzXQab6LBo9xLvFHsMkO-CQDDJv4UuJs=.72a08792-fd9d-4b8d-80cc-6c9c3db41681@github.com>
References: <yJ42M3jsHSGJzXQab6LBo9xLvFHsMkO-CQDDJv4UuJs=.72a08792-fd9d-4b8d-80cc-6c9c3db41681@github.com>
Message-ID: <IespM9POJyYxLF7v8POB87ASWRkioS_i6ZYaE2HmOAU=.e5b7fd10-c49a-429f-b61f-939c39a0959d@github.com>

On Fri, 27 Sep 2024 14:12:31 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Merges tag jdk-24+17

This pull request has now been integrated.

Changeset: a3db9e62
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.org/shenandoah/commit/a3db9e62b4992f627831bffaf13d84b51559ea70
Stats:     17776 lines in 400 files changed: 13032 ins; 2471 del; 2273 mod

Merge

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

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

From wkemper at openjdk.org  Fri Sep 27 21:16:40 2024
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 27 Sep 2024 21:16:40 GMT
Subject: RFR: 8336640: Shenandoah: Parallel worker use in
 parallel_heap_region_iterate
Message-ID: <8MA3iGfP8rjS_o2cKNEQBg0Qcah6zNplKkZg2bRk2UA=.f5b0f04b-c934-4058-81bf-b534c36c418e@github.com>

Clean backport.

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

Commit messages:
 - Backport e74edbaea9f09169f597a470f647f3b7d10cc71b

Changes: https://git.openjdk.org/shenandoah-jdk21u/pull/108/files
  Webrev: https://webrevs.openjdk.org/?repo=shenandoah-jdk21u&pr=108&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8336640
  Stats: 21 lines in 2 files changed: 14 ins; 0 del; 7 mod
  Patch: https://git.openjdk.org/shenandoah-jdk21u/pull/108.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah-jdk21u.git pull/108/head:pull/108

PR: https://git.openjdk.org/shenandoah-jdk21u/pull/108

From wkemper at openjdk.org  Fri Sep 27 21:23:11 2024
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 27 Sep 2024 21:23:11 GMT
Subject: Integrated: 8336640: Shenandoah: Parallel worker use in
 parallel_heap_region_iterate
In-Reply-To: <8MA3iGfP8rjS_o2cKNEQBg0Qcah6zNplKkZg2bRk2UA=.f5b0f04b-c934-4058-81bf-b534c36c418e@github.com>
References: <8MA3iGfP8rjS_o2cKNEQBg0Qcah6zNplKkZg2bRk2UA=.f5b0f04b-c934-4058-81bf-b534c36c418e@github.com>
Message-ID: <TjruMA1QsK8NfObWy1R3s1iMd4iLEYnPu3YrfPLlq8k=.0ffb9466-6b13-4fa8-bc00-c8e43d1cf018@github.com>

On Fri, 27 Sep 2024 21:11:37 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Clean backport.

This pull request has now been integrated.

Changeset: d7815100
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.org/shenandoah-jdk21u/commit/d7815100095a11ac1ae325eec46647290922a635
Stats:     21 lines in 2 files changed: 14 ins; 0 del; 7 mod

8336640: Shenandoah: Parallel worker use in parallel_heap_region_iterate

Backport-of: e74edbaea9f09169f597a470f647f3b7d10cc71b

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

PR: https://git.openjdk.org/shenandoah-jdk21u/pull/108

From wkemper at openjdk.org  Fri Sep 27 21:35:05 2024
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 27 Sep 2024 21:35:05 GMT
Subject: RFR: 8332697: ubsan: shenandoahSimpleBitMap.inline.hpp:68:23: runtime
 error: signed integer overflow: -9223372036854775808 - 1 cannot be
 represented in type 'long int'
Message-ID: <I8sOa0g-PbjrI3R9yuuosgg83kNah0m0wiLbsNN8IFM=.495943c2-9206-44c5-abb1-4f68cd98b0c5@github.com>

Use an unsigned version of `right_n_bits`.

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

Commit messages:
 - Use an unsigned variant of right_n_bits

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

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

From wkemper at openjdk.org  Fri Sep 27 23:26:33 2024
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 27 Sep 2024 23:26:33 GMT
Subject: RFR: 8332697: ubsan: shenandoahSimpleBitMap.inline.hpp:68:23:
 runtime error: signed integer overflow: -9223372036854775808 - 1 cannot be
 represented in type 'long int' [v2]
In-Reply-To: <I8sOa0g-PbjrI3R9yuuosgg83kNah0m0wiLbsNN8IFM=.495943c2-9206-44c5-abb1-4f68cd98b0c5@github.com>
References: <I8sOa0g-PbjrI3R9yuuosgg83kNah0m0wiLbsNN8IFM=.495943c2-9206-44c5-abb1-4f68cd98b0c5@github.com>
Message-ID: <w6J3PVBQ9SVVEp2MaMORMCyMd0lXyksDMYiBkSTzUSk=.8cf70b3c-8e93-4f30-b7dc-7adaf64486cb@github.com>

> Use an unsigned version of `right_n_bits`.

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

  Use template to match type of subtrahend and minuend

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21236/files
  - new: https://git.openjdk.org/jdk/pull/21236/files/4e33d52f..a3fb5858

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

  Stats: 29 lines in 3 files changed: 4 ins; 3 del; 22 mod
  Patch: https://git.openjdk.org/jdk/pull/21236.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21236/head:pull/21236

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

From wkemper at openjdk.org  Fri Sep 27 23:39:15 2024
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 27 Sep 2024 23:39:15 GMT
Subject: RFR: 8332697: ubsan: shenandoahSimpleBitMap.inline.hpp:68:23:
 runtime error: signed integer overflow: -9223372036854775808 - 1 cannot be
 represented in type 'long int' [v3]
In-Reply-To: <I8sOa0g-PbjrI3R9yuuosgg83kNah0m0wiLbsNN8IFM=.495943c2-9206-44c5-abb1-4f68cd98b0c5@github.com>
References: <I8sOa0g-PbjrI3R9yuuosgg83kNah0m0wiLbsNN8IFM=.495943c2-9206-44c5-abb1-4f68cd98b0c5@github.com>
Message-ID: <G1ZPGXEoLjBF6PKKptpfHZfitfTsLQZfuTAHvNRSuz8=.caed0816-0227-47f5-9d4f-1e95e18f5e39@github.com>

> Use a template version of `right_n_bits` to use the same type for minuend and subtrahend.

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

  Fix comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21236/files
  - new: https://git.openjdk.org/jdk/pull/21236/files/a3fb5858..97d1272b

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

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

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

From phh at openjdk.org  Sun Sep 29 21:01:34 2024
From: phh at openjdk.org (Paul Hohensee)
Date: Sun, 29 Sep 2024 21:01:34 GMT
Subject: RFR: 8332697: ubsan: shenandoahSimpleBitMap.inline.hpp:68:23:
 runtime error: signed integer overflow: -9223372036854775808 - 1 cannot be
 represented in type 'long int' [v3]
In-Reply-To: <G1ZPGXEoLjBF6PKKptpfHZfitfTsLQZfuTAHvNRSuz8=.caed0816-0227-47f5-9d4f-1e95e18f5e39@github.com>
References: <I8sOa0g-PbjrI3R9yuuosgg83kNah0m0wiLbsNN8IFM=.495943c2-9206-44c5-abb1-4f68cd98b0c5@github.com>
 <G1ZPGXEoLjBF6PKKptpfHZfitfTsLQZfuTAHvNRSuz8=.caed0816-0227-47f5-9d4f-1e95e18f5e39@github.com>
Message-ID: <tUFC0HZBXgjR-L3CeomY9kgZYSFndJpQBbqqLZVSsNo=.1630cd38-f726-46ca-9e4e-53469cd60bc3@github.com>

On Fri, 27 Sep 2024 23:39:15 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> Use a template version of `right_n_bits` to use the same type for minuend and subtrahend.
>
> William Kemper has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix comments

Rather than define a new method get_right_n_bits(), why not just replace the definition of right_n_bits() in globalDefinitions.hpp? The C++ compiler will inline and optimize both.

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

PR Review: https://git.openjdk.org/jdk/pull/21236#pullrequestreview-2335997131

From shade at openjdk.org  Mon Sep 30 07:05:42 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 30 Sep 2024 07:05:42 GMT
Subject: Integrated: 8340181: Shenandoah: Cleanup ShenandoahRuntime stubs
In-Reply-To: <ouGDYCKqo9EzfJXsxc6HBULKYcyeCopgyYLuYs05B2o=.be5eadfe-4b07-4429-9257-9b7be0b69264@github.com>
References: <ouGDYCKqo9EzfJXsxc6HBULKYcyeCopgyYLuYs05B2o=.be5eadfe-4b07-4429-9257-9b7be0b69264@github.com>
Message-ID: <rm9iyIV75EjkTb9_NdpIfRdCh_vMYAm_HCQkGSxgaZo=.1d6100df-30e9-42e6-8645-4f61af4fc6fd@github.com>

On Tue, 24 Sep 2024 08:52:21 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Noticed this while working on Leyden, which has to enumerate Shenandoah stubs for code archival to work.
> 
> `ShenandoahRuntime::shenandoah_clone_barrier` is excessive name. `ShenandoahRuntime::arraycopy_barrier_oop_entry` and friends is not covered by `JRT_LEAF`. This change hopefully homogenizes the namings for the stubs.
> 
> Additional testing:
>  - [x] Linux x86_64 server fastdebug, `hotspot_gc_shenandoah` 
>  - [x] Linux AArch64 server fastdebug, `hotspot_gc_shenandoah`

This pull request has now been integrated.

Changeset: 988a531b
Author:    Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/988a531b097ccbd699d233059d73f41cae24dc5b
Stats:     71 lines in 9 files changed: 7 ins; 11 del; 53 mod

8340181: Shenandoah: Cleanup ShenandoahRuntime stubs

Reviewed-by: adinn, phh, wkemper

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

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

From rcastanedalo at openjdk.org  Mon Sep 30 12:40:54 2024
From: rcastanedalo at openjdk.org (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Mon, 30 Sep 2024 12:40:54 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v11]
In-Reply-To: <shoDPnL4nQyaYX4xy-WyzQ7CwsoCbAeCE3c755CkE1o=.caf940aa-5fbb-4cb5-a4a2-68a2452ffe1b@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <DUgk6HT_Zk5KnbmAd_HzrJi4B8D1J-uuoAGzReWyI8s=.6c04f90a-bf1d-49af-a31d-5224973952d4@github.com>
 <YTte6oY9EeAPHxzzOndL8M202wY91SbeaYC4hPva0W0=.caf00270-89c7-44b0-ab88-a970fb8e840d@github.com>
 <kzodWwxj5qdAqPYcP2s4k2QTXqjju2H6Iftu7dojezk=.1f72fc31-94ba-4017-b330-c8688a8d39a4@github.com>
 <hkGaBWSugvpV0PgoR9rnutHCgQzkeXv1ctH7QwV3zK0=.204737d5-fadb-410a-8891-7db59d36830f@github.com>
 <shoDPnL4nQyaYX4xy-WyzQ7CwsoCbAeCE3c755CkE1o=.caf940aa-5fbb-4cb5-a4a2-68a2452ffe1b@github.com>
Message-ID: <TBZCkcFNNnEvat7TBnRkqUPo4Y5TEe1L0iUZ9loD7DI=.39c0249c-f6b2-45c8-b7c8-9e2c9c1b7a99@github.com>

On Thu, 12 Sep 2024 13:20:14 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

> Indeed, I could re-enable all tests in:
> 
> ```
> test/hotspot/jtreg/compiler/c2/irTests/TestVectorizationMismatchedAccess.java
> test/hotspot/jtreg/compiler/c2/irTests/TestVectorizationNotRun.java
> test/hotspot/jtreg/compiler/loopopts/superword/TestIndependentPacksWithCyclicDependency.java
> ```
> 
> but unfortunately not those others:
> 
> ```
> > > > test/hotspot/jtreg/compiler/loopopts/superword/TestAlignVector.java
> > > > test/hotspot/jtreg/compiler/loopopts/superword/TestMulAddS2I.java
> ```
> 
> I think the issue with all of them is that vectorization in those scenarios only works when the operations inside the loop start at an array index that addresses an element at 8-byte-aligned offset.
> 
> I have filed https://bugs.openjdk.org/browse/JDK-8340010 to track it.

@rkennke A test run of the current changeset in our internal CI system revealed that the following tests fail (because of missing vectorization) when using `-XX:+UnlockExperimentalVMOptions -XX:+UseCompactObjectHeaders -XX:UseSSE=N` with `N <= 3` on an Intel Xeon Platinum 8358 machine:

- test/hotspot/jtreg/compiler/c2/irTests/TestVectorizationNotRun.java
- test/hotspot/jtreg/compiler/c2/irTests/TestVectorizationMismatchedAccess.java
- test/hotspot/jtreg/compiler/vectorization/runner/LoopCombinedOpTest.java

Here are the failure details:


test/hotspot/jtreg/compiler/c2/irTests/TestVectorizationNotRun.java:

1) Method "public static void compiler.c2.irTests.TestVectorizationNotRun.test(byte[],long[])" - [Failed IR rules: 1]:
   * @IR rule 1: "@compiler.lib.ir_framework.IR(phase={DEFAULT}, applyIfPlatformAnd={}, applyIfCPUFeatureOr={}, counts={"_#V#LOAD_VECTOR_L#_", ">=1", "_#STORE_VECTOR#_", ">=1"}, applyIfPlatform={}, applyIfPlatformOr={}, failOn={}, applyIfOr={}, applyIfCPUFeatureAnd={}, applyIf={}, applyIfCPUFeature={}, applyIfAnd={}, applyIfNot={})"
     > Phase "PrintIdeal":
       - counts: Graph contains wrong number of nodes:
         * Constraint 1: "(\\d+(\\s){2}(LoadVector.*)+(\\s){2}===.*vector[A-Za-z]\[2\]:\{long\})"
           - Failed comparison: [found] 0 >= 1 [given]
           - No nodes matched!
         * Constraint 2: "(\\d+(\\s){2}(StoreVector.*)+(\\s){2}===.*)"
           - Failed comparison: [found] 0 >= 1 [given]
           - No nodes matched!


test/hotspot/jtreg/compiler/c2/irTests/TestVectorizationMismatchedAccess.java:

1) Method "public static void compiler.c2.irTests.TestVectorizationMismatchedAccess.testByteByte1(byte[],byte[])" - [Failed IR rules: 1]:
   * @IR rule 1: "@compiler.lib.ir_framework.IR(phase={DEFAULT}, applyIfPlatformAnd={}, applyIfCPUFeatureOr={}, counts={"_#V#LOAD_VECTOR_L#_", ">=1", "_#STORE_VECTOR#_", ">=1"}, failOn={}, applyIfPlatform={}, applyIfPlatformOr={}, applyIfOr={}, applyIfCPUFeatureAnd={}, applyIf={}, applyIfCPUFeature={}, applyIfAnd={}, applyIfNot={})"
     > Phase "PrintIdeal":
       - counts: Graph contains wrong number of nodes:
         * Constraint 1: "(\\d+(\\s){2}(LoadVector.*)+(\\s){2}===.*vector[A-Za-z]\[2\]:\{long\})"
           - Failed comparison: [found] 0 >= 1 [given]
           - No nodes matched!
         * Constraint 2: "(\\d+(\\s){2}(StoreVector.*)+(\\s){2}===.*)"
           - Failed comparison: [found] 0 >= 1 [given]
           - No nodes matched!

2) Method "public static void compiler.c2.irTests.TestVectorizationMismatchedAccess.testByteByte2(byte[],byte[])" - [Failed IR rules: 1]:
   * @IR rule 1: "@compiler.lib.ir_framework.IR(phase={DEFAULT}, applyIfPlatformAnd={}, applyIfCPUFeatureOr={}, counts={"_#V#LOAD_VECTOR_L#_", ">=1", "_#STORE_VECTOR#_", ">=1"}, failOn={}, applyIfPlatform={}, applyIfPlatformOr={}, applyIfOr={}, applyIfCPUFeatureAnd={}, applyIf={}, applyIfCPUFeature={}, applyIfAnd={}, applyIfNot={})"
     > Phase "PrintIdeal":
       - counts: Graph contains wrong number of nodes:
         * Constraint 1: "(\\d+(\\s){2}(LoadVector.*)+(\\s){2}===.*vector[A-Za-z]\[2\]:\{long\})"
           - Failed comparison: [found] 0 >= 1 [given]
           - No nodes matched!
         * Constraint 2: "(\\d+(\\s){2}(StoreVector.*)+(\\s){2}===.*)"
           - Failed comparison: [found] 0 >= 1 [given]
           - No nodes matched!

3) Method "public static void compiler.c2.irTests.TestVectorizationMismatchedAccess.testByteLong1(byte[],long[])" - [Failed IR rules: 1]:
   * @IR rule 1: "@compiler.lib.ir_framework.IR(phase={DEFAULT}, applyIfPlatformAnd={}, applyIfCPUFeatureOr={}, counts={"_#V#LOAD_VECTOR_L#_", ">=1", "_#STORE_VECTOR#_", ">=1"}, failOn={}, applyIfPlatform={}, applyIfPlatformOr={}, applyIfOr={}, applyIfCPUFeatureAnd={}, applyIf={}, applyIfCPUFeature={}, applyIfAnd={}, applyIfNot={})"
     > Phase "PrintIdeal":
       - counts: Graph contains wrong number of nodes:
         * Constraint 1: "(\\d+(\\s){2}(LoadVector.*)+(\\s){2}===.*vector[A-Za-z]\[2\]:\{long\})"
           - Failed comparison: [found] 0 >= 1 [given]
           - No nodes matched!
         * Constraint 2: "(\\d+(\\s){2}(StoreVector.*)+(\\s){2}===.*)"
           - Failed comparison: [found] 0 >= 1 [given]
           - No nodes matched!

4) Method "public static void compiler.c2.irTests.TestVectorizationMismatchedAccess.testByteLong2(byte[],long[])" - [Failed IR rules: 1]:
   * @IR rule 1: "@compiler.lib.ir_framework.IR(phase={DEFAULT}, applyIfPlatformAnd={}, applyIfCPUFeatureOr={}, counts={"_#V#LOAD_VECTOR_L#_", ">=1", "_#STORE_VECTOR#_", ">=1"}, failOn={}, applyIfPlatform={}, applyIfPlatformOr={}, applyIfOr={}, applyIfCPUFeatureAnd={}, applyIf={}, applyIfCPUFeature={}, applyIfAnd={}, applyIfNot={})"
     > Phase "PrintIdeal":
       - counts: Graph contains wrong number of nodes:
         * Constraint 1: "(\\d+(\\s){2}(LoadVector.*)+(\\s){2}===.*vector[A-Za-z]\[2\]:\{long\})"
           - Failed comparison: [found] 0 >= 1 [given]
           - No nodes matched!
         * Constraint 2: "(\\d+(\\s){2}(StoreVector.*)+(\\s){2}===.*)"
           - Failed comparison: [found] 0 >= 1 [given]
           - No nodes matched!

5) Method "public static void compiler.c2.irTests.TestVectorizationMismatchedAccess.testByteLong3(byte[],long[])" - [Failed IR rules: 1]:
   * @IR rule 1: "@compiler.lib.ir_framework.IR(phase={DEFAULT}, applyIfPlatformAnd={}, applyIfCPUFeatureOr={}, counts={"_#V#LOAD_VECTOR_L#_", ">=1", "_#STORE_VECTOR#_", ">=1"}, failOn={}, applyIfPlatform={}, applyIfPlatformOr={}, applyIfOr={}, applyIfCPUFeatureAnd={}, applyIf={}, applyIfCPUFeature={}, applyIfAnd={}, applyIfNot={})"
     > Phase "PrintIdeal":
       - counts: Graph contains wrong number of nodes:
         * Constraint 1: "(\\d+(\\s){2}(LoadVector.*)+(\\s){2}===.*vector[A-Za-z]\[2\]:\{long\})"
           - Failed comparison: [found] 0 >= 1 [given]
           - No nodes matched!
         * Constraint 2: "(\\d+(\\s){2}(StoreVector.*)+(\\s){2}===.*)"
           - Failed comparison: [found] 0 >= 1 [given]
           - No nodes matched!

6) Method "public static void compiler.c2.irTests.TestVectorizationMismatchedAccess.testByteLong5(byte[],long[],int,int)" - [Failed IR rules: 1]:
   * @IR rule 1: "@compiler.lib.ir_framework.IR(phase={DEFAULT}, applyIfPlatformAnd={}, applyIfCPUFeatureOr={}, counts={"_#V#LOAD_VECTOR_L#_", ">=1", "_#STORE_VECTOR#_", ">=1"}, failOn={}, applyIfPlatform={}, applyIfPlatformOr={}, applyIfOr={}, applyIfCPUFeatureAnd={}, applyIf={}, applyIfCPUFeature={}, applyIfAnd={}, applyIfNot={})"
     > Phase "PrintIdeal":
       - counts: Graph contains wrong number of nodes:
         * Constraint 1: "(\\d+(\\s){2}(LoadVector.*)+(\\s){2}===.*vector[A-Za-z]\[2\]:\{long\})"
           - Failed comparison: [found] 0 >= 1 [given]
           - No nodes matched!
         * Constraint 2: "(\\d+(\\s){2}(StoreVector.*)+(\\s){2}===.*)"
           - Failed comparison: [found] 0 >= 1 [given]
           - No nodes matched!


test/hotspot/jtreg/compiler/vectorization/runner/LoopCombinedOpTest.java:

1) Method "public int[] compiler.vectorization.runner.LoopCombinedOpTest.multipleOpsWith2DifferentTypesAndComplexExpression()" - [Failed IR rules: 1]:
   * @IR rule 1: "@compiler.lib.ir_framework.IR(phase={DEFAULT}, applyIfPlatformAnd={}, applyIfCPUFeatureOr={"asimd", "true", "sse2", "true"}, counts={"_#STORE_VECTOR#_", ">0"}, failOn={}, applyIfPlatform={}, applyIfPlatformOr={}, applyIfOr={}, applyIfCPUFeatureAnd={}, applyIf={}, applyIfCPUFeature={}, applyIfAnd={}, applyIfNot={})"
     > Phase "PrintIdeal":
       - counts: Graph contains wrong number of nodes:
         * Constraint 1: "(\\d+(\\s){2}(StoreVector.*)+(\\s){2}===.*)"
           - Failed comparison: [found] 0 > 0 [given]
           - No nodes matched!

2) Method "public int[] compiler.vectorization.runner.LoopCombinedOpTest.multipleOpsWith2DifferentTypesAndInvariant()" - [Failed IR rules: 1]:
   * @IR rule 1: "@compiler.lib.ir_framework.IR(phase={DEFAULT}, applyIfPlatformAnd={}, applyIfCPUFeatureOr={"asimd", "true", "sse2", "true"}, counts={"_#STORE_VECTOR#_", ">0"}, failOn={}, applyIfPlatform={}, applyIfPlatformOr={}, applyIfOr={}, applyIfCPUFeatureAnd={}, applyIf={}, applyIfCPUFeature={}, applyIfAnd={}, applyIfNot={})"
     > Phase "PrintIdeal":
       - counts: Graph contains wrong number of nodes:
         * Constraint 1: "(\\d+(\\s){2}(StoreVector.*)+(\\s){2}===.*)"
           - Failed comparison: [found] 0 > 0 [given]
           - No nodes matched!

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

PR Comment: https://git.openjdk.org/jdk/pull/20677#issuecomment-2383072505

From shade at openjdk.org  Mon Sep 30 15:00:10 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 30 Sep 2024 15:00:10 GMT
Subject: RFR: 8340183: Shenandoah: LRB node is not matched as GC barrier after
 JDK-8340183
Message-ID: <QIPZMJIfweyc5taFSjRc3R1zPjHd6_xAvtyli0jW1iU=.c8dbf4eb-ca88-4f46-8703-55358599ab3c@github.com>

[JDK-8340183](https://bugs.openjdk.org/browse/JDK-8340183) introduced a regression: `ShenandoahBarrierSetC2::is_gc_barrier_node` is now answering `false` for the actual `ShenandoahLoadReferenceBarrierNode`. The fix reinstates the check for LRB node.

Additional testing:
 - [ ] Linux x86_64 server fastdebug, `hotspot_gc_shenandoah`
 - [x] Linux x86_64 server fastdebug, `jdk/jfr/api/consumer/ ` (100x) -- used to fail intermittently, now it does not

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

Commit messages:
 - Fix

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

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

From rkennke at openjdk.org  Mon Sep 30 15:18:35 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Mon, 30 Sep 2024 15:18:35 GMT
Subject: RFR: 8341242: Shenandoah: LRB node is not matched as GC barrier
 after JDK-8340183
In-Reply-To: <QIPZMJIfweyc5taFSjRc3R1zPjHd6_xAvtyli0jW1iU=.c8dbf4eb-ca88-4f46-8703-55358599ab3c@github.com>
References: <QIPZMJIfweyc5taFSjRc3R1zPjHd6_xAvtyli0jW1iU=.c8dbf4eb-ca88-4f46-8703-55358599ab3c@github.com>
Message-ID: <_pdzl3TfvgJVVZUL9VKDAsUIaulvTgYg7FcKzuAGATg=.4e7ce808-9ff9-4815-a016-08c81dfc1272@github.com>

On Mon, 30 Sep 2024 14:54:30 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> [JDK-8340183](https://bugs.openjdk.org/browse/JDK-8340183) introduced a regression: `ShenandoahBarrierSetC2::is_gc_barrier_node` is now answering `false` for the actual `ShenandoahLoadReferenceBarrierNode`. The fix reinstates the check for LRB node.
> 
> Additional testing:
>  - [ ] Linux x86_64 server fastdebug, `hotspot_gc_shenandoah`
>  - [x] Linux x86_64 server fastdebug, `jdk/jfr/api/consumer/ ` (100x) -- used to fail intermittently, now it does not

Looks good!

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

Marked as reviewed by rkennke (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21266#pullrequestreview-2337883746

From phh at openjdk.org  Mon Sep 30 16:40:35 2024
From: phh at openjdk.org (Paul Hohensee)
Date: Mon, 30 Sep 2024 16:40:35 GMT
Subject: RFR: 8341242: Shenandoah: LRB node is not matched as GC barrier
 after JDK-8340183
In-Reply-To: <QIPZMJIfweyc5taFSjRc3R1zPjHd6_xAvtyli0jW1iU=.c8dbf4eb-ca88-4f46-8703-55358599ab3c@github.com>
References: <QIPZMJIfweyc5taFSjRc3R1zPjHd6_xAvtyli0jW1iU=.c8dbf4eb-ca88-4f46-8703-55358599ab3c@github.com>
Message-ID: <N0Are4lg11cF62QxtMp-CbuVsojSZo63o_qvlvlVryw=.bb3d835e-85d3-4e8c-b251-d911a0fc29af@github.com>

On Mon, 30 Sep 2024 14:54:30 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> [JDK-8340183](https://bugs.openjdk.org/browse/JDK-8340183) introduced a regression: `ShenandoahBarrierSetC2::is_gc_barrier_node` is now answering `false` for the actual `ShenandoahLoadReferenceBarrierNode`. The fix reinstates the check for LRB node.
> 
> Additional testing:
>  - [ ] Linux x86_64 server fastdebug, `hotspot_gc_shenandoah`
>  - [x] Linux x86_64 server fastdebug, `jdk/jfr/api/consumer/ ` (100x) -- used to fail intermittently, now it does not

Marked as reviewed by phh (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/21266#pullrequestreview-2338076905

From shade at openjdk.org  Mon Sep 30 16:50:46 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 30 Sep 2024 16:50:46 GMT
Subject: RFR: 8341242: Shenandoah: LRB node is not matched as GC barrier
 after JDK-8340183
In-Reply-To: <QIPZMJIfweyc5taFSjRc3R1zPjHd6_xAvtyli0jW1iU=.c8dbf4eb-ca88-4f46-8703-55358599ab3c@github.com>
References: <QIPZMJIfweyc5taFSjRc3R1zPjHd6_xAvtyli0jW1iU=.c8dbf4eb-ca88-4f46-8703-55358599ab3c@github.com>
Message-ID: <atj4_-uUV39uleSX62sMEBlBA7lIODWkBGEtvmn4nOI=.733032b0-0eb9-47d8-bb47-b669fe3771e4@github.com>

On Mon, 30 Sep 2024 14:54:30 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> [JDK-8340183](https://bugs.openjdk.org/browse/JDK-8340183) introduced a regression: `ShenandoahBarrierSetC2::is_gc_barrier_node` is now answering `false` for the actual `ShenandoahLoadReferenceBarrierNode`. The fix reinstates the check for LRB node.
> 
> Additional testing:
>  - [ ] Linux x86_64 server fastdebug, `hotspot_gc_shenandoah`
>  - [x] Linux x86_64 server fastdebug, `jdk/jfr/api/consumer/ ` (100x) -- used to fail intermittently, now it does not

Thanks! Trivial, right? Restores the code to previous shape.

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

PR Comment: https://git.openjdk.org/jdk/pull/21266#issuecomment-2383696926

From wkemper at openjdk.org  Mon Sep 30 17:01:36 2024
From: wkemper at openjdk.org (William Kemper)
Date: Mon, 30 Sep 2024 17:01:36 GMT
Subject: RFR: 8332697: ubsan: shenandoahSimpleBitMap.inline.hpp:68:23:
 runtime error: signed integer overflow: -9223372036854775808 - 1 cannot be
 represented in type 'long int' [v3]
In-Reply-To: <G1ZPGXEoLjBF6PKKptpfHZfitfTsLQZfuTAHvNRSuz8=.caed0816-0227-47f5-9d4f-1e95e18f5e39@github.com>
References: <I8sOa0g-PbjrI3R9yuuosgg83kNah0m0wiLbsNN8IFM=.495943c2-9206-44c5-abb1-4f68cd98b0c5@github.com>
 <G1ZPGXEoLjBF6PKKptpfHZfitfTsLQZfuTAHvNRSuz8=.caed0816-0227-47f5-9d4f-1e95e18f5e39@github.com>
Message-ID: <BhAHctSmhJrk8PXpvvIaXwfrEdqhTBhTfQj2XgfzREA=.18dac0d1-1364-4f26-949a-77017388806d@github.com>

On Fri, 27 Sep 2024 23:39:15 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> Use a template version of `right_n_bits` to use the same type for minuend and subtrahend.
>
> William Kemper has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix comments

I tried that, but there is a warning at the macro declaration:

// (note: #define used only so that they can be used in enum constant definitions)
#define nth_bit(n)        (((n) >= BitsPerWord) ? 0 : (OneBit << (n)))
#define right_n_bits(n)   (nth_bit(n) - 1)

There are many usages of `right_n_bits` that use an unnamed enum constant, which will not accept a cast from a numeric type.

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

PR Comment: https://git.openjdk.org/jdk/pull/21236#issuecomment-2383717052

From rkennke at openjdk.org  Mon Sep 30 17:50:54 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Mon, 30 Sep 2024 17:50:54 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v26]
In-Reply-To: <zi8MM6qUWhvxPSyb3ewa3baXWhmDIDlut2uYUQmWvcw=.7b32fa42-7a3f-43bb-8f15-fe6b8e66c49b@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <fEpfi4CzTFr1Pl-IyOAVyHNXWlVz33lHKQyzVY0kBc8=.cc39355b-ee7a-4118-952a-28e4184eec84@github.com>
 <DKuidQyyiiJOsrerLCeziselVyG9Ztpzsyc64ZNjlI4=.722fc4f7-d7cc-49df-9d82-5c1094508f74@github.com>
 <hdttC4LhHE6y6Nbq0jjJwxxF4W0hTfJLK_siODDCBkM=.1667f495-fcd9-4b7f-8d58-24e27665eeb3@github.com>
 <fWSdSqQfhOrGpFoExiaO4L-UDtR90_t0gRxp9YBO3_c=.0173618e-f392-4921-8fae-39d44b24de08@github.com>
 <6PTWMepIDuZDdPfN3xNKV1vqUyO_R4yCSeiSTpYIyyQ=.61a5b462-7114-4385-a6d7-40e5c7b0005d@github.com>
 <C5LwWrsa-VO87kdm_sYuisTGMsHoxv4Eoe0QikdkusE=.63b0993c-86c8-4ef6-a3cf-bc8a67e10815@github.com>
 <WOlTJMNHCr_Kk69sEIUwCVI3ZbiRlckY4TSBRfL7zoA=.1a4c59f1-a000-4d9f-abbc-36b24ed5105e@github.com>
 <UjwpWz9Y3W8WRzYHZmDk9EvoiLSCZG1aai5oASGtDKA=.68cab6dd-e67d-4651-a9c9-75dccf42d85f@github.com>
 <l_7f8gGpIdG9H3Ini5vHWruIa0oDi7fkn2Lz5thDI5c=.969b804f-bae2-48e1-9c44-e631d90037e7@github.com>
 <BtvwMUG5tcy_zU4tRG3Q5VVw08qE_3gSE35
 wCxlDnj4=.954353e5-cab2-48f4-b0f2-5852e586ba20@github.com>
 <zi8MM6qUWhvxPSyb3ewa3baXWhmDIDlut2uYUQmWvcw=.7b32fa42-7a3f-43bb-8f15-fe6b8e66c49b@github.com>
Message-ID: <TSxYcKKfAdx7SsVcq6iwiySCLlkoVbXQO7a25vsiG4k=.29e59a6c-b8e0-42e9-8bdd-cc8ca23df146@github.com>

On Fri, 27 Sep 2024 16:23:15 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> I believe the code in the patch is good enough as-is, especially if `UseCompactObjectHeaders` is slated to go away.  The existing `if` will prevent the < 16 byte header code from being emitted, which is the desired behavior - i.e., if the header size is >= 16, there will be no code emitted to the intrinsic for that block.  So there will not be an additional branch for the code when it is executed.
>> 
>> I'm good with a comment tying `UseCompactObjectHeaders` to the condition.  The comment can be removed when the flag is removed.  "Ship it" :-)
>
> Wait a second, I've probably not been clear. `UseCompactObjectHeaders` is slated to become *on by default* and then slated to go away. That means that array base offets <= 16 bytes will become the default. The generated code will be something like:
> 
> 
> if (haystack_len <= 8) {
>   // Copy 8 bytes onto stack
> } else if (haystack_len <= 16) {
>   // Copy 16 bytes onto stack
> } else {
>   // Copy 32 bytes onto stack
> }
> 
> 
> So that is 2 branches in this prologue code instead of originally 1.
> 
> However, I just noticed that what I proposed is not enough. Consider what happens when haystack_len is 17. This would take the last case and copy 32 bytes. But we only have 17+8=25 bytes that we can guarantee to be available for copying. If this happens to be the array at the very beginning of the heap (very rare/unlikely), this would segfault.
> 
> I think I need to mull over it some more to come up with a correct fix.

I changed the header<16 version to be a small loop: https://github.com/rkennke/jdk/commit/bcba264ea5c15581647933db1163ca1dae39b6c5

The idea is the same as before, except it's made as a small loop with a maximum of 4 iterations (backward-branches), and it copies 8 bytes at a time, such that 1. it may copy up to 7 bytes that precede the array and 2. doesn't run over the end of the array (which would potentially crash).

I am not sure if using XMM_TMP1 and XMM_TMP2 there is ok, or if it would encode better to use one of the regular registers.?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1781535745

From phh at openjdk.org  Mon Sep 30 21:47:39 2024
From: phh at openjdk.org (Paul Hohensee)
Date: Mon, 30 Sep 2024 21:47:39 GMT
Subject: RFR: 8332697: ubsan: shenandoahSimpleBitMap.inline.hpp:68:23:
 runtime error: signed integer overflow: -9223372036854775808 - 1 cannot be
 represented in type 'long int' [v3]
In-Reply-To: <G1ZPGXEoLjBF6PKKptpfHZfitfTsLQZfuTAHvNRSuz8=.caed0816-0227-47f5-9d4f-1e95e18f5e39@github.com>
References: <I8sOa0g-PbjrI3R9yuuosgg83kNah0m0wiLbsNN8IFM=.495943c2-9206-44c5-abb1-4f68cd98b0c5@github.com>
 <G1ZPGXEoLjBF6PKKptpfHZfitfTsLQZfuTAHvNRSuz8=.caed0816-0227-47f5-9d4f-1e95e18f5e39@github.com>
Message-ID: <vZQV9QBDMMXU1YnC50Uy8_rzzj7x_fmKomArTdAQ7S8=.1bb41d79-3e8a-47f2-8dd8-88eca476d4c1@github.com>

On Fri, 27 Sep 2024 23:39:15 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> Use a template version of `right_n_bits` to use the same type for minuend and subtrahend.
>
> William Kemper has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix comments

In that case, I'd put get_right_n_bits() in globalDefinitions.hpp because it's generally useful, and a comment on why, of course. :)

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

PR Comment: https://git.openjdk.org/jdk/pull/21236#issuecomment-2384203382

From wkemper at openjdk.org  Mon Sep 30 21:51:09 2024
From: wkemper at openjdk.org (William Kemper)
Date: Mon, 30 Sep 2024 21:51:09 GMT
Subject: RFR: 8334315: Shenandoah: reduce GC logging noise
Message-ID: <TvjmXXo3f4y03qpBF_EMSVEbGejznKx0FvshQnMPTSc=.a490bdd7-e181-4841-a4e2-9b4d5ad0a636@github.com>

Not clean, just logging level changes.

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

Commit messages:
 - Backport f35af7171213c09107b99104a73022853bff91b0

Changes: https://git.openjdk.org/shenandoah-jdk21u/pull/109/files
  Webrev: https://webrevs.openjdk.org/?repo=shenandoah-jdk21u&pr=109&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8334315
  Stats: 22 lines in 1 file changed: 0 ins; 0 del; 22 mod
  Patch: https://git.openjdk.org/shenandoah-jdk21u/pull/109.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah-jdk21u.git pull/109/head:pull/109

PR: https://git.openjdk.org/shenandoah-jdk21u/pull/109

From wkemper at openjdk.org  Mon Sep 30 21:54:41 2024
From: wkemper at openjdk.org (William Kemper)
Date: Mon, 30 Sep 2024 21:54:41 GMT
Subject: RFR: 8340490: Shenandoah: Optimize ShenandoahPacer
Message-ID: <EtNQBNqQqhkAuw4Nk_X40jN_tPhkf0cKaBF1loQY5DM=.3ef479d3-3f86-48cf-ad75-52806d013a0c@github.com>

Not clean, one simple conflict.

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

Commit messages:
 - Backport 65200a9589e46956a2194b20c4c90d003351a539

Changes: https://git.openjdk.org/shenandoah-jdk21u/pull/110/files
  Webrev: https://webrevs.openjdk.org/?repo=shenandoah-jdk21u&pr=110&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8340490
  Stats: 41 lines in 3 files changed: 8 ins; 16 del; 17 mod
  Patch: https://git.openjdk.org/shenandoah-jdk21u/pull/110.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah-jdk21u.git pull/110/head:pull/110

PR: https://git.openjdk.org/shenandoah-jdk21u/pull/110

From wkemper at openjdk.org  Mon Sep 30 21:56:35 2024
From: wkemper at openjdk.org (William Kemper)
Date: Mon, 30 Sep 2024 21:56:35 GMT
Subject: RFR: 8337241: Shenandoah: Normalize include guards
Message-ID: <HBmlzNVFgkC0yjhm7oJFouv1xDau74uKbFvqTnZNK2w=.505b1b7c-f5cc-4489-acb8-910645c17860@github.com>

Trivial conflict.

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

Commit messages:
 - Backport 4f194f10a1481cdc9df4e6338f6cabd07a34c84c

Changes: https://git.openjdk.org/shenandoah-jdk21u/pull/111/files
  Webrev: https://webrevs.openjdk.org/?repo=shenandoah-jdk21u&pr=111&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8337241
  Stats: 10 lines in 4 files changed: 0 ins; 0 del; 10 mod
  Patch: https://git.openjdk.org/shenandoah-jdk21u/pull/111.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah-jdk21u.git pull/111/head:pull/111

PR: https://git.openjdk.org/shenandoah-jdk21u/pull/111

From wkemper at openjdk.org  Mon Sep 30 22:11:27 2024
From: wkemper at openjdk.org (William Kemper)
Date: Mon, 30 Sep 2024 22:11:27 GMT
Subject: RFR: 8337511: Implement JEP-404: Generational Shenandoah
 (Experimental)
Message-ID: <8N7AiGx8AZc-d6MgBEKVw5R-qk8J_1FBZH-SbzmydGg=.d7ac9a04-5fa3-47e3-8d24-c8efd28a51f7@github.com>

This PR merges JEP 404, a generational mode for the Shenandoah garbage collector. The JEP can be viewed here: https://openjdk.org/jeps/404. We would like to target JDK24 with this PR.

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

Commit messages:
 - 8337511: Implement JEP-404: Generational Shenandoah (Experimental)

Changes: https://git.openjdk.org/jdk/pull/21273/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21273&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8337511
  Stats: 22576 lines in 229 files changed: 20937 ins; 807 del; 832 mod
  Patch: https://git.openjdk.org/jdk/pull/21273.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21273/head:pull/21273

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

From ysr at openjdk.org  Mon Sep 30 22:27:56 2024
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Mon, 30 Sep 2024 22:27:56 GMT
Subject: RFR: 8337241: Shenandoah: Normalize include guards
In-Reply-To: <HBmlzNVFgkC0yjhm7oJFouv1xDau74uKbFvqTnZNK2w=.505b1b7c-f5cc-4489-acb8-910645c17860@github.com>
References: <HBmlzNVFgkC0yjhm7oJFouv1xDau74uKbFvqTnZNK2w=.505b1b7c-f5cc-4489-acb8-910645c17860@github.com>
Message-ID: <whdZu8Sjsvmj0Oi-sw0ZsSowoBl8YFbctP00DIJzDJg=.003f657d-852e-4214-9bb1-f61cc6d4894d@github.com>

On Mon, 30 Sep 2024 21:49:27 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Trivial conflict.

Marked as reviewed by ysr (Committer).

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

PR Review: https://git.openjdk.org/shenandoah-jdk21u/pull/111#pullrequestreview-2338725449

From ysr at openjdk.org  Mon Sep 30 22:34:50 2024
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Mon, 30 Sep 2024 22:34:50 GMT
Subject: RFR: 8340490: Shenandoah: Optimize ShenandoahPacer
In-Reply-To: <EtNQBNqQqhkAuw4Nk_X40jN_tPhkf0cKaBF1loQY5DM=.3ef479d3-3f86-48cf-ad75-52806d013a0c@github.com>
References: <EtNQBNqQqhkAuw4Nk_X40jN_tPhkf0cKaBF1loQY5DM=.3ef479d3-3f86-48cf-ad75-52806d013a0c@github.com>
Message-ID: <5f5gX00bg8siO6Vo85CaI0o9QK2euLduZoxFG2fbiKs=.b02121e1-96c1-4935-8ed1-ab282411cf25@github.com>

On Mon, 30 Sep 2024 21:47:37 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Not clean, one simple conflict.

Marked as reviewed by ysr (Committer).

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

PR Review: https://git.openjdk.org/shenandoah-jdk21u/pull/110#pullrequestreview-2338731709

From ysr at openjdk.org  Mon Sep 30 22:35:55 2024
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Mon, 30 Sep 2024 22:35:55 GMT
Subject: RFR: 8334315: Shenandoah: reduce GC logging noise
In-Reply-To: <TvjmXXo3f4y03qpBF_EMSVEbGejznKx0FvshQnMPTSc=.a490bdd7-e181-4841-a4e2-9b4d5ad0a636@github.com>
References: <TvjmXXo3f4y03qpBF_EMSVEbGejznKx0FvshQnMPTSc=.a490bdd7-e181-4841-a4e2-9b4d5ad0a636@github.com>
Message-ID: <dMLrQyZrAVhUQMyuwzb06942pK8AFGtGJR6niosr24c=.51ed20fc-1344-4ebf-a7c6-e9e8d86fed30@github.com>

On Mon, 30 Sep 2024 21:46:31 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Not clean, just logging level changes.

Marked as reviewed by ysr (Committer).

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

PR Review: https://git.openjdk.org/shenandoah-jdk21u/pull/109#pullrequestreview-2338733201

From wkemper at openjdk.org  Mon Sep 30 23:08:57 2024
From: wkemper at openjdk.org (William Kemper)
Date: Mon, 30 Sep 2024 23:08:57 GMT
Subject: Integrated: 8337241: Shenandoah: Normalize include guards
In-Reply-To: <HBmlzNVFgkC0yjhm7oJFouv1xDau74uKbFvqTnZNK2w=.505b1b7c-f5cc-4489-acb8-910645c17860@github.com>
References: <HBmlzNVFgkC0yjhm7oJFouv1xDau74uKbFvqTnZNK2w=.505b1b7c-f5cc-4489-acb8-910645c17860@github.com>
Message-ID: <5tcYqf7Yl60srdKlG-ENw30ubgo8MdngiRkGKsCEDF8=.5c62bc39-f2f8-4759-8c9d-fbb7c3449ca4@github.com>

On Mon, 30 Sep 2024 21:49:27 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Trivial conflict.

This pull request has now been integrated.

Changeset: d1d530a0
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.org/shenandoah-jdk21u/commit/d1d530a0f2f8769c11b6931abfe63bcc21da3c2a
Stats:     10 lines in 4 files changed: 0 ins; 0 del; 10 mod

8337241: Shenandoah: Normalize include guards

Reviewed-by: ysr
Backport-of: 4f194f10a1481cdc9df4e6338f6cabd07a34c84c

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

PR: https://git.openjdk.org/shenandoah-jdk21u/pull/111

From wkemper at openjdk.org  Mon Sep 30 23:09:57 2024
From: wkemper at openjdk.org (William Kemper)
Date: Mon, 30 Sep 2024 23:09:57 GMT
Subject: Integrated: 8340490: Shenandoah: Optimize ShenandoahPacer
In-Reply-To: <EtNQBNqQqhkAuw4Nk_X40jN_tPhkf0cKaBF1loQY5DM=.3ef479d3-3f86-48cf-ad75-52806d013a0c@github.com>
References: <EtNQBNqQqhkAuw4Nk_X40jN_tPhkf0cKaBF1loQY5DM=.3ef479d3-3f86-48cf-ad75-52806d013a0c@github.com>
Message-ID: <K6J9zF5CmBfRw1856yRjvKE9musMZBzWKsFriKWmgzo=.0d2e1b16-3506-4cd0-bf3b-030fb7bc855b@github.com>

On Mon, 30 Sep 2024 21:47:37 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Not clean, one simple conflict.

This pull request has now been integrated.

Changeset: 413da1a4
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.org/shenandoah-jdk21u/commit/413da1a4aff75699d5af0763724800354c7aa70d
Stats:     41 lines in 3 files changed: 8 ins; 16 del; 17 mod

8340490: Shenandoah: Optimize ShenandoahPacer

Reviewed-by: ysr
Backport-of: 65200a9589e46956a2194b20c4c90d003351a539

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

PR: https://git.openjdk.org/shenandoah-jdk21u/pull/110

From wkemper at openjdk.org  Mon Sep 30 23:10:03 2024
From: wkemper at openjdk.org (William Kemper)
Date: Mon, 30 Sep 2024 23:10:03 GMT
Subject: Integrated: 8334315: Shenandoah: reduce GC logging noise
In-Reply-To: <TvjmXXo3f4y03qpBF_EMSVEbGejznKx0FvshQnMPTSc=.a490bdd7-e181-4841-a4e2-9b4d5ad0a636@github.com>
References: <TvjmXXo3f4y03qpBF_EMSVEbGejznKx0FvshQnMPTSc=.a490bdd7-e181-4841-a4e2-9b4d5ad0a636@github.com>
Message-ID: <BJXUZ-u2RlwrxY1tE7sVd79Wm3BIOf5OlxLTKSob1JY=.7f13dbcc-2971-42e2-9bff-957f7a5868f0@github.com>

On Mon, 30 Sep 2024 21:46:31 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Not clean, just logging level changes.

This pull request has now been integrated.

Changeset: e8f1584a
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.org/shenandoah-jdk21u/commit/e8f1584a0d3bfae2a6b36e3da4985771ed71a5d3
Stats:     22 lines in 1 file changed: 0 ins; 0 del; 22 mod

8334315: Shenandoah: reduce GC logging noise

Reviewed-by: ysr
Backport-of: f35af7171213c09107b99104a73022853bff91b0

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

PR: https://git.openjdk.org/shenandoah-jdk21u/pull/109

From wkemper at openjdk.org  Mon Sep 30 23:27:59 2024
From: wkemper at openjdk.org (William Kemper)
Date: Mon, 30 Sep 2024 23:27:59 GMT
Subject: RFR: 8340395: GenShen: Remove unnecessary check on card barrier flag
Message-ID: <4hGJm4U_QNzg_IYHJHmH-1m7cRZzBTlnCgaIYeb9wzw=.0d91984e-8c7b-4eae-a340-a445a6048dc9@github.com>

Clean backport.

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

Commit messages:
 - Backport e11a68f8168675ce3ddced82860b9b3d288707df

Changes: https://git.openjdk.org/shenandoah-jdk21u/pull/112/files
  Webrev: https://webrevs.openjdk.org/?repo=shenandoah-jdk21u&pr=112&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8340395
  Stats: 5 lines in 1 file changed: 0 ins; 1 del; 4 mod
  Patch: https://git.openjdk.org/shenandoah-jdk21u/pull/112.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah-jdk21u.git pull/112/head:pull/112

PR: https://git.openjdk.org/shenandoah-jdk21u/pull/112

From wkemper at openjdk.org  Mon Sep 30 23:50:56 2024
From: wkemper at openjdk.org (William Kemper)
Date: Mon, 30 Sep 2024 23:50:56 GMT
Subject: Integrated: 8340395: GenShen: Remove unnecessary check on card barrier
 flag
In-Reply-To: <4hGJm4U_QNzg_IYHJHmH-1m7cRZzBTlnCgaIYeb9wzw=.0d91984e-8c7b-4eae-a340-a445a6048dc9@github.com>
References: <4hGJm4U_QNzg_IYHJHmH-1m7cRZzBTlnCgaIYeb9wzw=.0d91984e-8c7b-4eae-a340-a445a6048dc9@github.com>
Message-ID: <0tS7OGvVPgV4Nx4qhyhRzE6K85PuKLo0NA36Jibss4s=.a378346f-b615-419a-821f-84c85373e049@github.com>

On Mon, 30 Sep 2024 23:22:58 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Clean backport.

This pull request has now been integrated.

Changeset: 66ad25a9
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.org/shenandoah-jdk21u/commit/66ad25a9e0a6a7f23ff00e4ed3175a2201f79052
Stats:     5 lines in 1 file changed: 0 ins; 1 del; 4 mod

8340395: GenShen: Remove unnecessary check on card barrier flag

Backport-of: e11a68f8168675ce3ddced82860b9b3d288707df

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

PR: https://git.openjdk.org/shenandoah-jdk21u/pull/112