From aboldtch at openjdk.org  Thu Jun  1 06:42:04 2023
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Thu, 1 Jun 2023 06:42:04 GMT
Subject: RFR: 8308752: Generational ZGC: Avoid final marking through stack
 chunks
In-Reply-To: <-4SrCIDBMltA1BGL79xit4RoKS-3fJXgR-eQRlxn9t8=.78be0a59-813b-4b08-8fd6-fc70eb65570d@github.com>
References: <-4SrCIDBMltA1BGL79xit4RoKS-3fJXgR-eQRlxn9t8=.78be0a59-813b-4b08-8fd6-fc70eb65570d@github.com>
Message-ID: <AEoB5sRGO7W1LA1qoW5nX0ZF_Z6N4PsxWssCZx8b4fU=.eb1559b2-16b7-4a98-a149-aa59e4ea17ad@github.com>

On Mon, 29 May 2023 15:31:02 GMT, Erik ?sterlund <eosterlund at openjdk.org> wrote:

> Single generation ZGC switches marking strength to strong unconditionally when marking through loom stack chunks, as there is no support for final marking through nmethod oops. We missed doing the same thing in generational ZGC, which is an oversight. This patch fixes that.

Marked as reviewed by aboldtch (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/14204#pullrequestreview-1454692913

From tschatzl at openjdk.org  Thu Jun  1 07:01:13 2023
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Thu, 1 Jun 2023 07:01:13 GMT
Subject: RFR: 8308766: TLAB initialization may cause div by zero
In-Reply-To: <NH4MM4hu8rSaZ64poX62vmmL9lOgyIxIE9Wr2hYhQ50=.694290a2-3724-4ab1-94e5-b8947152fb03@github.com>
References: <vJ_ZL7pfKSWzTcjkM0M58TYAPulkgtwn3tn9pkpgk0M=.d57ef62b-7d19-412b-90c2-75cec1c093a9@github.com>
 <NH4MM4hu8rSaZ64poX62vmmL9lOgyIxIE9Wr2hYhQ50=.694290a2-3724-4ab1-94e5-b8947152fb03@github.com>
Message-ID: <SooscSX8boJTL4bYyhHgtxz4VrrKvNf8lLzaaddf4Bw=.ead0636e-bb5a-4364-b5ab-d72d09e779a8@github.com>

On Thu, 25 May 2023 13:56:46 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Hi all,
>> 
>>   can I have reviews for this change that fixes an FP div by zero?
>> 
>> In `ThreadLocalAllocBuffer::initialize()` we initialize the TLAB using current available TLAB capacity for the thread. In G1, this can be zero in some situations, leading to that div by zero (see the CR for the crash when adding an assert).
>> The suggested fix is to just not sample at this point. TLAB resizing will fix TLAB sizing up.
>> 
>> Only G1 seems to be affected as it seems to be the only gc that uses a dynamic value for the capacity available for TLAB allocation. Other GCs seem to just use total heap capacity (Z, Shenandoah) or eden capacity (Serial, Parallel).
>> Not sure if that is actually better and I think won't result in the expected behavior (every thread should reload TLABs `target_refills()` times per mutator time); since even with G1 at TLAB resizing time eden is maximal, this hiccup at initialization does not seem too bad.
>> 
>> This may also be the cause for the behavior observed in https://bugs.openjdk.org/browse/JDK-8264798. 
>> 
>> Testing: gha
>> 
>> Thanks,
>>   Thomas
>
> Looking at where `_allocation_fraction` is accessed, wouldn't a variable capacity cause the alloc-amount to be miscalculated? I'd expect `capacity` to be const to more accurately track/predict #alloc-bytes.
> 
> 
>   // ** sampling place ** //
>   size_t capacity = Universe::heap()->tlab_capacity(thread()) / HeapWordSize;
>   float alloc_frac = desired_size() * target_refills() / (float)capacity;
>   _allocation_fraction.sample(alloc_frac);
> 
>   // ** where it's used ** //
>   // Compute the next tlab size using expected allocation amount
>   size_t alloc = (size_t)(_allocation_fraction.average() *
>                           (Universe::heap()->tlab_capacity(thread()) / HeapWordSize));

Thanks @albertnetymk @shipilev for your reviews.

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

PR Comment: https://git.openjdk.org/jdk/pull/14121#issuecomment-1571465723

From tschatzl at openjdk.org  Thu Jun  1 07:01:15 2023
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Thu, 1 Jun 2023 07:01:15 GMT
Subject: Integrated: 8308766: TLAB initialization may cause div by zero
In-Reply-To: <vJ_ZL7pfKSWzTcjkM0M58TYAPulkgtwn3tn9pkpgk0M=.d57ef62b-7d19-412b-90c2-75cec1c093a9@github.com>
References: <vJ_ZL7pfKSWzTcjkM0M58TYAPulkgtwn3tn9pkpgk0M=.d57ef62b-7d19-412b-90c2-75cec1c093a9@github.com>
Message-ID: <uH0Li0_-JWCcufUP_IegkPsBX1djDUOm6ZulMaD3Frc=.5f91cf95-1a55-4820-93b1-686201265fb9@github.com>

On Wed, 24 May 2023 11:50:02 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   can I have reviews for this change that fixes an FP div by zero?
> 
> In `ThreadLocalAllocBuffer::initialize()` we initialize the TLAB using current available TLAB capacity for the thread. In G1, this can be zero in some situations, leading to that div by zero (see the CR for the crash when adding an assert).
> The suggested fix is to just not sample at this point. TLAB resizing will fix TLAB sizing up.
> 
> Only G1 seems to be affected as it seems to be the only gc that uses a dynamic value for the capacity available for TLAB allocation. Other GCs seem to just use total heap capacity (Z, Shenandoah) or eden capacity (Serial, Parallel).
> Not sure if that is actually better and I think won't result in the expected behavior (every thread should reload TLABs `target_refills()` times per mutator time); since even with G1 at TLAB resizing time eden is maximal, this hiccup at initialization does not seem too bad.
> 
> This may also be the cause for the behavior observed in https://bugs.openjdk.org/browse/JDK-8264798. 
> 
> Testing: gha
> 
> Thanks,
>   Thomas

This pull request has now been integrated.

Changeset: 96ed1392
Author:    Thomas Schatzl <tschatzl at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/96ed1392d1c5062063b1f8b5f1bd30d2d17ce3fe
Stats:     5 lines in 1 file changed: 2 ins; 0 del; 3 mod

8308766: TLAB initialization may cause div by zero

Reviewed-by: shade, ayang

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

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

From tschatzl at openjdk.org  Thu Jun  1 08:22:10 2023
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Thu, 1 Jun 2023 08:22:10 GMT
Subject: RFR: 8140326: G1: Consider putting regions where evacuation failed
 into next collection set
In-Reply-To: <mmq6sEkAicO7Mc5FKkk5tcRVJDU6qtjYoyySho56F80=.aea5db50-0ec5-4e27-944e-2750af3d0bd7@github.com>
References: <mmq6sEkAicO7Mc5FKkk5tcRVJDU6qtjYoyySho56F80=.aea5db50-0ec5-4e27-944e-2750af3d0bd7@github.com>
Message-ID: <qypcDndFykV0I4rO8Rm-lsyo_p8zADmwDS6rrJdIrpo=.c92d8e96-7f83-4a5b-961c-0466b9b78d1f@github.com>

On Tue, 30 May 2023 14:00:30 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> This change adds management of retained regions, i.e. trying to evacuate evacuation failed regions asap.
> 
> The advantage is that evacuation failed regions do not need to wait until the next marking to be cleaned out; as they are often very sparsely occupied (often being eden regions), this occupies a lot of space, potentially causing additional evacuation failures later on.
> Another use of this change will be region pinning, which are basically evacuation failed regions that can not be reclaimed as long as they are pinned - however as soon as they are unpinned, they should be reclaimed for the same reasons as well.
> 
> It consists of several behavioral changes:
> 
> During garbage collection:
> 
> ... in the Evacuation phase:
> * always collect dirty cards into evacuation failed regions proactively. In tests, the amount of cards/live objects per evacuation failed region is typically very small. Dirty cards are always put into the global refinement buffer immediately, assuming that we will keep most if not all evacuation failed regions.
> 
> ... during Post Evacuation 2/Free Collection Set phase:
> * determine whether the region will be retained (kept for "immediate" evacuation) or not. Highly occupied regions are assumed to stay (mostly) live at least until the next marking, so do not bother with them.
> 
> These "retained" regions are collected in a new "from retained" set in the collection set candidates and managed separately from "from marking" regions. Having the "from retained" and "from marking" sets separate in the collection set candidates is easier to manage than to use a single list and the picking stuff from it. Particularly wrt to making sure that mixed gcs preferentially pick from the "from marking" list first, then second from the "from retained" list.
> 
> ... determining the collection set during the pause:
>   * during gc, the collection set is preferentially (first) populated with regions from the "from marking" candidates (these are the important regions to get cleaned out), second from the "from retained" list.
>   * g1 reserves up to 20% of max gc pause time for retained regions as optional candidates (this is a random number) to make sure that these are cleared out asap to free memory. There is also a minimum number of regions to take from the retained regions list.
> 
> During marking
> 
> ... changes to marking proper
> * retained regions will not be marked through during concurrent mark, i.e. they are considered outside of the snapshot. So they are ...

Because I've been asked about why the strict separation of from-marking and retained regions in the policy: to keep the current gc cycle policy fairly intact.
I.e. do the same as before, with some almost optional additional reclamation of known sparsely populated regions (compared to existing code).

The current heuristic to do young gcs, then a fixed amount of mixed gcs that clean out the old gen asap is, as ugly as it is, surprisingly good in the general case. Treating the retained regions the same as from-marking regions would make it necessary to rethink that: Retained regions are often/most of the time prime targets for evacuation (high efficiency), which means that g1 would start concentrating on these regions first even during the mixed phase (which is generally fine...), but due to how mixed gc works (use "smallest young gen", conceptually fixed amount of gcs) it ultimately would not clean out old gen *fast* enough (or completely, depends) as tuned right now. All the low efficiency regions would need to be cleaned out later. However the prediction isn't good enough to cope well with them. They are typically predicted worse than high efficicency ones, that means failing to be exact for them is worse than for high efficiency regions, so it will not take enough of them.

Now one could extend the mixed phase, but in corner cases g1 would then potentially stay in mixed phase (if evacuation failure/and later pinned regions were commonly encountered but still few) forever, which prohibits marking (leading to full gcs), and degrades performance (as it will be using a small young gen).

In some way, evacuation failed regions, can be seen as kind of extra regions/work due to a mismatch between application and VM configuration (compared to current master). Concentrating on that extra work in the phase that's about keeping the gc cycle going without full gc isn't the best thing to do (the current policy just has fairly strong provisions to take low efficiency regions and avoid full gc), particularly it has less overall impact to stuff high efficiency region collection into the existing young gcs that can go almost if not at full speed (i.e. it has less impact to be wrong about the prediction of a high efficiency region vs. low efficiency one).

Basically I think g1 ultimately needs to get away from what mixed gc is now, and how g1 determines when to start/stop that reclamation phase and how to determine the "right" amount of things to evacuate at what speed. That will certainly have to do something with making sure that the old gen allocation rate is countered, and at the same time being efficient overall (i.e. doing more than necessary to do as many young collections as possible within allowed time goal) without degrading into full gcs.

Fwiw: https://bugs.openjdk.org/browse/JDK-8159697.

I tried and failed to do that in this change (to be better than the current heuristic). Apart from being a different topic, this change in itself has its own merit: it improves resiliency vs. evacuation failure. In the past, what you often had is like having an evacuation failure because you ran out of memory. Since this produced lots of garbage, there has been a very high risk of getting into another evacuation failure because the even more decreased available free space causes gcs more often (smaller young gen available), which causes more surviving objects, resulting in more serious evacuation failures (with more live objects). Ultimately you end up with a full gc very quickly because there is not enough time to mark through the old gen.
With this change at least in the next young gc g1 will compact the evacuation failed regions fairly quickly (next gc), allow better recovery and/or allowing G1 to more easily not loose the race with the mutator until the next marking cycle.

Obviously it is also an important stepping stone for handling pinned regions reasonably.

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

PR Comment: https://git.openjdk.org/jdk/pull/14220#issuecomment-1571581367

From tschatzl at openjdk.org  Thu Jun  1 08:25:08 2023
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Thu, 1 Jun 2023 08:25:08 GMT
Subject: RFR: 8232722: G1 archive region deallocation may shrink the heap
 below -Xms
In-Reply-To: <5-VfLL5nXFl3sLdktHnNcFLOjvtKV_fWRJASUsvqbGo=.7590385f-c518-454f-895c-2f441fa13d99@github.com>
References: <olsv22PYjiSq7AOROlS48ALEEvZryCilV4X0pIZ9fzM=.e87699c0-2e12-4da1-bf01-0792e4a97057@github.com>
 <P2BlxKpVNHD--dIzxPHsnwr3v8VYM4SVIBRIdakr0Yo=.736714b5-914c-422e-a1a9-eeb36403f972@github.com>
 <CENOrQx6rFvJ3Nhp4m6pDMhjNxLBrUchMqobLzDQBBI=.82079d74-8174-4801-97f6-a498ac1b82c6@github.com>
 <5-VfLL5nXFl3sLdktHnNcFLOjvtKV_fWRJASUsvqbGo=.7590385f-c518-454f-895c-2f441fa13d99@github.com>
Message-ID: <7tWDwNhCcGN8q2bDmLRi9RVzY_wj5BDz84TBe5lQggc=.aba857a8-ff55-4450-b17a-b581983fd4ba@github.com>

On Wed, 31 May 2023 13:13:26 GMT, Ashutosh Mehra <duke at openjdk.org> wrote:

> > No real issue, but no real advantage either. In case of -Xms != -Xmx this would mean that the main method will not start with heap size of -Xms, but additional regions.
> 
> Right, that's the current behavior as well and not uncommitting the regions in `dealloc_archive_regions` doesn't change that. The difference appears only when the archive region mapping fails. If the regions are uncommitted it would bring back heap size to Xms. If not, heap size will remain slightly above Xms, which is same as the current behavior when mapping succeeds.

I do not think the current behavior is intended or good. It is at most tolerable. At least it has not been specified as correct in any documentation I could find, and it seems to counter to how initial heap size behaves with other collectors afaik (they just load the data into wherever it lands in old gen and fixes up references).

Hence filing https://bugs.openjdk.org/browse/JDK-8308854.

> The advantage is avoiding the need to track committed regions which avoids leaks more G1 specific details to CDS code. Adding GC policy specific details would make it harder to implement https://bugs.openjdk.org/browse/JDK-8296263. I am trying to move G1 specific code out of CDS in #14208. So if not uncommitting simplifies the things then why not?

That is a strange argument given that it causes some (minor) observable difference in behavior between collectors too. Having collectors behave the same helps reasoning about it.

I will look at the PR later today, haven't noticed it before.

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

PR Comment: https://git.openjdk.org/jdk/pull/14145#issuecomment-1571585857

From gli at openjdk.org  Thu Jun  1 09:02:22 2023
From: gli at openjdk.org (Guoxiong Li)
Date: Thu, 1 Jun 2023 09:02:22 GMT
Subject: RFR: 8194823: Serial GC does not account GCs caused by TLAB
 allocation in GC overhead limit [v2]
In-Reply-To: <7PQoFkIc--n8CWcJwLSksiSaIs1wk-MXDS39QsuLLQU=.3e8d1d80-12a6-4817-af60-0af3df248988@github.com>
References: <BXLdI5vFdnHqoH8Jk-g0DWDsSUwLjM87BemM0DVheH0=.138ae3a2-26af-4f07-aea3-3da1ece4facc@github.com>
 <Kda4kfCjCcjKiIDh0BonjNduQbiXVPeEUNFb8K46Uus=.fbcb1ea8-f867-4f3b-99ac-887c4276f12e@github.com>
 <7PQoFkIc--n8CWcJwLSksiSaIs1wk-MXDS39QsuLLQU=.3e8d1d80-12a6-4817-af60-0af3df248988@github.com>
Message-ID: <jSiDpJlY_zRAZTQBoHDjmdZtxVGM4g0deS2PoVtSK7Y=.7be7184f-bb2f-43d9-828b-6c38e191df1c@github.com>

On Mon, 29 May 2023 08:11:27 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> I think it's best to do the removing in another ticket/PR and link the two tickets.

Filed https://bugs.openjdk.org/browse/JDK-8309265 to follow up. Closing this one.

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

PR Comment: https://git.openjdk.org/jdk/pull/14120#issuecomment-1571637087

From gli at openjdk.org  Thu Jun  1 09:02:24 2023
From: gli at openjdk.org (Guoxiong Li)
Date: Thu, 1 Jun 2023 09:02:24 GMT
Subject: Withdrawn: 8194823: Serial GC does not account GCs caused by TLAB
 allocation in GC overhead limit
In-Reply-To: <BXLdI5vFdnHqoH8Jk-g0DWDsSUwLjM87BemM0DVheH0=.138ae3a2-26af-4f07-aea3-3da1ece4facc@github.com>
References: <BXLdI5vFdnHqoH8Jk-g0DWDsSUwLjM87BemM0DVheH0=.138ae3a2-26af-4f07-aea3-3da1ece4facc@github.com>
Message-ID: <hvnJv0xg6Uxy3DZ7rKbib6nmXAH8lDtHWQs8MG_GuW0=.3de148e9-b698-4b4b-8112-b69dfee6320a@github.com>

On Wed, 24 May 2023 10:54:16 GMT, Guoxiong Li <gli at openjdk.org> wrote:

> Hi all,
> 
> This patch enables the gc overhead limit when allocating TLAB in serial gc.
> The main modification is at `GenCollectedHeap::allocate_new_tlab` and the other 
> files only adjust the parameters of the method `allocate_new_tlab`.
> 
> Thanks for the review.
> 
> Best Regards,
> -- Guoxiong

This pull request has been closed without being integrated.

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

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

From gli at openjdk.org  Thu Jun  1 09:33:10 2023
From: gli at openjdk.org (Guoxiong Li)
Date: Thu, 1 Jun 2023 09:33:10 GMT
Subject: RFR: 8047998: -XX:MaxNewSize is unnecessarily set to NewSize if
 NewSize is too low [v2]
In-Reply-To: <x0XiQ_v_hgW3zTJeni10F93buDr224ALn-oqzJeH0j8=.48b829a2-dd45-48d1-bbdd-3cfb3037ebea@github.com>
References: <x0XiQ_v_hgW3zTJeni10F93buDr224ALn-oqzJeH0j8=.48b829a2-dd45-48d1-bbdd-3cfb3037ebea@github.com>
Message-ID: <OyY_PtBrYl63cgc1lVohoqRJ3tQy0sXZNubwCeb-mGY=.6ebb9afa-9812-4505-85ba-4dfcdfb9cf98@github.com>

> Hi all,
> 
> When `MaxHeapSize` is equal to `InitialHeapSize` and `NewSize` is set in command line,
> currently, the `max_young_size/MaxNewSize` will be set to the value of `NewSize`.
> 
> Considering the document of the `NewSize` (shown below), someone may set the `NewSize` 
> to a very small value and expect the JVM to adjust the value dynamically.
> Then when the `MaxHeapSize` is equal to `InitialHeapSize` (set by user or ergonomics),
> the `MaxNewSize` is set to the value of `NewSize`, which is small unexpectedly.
> 
> 
>   product(size_t, NewSize, ScaleForWordSize(1*M),                           \
>           "Initial new generation size (in bytes)")                         \
>           constraint(NewSizeConstraintFunc,AfterErgo)                       \
> 
> 
> This patch fixes the issue by setting the `MaxNewSize` to `NewSize` only when the `NewSize` 
> is larger than the original `max_young_size/MaxNewSize`.
> 
> The title of JDK-8047998 may need to adjusted.
> 
> Thanks for the review.
> 
> Best Regards,
> -- Guoxiong

Guoxiong Li 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:

 - Abort the vm instead of setting it implicitly.
 - Merge branch 'master' into JDK-8047998
 - JDK-8047998

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13876/files
  - new: https://git.openjdk.org/jdk/pull/13876/files/5614f4d3..d86264c8

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

  Stats: 159000 lines in 2768 files changed: 120360 ins; 19083 del; 19557 mod
  Patch: https://git.openjdk.org/jdk/pull/13876.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13876/head:pull/13876

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

From ayang at openjdk.org  Thu Jun  1 09:36:19 2023
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Thu, 1 Jun 2023 09:36:19 GMT
Subject: RFR: 8308507: G1: GClocker induced GCs can starve threads
 requiring memory leading to OOME [v4]
In-Reply-To: <bOFF29fUhB222MjlbU-ib-PqYwpxNp1crY-FcqQStck=.19433b75-5ef0-4364-b79f-35136f450d2c@github.com>
References: <OA_NUok57_CwYFRa6FjYHfQpxEIQrxO7tHQ-1VM3Cus=.1621f0a2-7766-41a0-a45b-94c2703ff4bf@github.com>
 <bOFF29fUhB222MjlbU-ib-PqYwpxNp1crY-FcqQStck=.19433b75-5ef0-4364-b79f-35136f450d2c@github.com>
Message-ID: <aaqgAVbBdwg6QO1wEKg_fzuaCxSVDzZYvvhjghv_diE=.120d8991-be9d-4cf0-9f26-89d4026abe82@github.com>

On Wed, 31 May 2023 08:38:43 GMT, Ivan Walulya <iwalulya at openjdk.org> wrote:

>> Please review this change which fixes the thread starvation problem during allocation for G1.
>> 
>> The starvation problem is not limited to GCLocker, however, currently, it manifests as an OOME only when GCLocker is active. In other cases, the starvation only affects the "starved" thread as it may loop indefinitely. 
>> 
>> Starvation with an active GCLocker happens as below:
>> 
>> 1. Thread A tries to allocate memory as normal, and tries to start a GC; the GCLocker is active and so the thread gets stalled waiting for the GC.
>> 2. GCLocker induced GC executes and frees some memory.
>> 3. Thread A does not get any of that memory, but other threads also waiting for memory.
>> 4. Goto 1 until the gclocker retry count has been reached.
>> 
>> In this change, we take the general approach to solving starvation problems with announcement tables (request queues). On slow allocation, a thread that wishes to complete an Allocation GC and then attempt an allocation, announces its allocation request before proceeding to participate in a race to execute a GC safepoint. Whichever thread succeeds in executing the Allocation GC safepoint will be tasked with completing all allocation requests that were announced before the safepoint. This guarantees that all announced allocation requests are either satisfied during the safepoint, or failed in case there is not enough memory to complete all requests. This effectively deals with the starvation issue and reduces the number of allocation GCs triggered.
>> 
>> Note: The change also adopts ZList from ZGC and makes it available under utilities as DoublyLinkedList with slight modifications. 
>> 
>> Testing: Tier 1-7
>
> Ivan Walulya has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Thomas review

src/hotspot/share/gc/g1/g1CollectedHeap.cpp line 419:

> 417: 
> 418:   if (should_try_gc) {
> 419:     bool succeeded = false;

Why is this var needed?

src/hotspot/share/gc/g1/g1CollectedHeap.cpp line 502:

> 500:     }
> 501: 
> 502:     if (attempt_allocation_after_gc(word_size, gc_count_before, should_try_gc, &result, GCCause::_g1_inc_collection_pause)) {

When this returns `false`, it would loop. Why is it safe/correct to discard `GCLockerRetryAllocationCount` here? (Can't find it in G1 code.)

src/hotspot/share/gc/g1/g1CollectedHeap.cpp line 1049:

> 1047:   bool *expect_null_alloc_regions = (bool*)alloca(active_numa_nodes * sizeof(bool));
> 1048:   for (uint i = 0; i < active_numa_nodes; i++) {
> 1049:     expect_null_alloc_regions[i] = expect_null_mutator_alloc_region;

AFAICS, this array is just for assert eventually, right? If so, how useful is that assert? Can it be removed?

src/hotspot/share/gc/g1/g1CollectedHeap.cpp line 1091:

> 1089:       // Fill the allocated memory with filler objects.
> 1090:       CollectedHeap::fill_with_objects(result, alloc_req->size());
> 1091:     }

Maybe some words on why fillers are required? Not obvious at first glance.

src/hotspot/share/gc/g1/g1CollectedHeap.hpp line 224:

> 222:   Mutex _alloc_request_lock;
> 223:   DoublyLinkedList<StalledAllocReq> _stalled_allocations;
> 224:   DoublyLinkedList<StalledAllocReq> _satisfied_allocations;

Not super obvious to me why two lists are needed since each element has `state` already. Can they be merged into one? Then, one can avoid the list manipulation in the following example.


    alloc_req->set_state(StalledAllocReq::AllocationState::Success, result);
    ...
    // Move the allocation request from stalled to satisfied list.
    _stalled_allocations.remove(alloc_req);
    _satisfied_allocations.insert_last(alloc_req);

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14077#discussion_r1212394009
PR Review Comment: https://git.openjdk.org/jdk/pull/14077#discussion_r1212399991
PR Review Comment: https://git.openjdk.org/jdk/pull/14077#discussion_r1212400889
PR Review Comment: https://git.openjdk.org/jdk/pull/14077#discussion_r1212401798
PR Review Comment: https://git.openjdk.org/jdk/pull/14077#discussion_r1212398469

From iwalulya at openjdk.org  Thu Jun  1 09:55:13 2023
From: iwalulya at openjdk.org (Ivan Walulya)
Date: Thu, 1 Jun 2023 09:55:13 GMT
Subject: RFR: 8308507: G1: GClocker induced GCs can starve threads
 requiring memory leading to OOME [v4]
In-Reply-To: <aaqgAVbBdwg6QO1wEKg_fzuaCxSVDzZYvvhjghv_diE=.120d8991-be9d-4cf0-9f26-89d4026abe82@github.com>
References: <OA_NUok57_CwYFRa6FjYHfQpxEIQrxO7tHQ-1VM3Cus=.1621f0a2-7766-41a0-a45b-94c2703ff4bf@github.com>
 <bOFF29fUhB222MjlbU-ib-PqYwpxNp1crY-FcqQStck=.19433b75-5ef0-4364-b79f-35136f450d2c@github.com>
 <aaqgAVbBdwg6QO1wEKg_fzuaCxSVDzZYvvhjghv_diE=.120d8991-be9d-4cf0-9f26-89d4026abe82@github.com>
Message-ID: <FCF44hnq7vrgcbH2ajIZ23tBEeAmG1N8ZyXSKz4Nkag=.618003f5-d6c3-4285-9eeb-b1996167fd99@github.com>

On Wed, 31 May 2023 22:51:54 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Ivan Walulya has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Thomas review
>
> src/hotspot/share/gc/g1/g1CollectedHeap.cpp line 419:
> 
>> 417: 
>> 418:   if (should_try_gc) {
>> 419:     bool succeeded = false;
> 
> Why is this var needed?

forced by existing implementation of `G1CollectedHeap::do_collection_pause`, I sure can change that and remove the need for the variable.

> src/hotspot/share/gc/g1/g1CollectedHeap.cpp line 502:
> 
>> 500:     }
>> 501: 
>> 502:     if (attempt_allocation_after_gc(word_size, gc_count_before, should_try_gc, &result, GCCause::_g1_inc_collection_pause)) {
> 
> When this returns `false`, it would loop. Why is it safe/correct to discard `GCLockerRetryAllocationCount` here? (Can't find it in G1 code.)

Because the false return will not be due to GCLocker.

> src/hotspot/share/gc/g1/g1CollectedHeap.cpp line 1049:
> 
>> 1047:   bool *expect_null_alloc_regions = (bool*)alloca(active_numa_nodes * sizeof(bool));
>> 1048:   for (uint i = 0; i < active_numa_nodes; i++) {
>> 1049:     expect_null_alloc_regions[i] = expect_null_mutator_alloc_region;
> 
> AFAICS, this array is just for assert eventually, right? If so, how useful is that assert? Can it be removed?

I wasn't in position to determine that, so I went with keeping it. Removing it would make the code a lot cleaner and also avoid the use of alloca, but again, I need guidance on the removing it part

> src/hotspot/share/gc/g1/g1CollectedHeap.hpp line 224:
> 
>> 222:   Mutex _alloc_request_lock;
>> 223:   DoublyLinkedList<StalledAllocReq> _stalled_allocations;
>> 224:   DoublyLinkedList<StalledAllocReq> _satisfied_allocations;
> 
> Not super obvious to me why two lists are needed since each element has `state` already. Can they be merged into one? Then, one can avoid the list manipulation in the following example.
> 
> 
>     alloc_req->set_state(StalledAllocReq::AllocationState::Success, result);
>     ...
>     // Move the allocation request from stalled to satisfied list.
>     _stalled_allocations.remove(alloc_req);
>     _satisfied_allocations.insert_last(alloc_req);

I thought it would be easier to follow with the two lists. I can merge them, If that is easier.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14077#discussion_r1212889822
PR Review Comment: https://git.openjdk.org/jdk/pull/14077#discussion_r1212894366
PR Review Comment: https://git.openjdk.org/jdk/pull/14077#discussion_r1212897636
PR Review Comment: https://git.openjdk.org/jdk/pull/14077#discussion_r1212890664

From gli at openjdk.org  Thu Jun  1 11:23:08 2023
From: gli at openjdk.org (Guoxiong Li)
Date: Thu, 1 Jun 2023 11:23:08 GMT
Subject: RFR: 8309265: Serial GC: remove the related code about GC overheap
 limit
Message-ID: <DsF4t8TB4x-hC4LZ0cWJuiVcOV3pk3-jUOEpplZPd30=.66e8793f-ae2f-4237-8bfc-e581fc9fc9a8@github.com>

Hi all,

This patch removes the unimplemented GC overhead limit related code in serial GC, mainly in `genCollectedHeap`.
It seems a leftover when removing the CMS.

Thanks for the review.

Best Regards,
-- Guoxiong

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

Commit messages:
 - JDK-8309265

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

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

From tschatzl at openjdk.org  Thu Jun  1 11:25:12 2023
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Thu, 1 Jun 2023 11:25:12 GMT
Subject: RFR: 8308507: G1: GClocker induced GCs can starve threads
 requiring memory leading to OOME [v4]
In-Reply-To: <FCF44hnq7vrgcbH2ajIZ23tBEeAmG1N8ZyXSKz4Nkag=.618003f5-d6c3-4285-9eeb-b1996167fd99@github.com>
References: <OA_NUok57_CwYFRa6FjYHfQpxEIQrxO7tHQ-1VM3Cus=.1621f0a2-7766-41a0-a45b-94c2703ff4bf@github.com>
 <bOFF29fUhB222MjlbU-ib-PqYwpxNp1crY-FcqQStck=.19433b75-5ef0-4364-b79f-35136f450d2c@github.com>
 <aaqgAVbBdwg6QO1wEKg_fzuaCxSVDzZYvvhjghv_diE=.120d8991-be9d-4cf0-9f26-89d4026abe82@github.com>
 <FCF44hnq7vrgcbH2ajIZ23tBEeAmG1N8ZyXSKz4Nkag=.618003f5-d6c3-4285-9eeb-b1996167fd99@github.com>
Message-ID: <9toAEaiqW_w9to2SXJ-LUQ_1bn5PSfSYFaYVDInvLZU=.961cb3bf-95c7-4ace-9647-818963e7b14d@github.com>

On Thu, 1 Jun 2023 09:52:41 GMT, Ivan Walulya <iwalulya at openjdk.org> wrote:

>> src/hotspot/share/gc/g1/g1CollectedHeap.cpp line 1049:
>> 
>>> 1047:   bool *expect_null_alloc_regions = (bool*)alloca(active_numa_nodes * sizeof(bool));
>>> 1048:   for (uint i = 0; i < active_numa_nodes; i++) {
>>> 1049:     expect_null_alloc_regions[i] = expect_null_mutator_alloc_region;
>> 
>> AFAICS, this array is just for assert eventually, right? If so, how useful is that assert? Can it be removed?
>
> I wasn't in position to determine that, so I went with keeping it. Removing it would make the code a lot cleaner and also avoid the use of alloca, but again, I need guidance on the removing it part

I'm good with this change removing it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14077#discussion_r1213003682

From ayang at openjdk.org  Thu Jun  1 11:41:06 2023
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Thu, 1 Jun 2023 11:41:06 GMT
Subject: RFR: 8309265: Serial: Remove the code related to GC overheap limit
In-Reply-To: <DsF4t8TB4x-hC4LZ0cWJuiVcOV3pk3-jUOEpplZPd30=.66e8793f-ae2f-4237-8bfc-e581fc9fc9a8@github.com>
References: <DsF4t8TB4x-hC4LZ0cWJuiVcOV3pk3-jUOEpplZPd30=.66e8793f-ae2f-4237-8bfc-e581fc9fc9a8@github.com>
Message-ID: <CunRidxshw8CxM0WkiuTmGkLY7Maaib5fitKuhtzHfo=.a575a673-4d92-4233-bb60-9494abf6f481@github.com>

On Thu, 1 Jun 2023 11:15:17 GMT, Guoxiong Li <gli at openjdk.org> wrote:

> Hi all,
> 
> This patch removes the unimplemented GC overhead limit related code in serial GC, mainly in `genCollectedHeap`.
> It seems a leftover when removing the CMS.
> 
> Thanks for the review.
> 
> Best Regards,
> -- Guoxiong

Marked as reviewed by ayang (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/14258#pullrequestreview-1455252636

From tschatzl at openjdk.org  Thu Jun  1 11:46:07 2023
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Thu, 1 Jun 2023 11:46:07 GMT
Subject: RFR: 8309265: Serial: Remove the code related to GC overheap limit
In-Reply-To: <DsF4t8TB4x-hC4LZ0cWJuiVcOV3pk3-jUOEpplZPd30=.66e8793f-ae2f-4237-8bfc-e581fc9fc9a8@github.com>
References: <DsF4t8TB4x-hC4LZ0cWJuiVcOV3pk3-jUOEpplZPd30=.66e8793f-ae2f-4237-8bfc-e581fc9fc9a8@github.com>
Message-ID: <ZNp17q-upT_96peOQmWC9GvdaOlrsyqlJKriVn6F99k=.3b628d89-6de5-41a5-8298-85cf73775f1b@github.com>

On Thu, 1 Jun 2023 11:15:17 GMT, Guoxiong Li <gli at openjdk.org> wrote:

> Hi all,
> 
> This patch removes the unimplemented GC overhead limit related code in serial GC, mainly in `genCollectedHeap`.
> It seems a leftover when removing the CMS.
> 
> Thanks for the review.
> 
> Best Regards,
> -- Guoxiong

lgtm.

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

Marked as reviewed by tschatzl (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14258#pullrequestreview-1455261676

From ayang at openjdk.org  Thu Jun  1 11:53:35 2023
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Thu, 1 Jun 2023 11:53:35 GMT
Subject: RFR: 8309286: G1: Remove unused G1HeapRegionAttr::is_valid_gen
Message-ID: <Zvcf0ZHkxNpQ4SBxnYuyXC2CNQoY2_MY49Ru13JkNE4=.f31fe4f5-886e-41a4-a0b1-fcc3c9d11de9@github.com>

Trivial removing dead code.

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

Commit messages:
 - trivial

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

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

From ayang at openjdk.org  Thu Jun  1 12:11:11 2023
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Thu, 1 Jun 2023 12:11:11 GMT
Subject: RFR: 8308507: G1: GClocker induced GCs can starve threads
 requiring memory leading to OOME [v4]
In-Reply-To: <FCF44hnq7vrgcbH2ajIZ23tBEeAmG1N8ZyXSKz4Nkag=.618003f5-d6c3-4285-9eeb-b1996167fd99@github.com>
References: <OA_NUok57_CwYFRa6FjYHfQpxEIQrxO7tHQ-1VM3Cus=.1621f0a2-7766-41a0-a45b-94c2703ff4bf@github.com>
 <bOFF29fUhB222MjlbU-ib-PqYwpxNp1crY-FcqQStck=.19433b75-5ef0-4364-b79f-35136f450d2c@github.com>
 <aaqgAVbBdwg6QO1wEKg_fzuaCxSVDzZYvvhjghv_diE=.120d8991-be9d-4cf0-9f26-89d4026abe82@github.com>
 <FCF44hnq7vrgcbH2ajIZ23tBEeAmG1N8ZyXSKz4Nkag=.618003f5-d6c3-4285-9eeb-b1996167fd99@github.com>
Message-ID: <w3KQqCP-8CV42be4xNWwavlV7BYWhnz9EPN9TTg7SyI=.e2ba6e10-bbae-4121-bb5e-45c85597971c@github.com>

On Thu, 1 Jun 2023 09:46:58 GMT, Ivan Walulya <iwalulya at openjdk.org> wrote:

>> src/hotspot/share/gc/g1/g1CollectedHeap.hpp line 224:
>> 
>>> 222:   Mutex _alloc_request_lock;
>>> 223:   DoublyLinkedList<StalledAllocReq> _stalled_allocations;
>>> 224:   DoublyLinkedList<StalledAllocReq> _satisfied_allocations;
>> 
>> Not super obvious to me why two lists are needed since each element has `state` already. Can they be merged into one? Then, one can avoid the list manipulation in the following example.
>> 
>> 
>>     alloc_req->set_state(StalledAllocReq::AllocationState::Success, result);
>>     ...
>>     // Move the allocation request from stalled to satisfied list.
>>     _stalled_allocations.remove(alloc_req);
>>     _satisfied_allocations.insert_last(alloc_req);
>
> I thought it would be easier to follow with the two lists. I can merge them, If that is easier.

I think it's the `state` that determines how element should be processed, regardless which list it lives on. If so, merging them sounds simpler. Could you try and see which approach is shorter/clearer/easier?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14077#discussion_r1213053912

From tschatzl at openjdk.org  Thu Jun  1 14:20:05 2023
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Thu, 1 Jun 2023 14:20:05 GMT
Subject: RFR: 8309286: G1: Remove unused G1HeapRegionAttr::is_valid_gen
In-Reply-To: <Zvcf0ZHkxNpQ4SBxnYuyXC2CNQoY2_MY49Ru13JkNE4=.f31fe4f5-886e-41a4-a0b1-fcc3c9d11de9@github.com>
References: <Zvcf0ZHkxNpQ4SBxnYuyXC2CNQoY2_MY49Ru13JkNE4=.f31fe4f5-886e-41a4-a0b1-fcc3c9d11de9@github.com>
Message-ID: <Sjm6gx9JikX_VLOCCpd2TV0-cdOymd3Rf2-3nnAztg4=.7bad9422-4037-4c1a-8c71-fc28810f2595@github.com>

On Thu, 1 Jun 2023 11:47:14 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Trivial removing dead code.

Ship it. Trivial.

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

Marked as reviewed by tschatzl (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14260#pullrequestreview-1455596400

From tschatzl at openjdk.org  Thu Jun  1 15:03:11 2023
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Thu, 1 Jun 2023 15:03:11 GMT
Subject: RFR: 8232722: G1 archive region deallocation may shrink the heap
 below -Xms
In-Reply-To: <olsv22PYjiSq7AOROlS48ALEEvZryCilV4X0pIZ9fzM=.e87699c0-2e12-4da1-bf01-0792e4a97057@github.com>
References: <olsv22PYjiSq7AOROlS48ALEEvZryCilV4X0pIZ9fzM=.e87699c0-2e12-4da1-bf01-0792e4a97057@github.com>
Message-ID: <7kUnLznyk6FoWofgi1_3XRgVoqKJRKAnmig0Idarf2o=.1c258286-873b-4223-ac71-eed2c01ed734@github.com>

On Thu, 25 May 2023 09:09:06 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   can I have reviews for this change that properly deallocates/uncommits CDS archive regions when failing to load the CDS archive?
> 
> In particular this caused the nuisance mentioned in the CR where even if -Xms==-Xmx, g1 uncommitted the heap memory anyway.
> 
> Testing: gha, manual testing as below
> 
> There is no (existing) way to induce CDS load errors easily, so what I did was adding `-XX:+UseNewCode` in `filemap.cpp:2202` to simulate failures when enabled. Obviously I removed the flag in this change.
> 
> Here's the problematic case:
> 
> 
> $java -XX:GCCardSizeInBytes=128 -Xmx128m -Xms128m -Xlog:gc+region=trace,gc+ergo+heap=debug -XX:+UseNewCode -version
> 
> [0.050s][trace][gc,region   ] G1HR ALLOC(OLD) [0x00000000ffe00000, 0x00000000fff00000, 0x00000000fff00000]
> [0.050s][trace][gc,region   ] G1HR ALLOC(OLD) [0x00000000fff00000, 0x00000000fff06278, 0x0000000100000000]
> [0.050s][trace][gc,region   ] G1HR INACTIVE(FREE) [0x00000000ffe00000, 0x00000000ffe00000, 0x00000000fff00000]
> [0.050s][trace][gc,region   ] G1HR INACTIVE(FREE) [0x00000000fff00000, 0x00000000fff00000, 0x0000000100000000]
> [0.050s][debug][gc,ergo,heap] Attempt heap shrinking (CDS archive regions). Total size: 2097152B
> [0.050s][trace][gc,region   ] G1HR UNCOMMIT(FREE) [0x00000000ffe00000, 0x00000000ffe00000, 0x00000000fff00000]
> [0.050s][trace][gc,region   ] G1HR UNCOMMIT(FREE) [0x00000000fff00000, 0x00000000fff00000, 0x0000000100000000]
> [0.057s][trace][gc,region   ] G1HR ALLOC(EDEN) [0x00000000ffd00000, 0x00000000ffd00000, 0x00000000ffe00000]
> [0.129s][trace][gc,region   ] G1HR ALLOC(EDEN) [0x00000000ffc00000, 0x00000000ffc00000, 0x00000000ffd00000]
> openjdk version "21-internal" 2023-09-19
> 
> 
> (The `GCCardSizeInBytes` option is there to decrease the minimum heap alignment to 512kb/1M so that setting `-Xms` to an odd value in a later test works)
> 
> I.e. the CDS regions are unconditionally uncommitted even through `-Xms == -Xmx`.
> 
> The next case just illustrates current (pre-existing) behavior with `-Xms != -Xmx`, showing that CDS regions are always committed, leading to higher than `-Xms` memory usage. I will file an enhancement here, as it is acceptable behavior (to me).
> 
> 
> $ java -XX:GCCardSizeInBytes=128 -Xmx128m -Xms126m -Xlog:gc+region=trace,gc+ergo+heap=debug -XX:+UseNewCode -version
> 
> [0.048s][trace][gc,region   ] G1HR COMMIT(FREE) [0x00000000fff00000, 0x00000000fff00000, 0x0000000100000000]
> [0.048s][trace][gc,region   ] G1HR ACTIVE(FREE) [0x00000000fff00000, 0x00000...

Maybe it is better to make this change differently, and combine with https://bugs.openjdk.org/browse/JDK-8308854: archive allocation removes/uncommits regions from the heap first, then allocates the new memory. This keeps -Xms. Later deallocation simply frees that memory.

What do you think?

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

PR Comment: https://git.openjdk.org/jdk/pull/14145#issuecomment-1572221337

From ayang at openjdk.org  Thu Jun  1 15:03:17 2023
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Thu, 1 Jun 2023 15:03:17 GMT
Subject: RFR: 8047998: -XX:MaxNewSize is unnecessarily set to NewSize if
 NewSize is too low [v2]
In-Reply-To: <OyY_PtBrYl63cgc1lVohoqRJ3tQy0sXZNubwCeb-mGY=.6ebb9afa-9812-4505-85ba-4dfcdfb9cf98@github.com>
References: <x0XiQ_v_hgW3zTJeni10F93buDr224ALn-oqzJeH0j8=.48b829a2-dd45-48d1-bbdd-3cfb3037ebea@github.com>
 <OyY_PtBrYl63cgc1lVohoqRJ3tQy0sXZNubwCeb-mGY=.6ebb9afa-9812-4505-85ba-4dfcdfb9cf98@github.com>
Message-ID: <f4CtBm2qwrhtOkfd9g49W-S-vfUcg_2DINrw4Rx83lg=.e95ca164-115d-4e7d-aadf-a7a9d13d962a@github.com>

On Thu, 1 Jun 2023 09:33:10 GMT, Guoxiong Li <gli at openjdk.org> wrote:

>> Hi all,
>> 
>> When `MaxHeapSize` is equal to `InitialHeapSize` and `NewSize` is set in command line,
>> currently, the `max_young_size/MaxNewSize` will be set to the value of `NewSize`.
>> 
>> Considering the document of the `NewSize` (shown below), someone may set the `NewSize` 
>> to a very small value and expect the JVM to adjust the value dynamically.
>> Then when the `MaxHeapSize` is equal to `InitialHeapSize` (set by user or ergonomics),
>> the `MaxNewSize` is set to the value of `NewSize`, which is small unexpectedly.
>> 
>> 
>>   product(size_t, NewSize, ScaleForWordSize(1*M),                           \
>>           "Initial new generation size (in bytes)")                         \
>>           constraint(NewSizeConstraintFunc,AfterErgo)                       \
>> 
>> 
>> This patch fixes the issue by setting the `MaxNewSize` to `NewSize` only when the `NewSize` 
>> is larger than the original `max_young_size/MaxNewSize`.
>> 
>> The title of JDK-8047998 may need to adjusted.
>> 
>> Thanks for the review.
>> 
>> Best Regards,
>> -- Guoxiong
>
> Guoxiong Li 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:
> 
>  - Abort the vm instead of setting it implicitly.
>  - Merge branch 'master' into JDK-8047998
>  - JDK-8047998

Marked as reviewed by ayang (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/13876#pullrequestreview-1455698728

From mbaesken at openjdk.org  Thu Jun  1 15:03:14 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 1 Jun 2023 15:03:14 GMT
Subject: RFR: JDK-8309297: Adjust ShenandoahHeap print_heap_regions_on
Message-ID: <3EEbuWYZF264cbHXTzb825CwzVXY-5puhsWsZOS9ySM=.80200999-fc25-447f-9421-b5681e8cca02@github.com>

The ShenandoahHeap print_heap_regions_on method prints some brief description of the columns of the heap table, however the description is unsorted and seems to be not fully up to date.

Another thought - is the critical pins column (CP=critical pins)  still needed or always 0  and obsolete now?

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

Commit messages:
 - JDK-8309297

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

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

From mbaesken at openjdk.org  Thu Jun  1 15:03:15 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 1 Jun 2023 15:03:15 GMT
Subject: RFR: JDK-8309297: Adjust ShenandoahHeap print_heap_regions_on
In-Reply-To: <3EEbuWYZF264cbHXTzb825CwzVXY-5puhsWsZOS9ySM=.80200999-fc25-447f-9421-b5681e8cca02@github.com>
References: <3EEbuWYZF264cbHXTzb825CwzVXY-5puhsWsZOS9ySM=.80200999-fc25-447f-9421-b5681e8cca02@github.com>
Message-ID: <wgdmECdtqGp1CLiCM0zzpmAnaTJmOXRbxVtKvaW2guo=.1e0f2589-39da-476f-8d75-cf6f46350927@github.com>

On Thu, 1 Jun 2023 14:45:16 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> The ShenandoahHeap print_heap_regions_on method prints some brief description of the columns of the heap table, however the description is unsorted and seems to be not fully up to date.
> 
> Another thought - is the critical pins column (CP=critical pins)  still needed or always 0  and obsolete now?

Btw I also considered to add a table header  describing the columns, but was not sure if this is really desired?

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

PR Comment: https://git.openjdk.org/jdk/pull/14264#issuecomment-1572216969

From ayang at openjdk.org  Thu Jun  1 15:13:28 2023
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Thu, 1 Jun 2023 15:13:28 GMT
Subject: RFR: 8309306: G1: Move is_obj_dead from HeapRegion to G1CollectedHeap
Message-ID: <MYgx_BYquNBhL8TK0_MTTMq5I5gj6Er7bK-ArTwAKaw=.c65bc5fe-25e3-4e4f-896b-b32db18f5d94@github.com>

Simple refactoring around `HeapRegion::is_obj_dead`.

Test: hotspot_gc

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

Commit messages:
 - g1-is-obj-dead

Changes: https://git.openjdk.org/jdk/pull/14265/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14265&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8309306
  Stats: 37 lines in 4 files changed: 7 ins; 18 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/14265.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14265/head:pull/14265

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

From duke at openjdk.org  Thu Jun  1 15:19:10 2023
From: duke at openjdk.org (Ashutosh Mehra)
Date: Thu, 1 Jun 2023 15:19:10 GMT
Subject: RFR: 8232722: G1 archive region deallocation may shrink the heap
 below -Xms
In-Reply-To: <7kUnLznyk6FoWofgi1_3XRgVoqKJRKAnmig0Idarf2o=.1c258286-873b-4223-ac71-eed2c01ed734@github.com>
References: <olsv22PYjiSq7AOROlS48ALEEvZryCilV4X0pIZ9fzM=.e87699c0-2e12-4da1-bf01-0792e4a97057@github.com>
 <7kUnLznyk6FoWofgi1_3XRgVoqKJRKAnmig0Idarf2o=.1c258286-873b-4223-ac71-eed2c01ed734@github.com>
Message-ID: <CqoIfHXVdUJMk6liYwFgYrlX8Y1S2HwgFwJr3qL7fBQ=.bfb8f773-05d7-49f9-a643-dd9f00ade87d@github.com>

On Thu, 1 Jun 2023 15:00:13 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Maybe it is better to make this change differently, and combine with https://bugs.openjdk.org/browse/JDK-8308854: archive allocation removes/uncommits regions from the heap first, then allocates the new memory. This keeps -Xms. Later deallocation simply frees that memory.

+1 for this approach.

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

PR Comment: https://git.openjdk.org/jdk/pull/14145#issuecomment-1572250044

From mdoerr at openjdk.org  Thu Jun  1 16:01:08 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Thu, 1 Jun 2023 16:01:08 GMT
Subject: RFR: JDK-8309297: Adjust ShenandoahHeap print_heap_regions_on
In-Reply-To: <3EEbuWYZF264cbHXTzb825CwzVXY-5puhsWsZOS9ySM=.80200999-fc25-447f-9421-b5681e8cca02@github.com>
References: <3EEbuWYZF264cbHXTzb825CwzVXY-5puhsWsZOS9ySM=.80200999-fc25-447f-9421-b5681e8cca02@github.com>
Message-ID: <ZlrmAbsmUUvGduQiL1gs1Xo6AQNA0Y2Y09tmI9uG1EQ=.f8d2f428-c461-4821-9ade-471bc3b0206a@github.com>

On Thu, 1 Jun 2023 14:45:16 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> The ShenandoahHeap print_heap_regions_on method prints some brief description of the columns of the heap table, however the description is unsorted and seems to be not fully up to date.
> 
> Another thought - is the critical pins column (CP=critical pins)  still needed or always 0  and obsolete now?

`CP` is still used by `jni_GetPrimitiveArrayCritical` and `jni_GetStringCritical`. (Object pinning for critical JNI natives was already removed by https://bugs.openjdk.org/browse/JDK-8233343.)

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

PR Comment: https://git.openjdk.org/jdk/pull/14264#issuecomment-1572321489

From gli at openjdk.org  Thu Jun  1 22:40:12 2023
From: gli at openjdk.org (Guoxiong Li)
Date: Thu, 1 Jun 2023 22:40:12 GMT
Subject: RFR: 8272147: Consolidate preserved marks handling with other STW
 collectors
Message-ID: <jXZiOVJDgymUKJne7d-LXCpIx7xcPoFPGATHIGSw_HE=.cb5e5aa0-001c-4842-9c16-7cb70e41b8a2@github.com>

Hi all,

This patch removes the class `markSweep.hpp::PreservedMark` and uses the shared `PreservedMarksSet` instead.

In order to keep the meaning of the field `_preserved_marks` in `markSweep`,
I need to use `OopAndMarkWord` explicitly. So I move `OopAndMarkWord` out of `PreservedMarks`.

Tests:
`hotspot:tier1` passed locally (x86 & linux).

Thanks for the review.

Best Regards,
-- Guoxiong

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

Commit messages:
 - JDK-8272147

Changes: https://git.openjdk.org/jdk/pull/14274/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14274&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8272147
  Stats: 70 lines in 5 files changed: 19 ins; 34 del; 17 mod
  Patch: https://git.openjdk.org/jdk/pull/14274.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14274/head:pull/14274

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

From eosterlund at openjdk.org  Fri Jun  2 06:57:13 2023
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Fri, 2 Jun 2023 06:57:13 GMT
Subject: RFR: 8308752: Generational ZGC: Avoid final marking through stack
 chunks
In-Reply-To: <ZiAPBnz1AJfusckoGVgUKwj3ASI0JrHzS8ncJQEGW10=.17e1307a-5a02-44fe-a842-ccec38cd0043@github.com>
References: <-4SrCIDBMltA1BGL79xit4RoKS-3fJXgR-eQRlxn9t8=.78be0a59-813b-4b08-8fd6-fc70eb65570d@github.com>
 <ZiAPBnz1AJfusckoGVgUKwj3ASI0JrHzS8ncJQEGW10=.17e1307a-5a02-44fe-a842-ccec38cd0043@github.com>
Message-ID: <gedqbg1Qyx9SUG3HDw4NPFhfmDuMJ18sUsNVXcdveiQ=.c48d67b3-75e1-4c13-b443-14d46d23bfb8@github.com>

On Tue, 30 May 2023 06:57:45 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> Single generation ZGC switches marking strength to strong unconditionally when marking through loom stack chunks, as there is no support for final marking through nmethod oops. We missed doing the same thing in generational ZGC, which is an oversight. This patch fixes that.
>
> Marked as reviewed by stefank (Reviewer).

Thanks for the reviews @stefank and @xmas92!

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

PR Comment: https://git.openjdk.org/jdk/pull/14204#issuecomment-1573244050

From eosterlund at openjdk.org  Fri Jun  2 06:57:14 2023
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Fri, 2 Jun 2023 06:57:14 GMT
Subject: Integrated: 8308752: Generational ZGC: Avoid final marking through
 stack chunks
In-Reply-To: <-4SrCIDBMltA1BGL79xit4RoKS-3fJXgR-eQRlxn9t8=.78be0a59-813b-4b08-8fd6-fc70eb65570d@github.com>
References: <-4SrCIDBMltA1BGL79xit4RoKS-3fJXgR-eQRlxn9t8=.78be0a59-813b-4b08-8fd6-fc70eb65570d@github.com>
Message-ID: <9poN6YuLTULnjGD8zPIFHif34iEnc_4E5Cly4g35Jsk=.d5f50f86-dd2b-4ac5-9555-cd0c9e23d9ed@github.com>

On Mon, 29 May 2023 15:31:02 GMT, Erik ?sterlund <eosterlund at openjdk.org> wrote:

> Single generation ZGC switches marking strength to strong unconditionally when marking through loom stack chunks, as there is no support for final marking through nmethod oops. We missed doing the same thing in generational ZGC, which is an oversight. This patch fixes that.

This pull request has now been integrated.

Changeset: 8f1ce789
Author:    Erik ?sterlund <eosterlund at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8f1ce78907f2765ac59aef23f25201353355e046
Stats:     10 lines in 1 file changed: 1 ins; 0 del; 9 mod

8308752: Generational ZGC: Avoid final marking through stack chunks

Reviewed-by: stefank, aboldtch

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

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

From tschatzl at openjdk.org  Fri Jun  2 07:18:05 2023
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Fri, 2 Jun 2023 07:18:05 GMT
Subject: RFR: 8309306: G1: Move is_obj_dead from HeapRegion to
 G1CollectedHeap
In-Reply-To: <MYgx_BYquNBhL8TK0_MTTMq5I5gj6Er7bK-ArTwAKaw=.c65bc5fe-25e3-4e4f-896b-b32db18f5d94@github.com>
References: <MYgx_BYquNBhL8TK0_MTTMq5I5gj6Er7bK-ArTwAKaw=.c65bc5fe-25e3-4e4f-896b-b32db18f5d94@github.com>
Message-ID: <xNjb7vN5XhMcIN7YdGk9eLotHeiHC9MlYtBjPcuRHsI=.61bd4962-5722-43e3-94c2-01cd4d31214c@github.com>

On Thu, 1 Jun 2023 15:05:41 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple refactoring around `HeapRegion::is_obj_dead`.
> 
> Test: hotspot_gc

Marked as reviewed by tschatzl (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/14265#pullrequestreview-1456786302

From tschatzl at openjdk.org  Fri Jun  2 07:24:15 2023
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Fri, 2 Jun 2023 07:24:15 GMT
Subject: RFR: 8232722: G1 archive region deallocation may shrink the heap
 below -Xms
In-Reply-To: <CqoIfHXVdUJMk6liYwFgYrlX8Y1S2HwgFwJr3qL7fBQ=.bfb8f773-05d7-49f9-a643-dd9f00ade87d@github.com>
References: <olsv22PYjiSq7AOROlS48ALEEvZryCilV4X0pIZ9fzM=.e87699c0-2e12-4da1-bf01-0792e4a97057@github.com>
 <7kUnLznyk6FoWofgi1_3XRgVoqKJRKAnmig0Idarf2o=.1c258286-873b-4223-ac71-eed2c01ed734@github.com>
 <CqoIfHXVdUJMk6liYwFgYrlX8Y1S2HwgFwJr3qL7fBQ=.bfb8f773-05d7-49f9-a643-dd9f00ade87d@github.com>
Message-ID: <R758UCMJMEVQWslzjN3xi8fVOz8TmIQR_Hsk-kLVhSo=.ef2d0dc8-d379-480f-b5ea-736cb9b3c952@github.com>

On Thu, 1 Jun 2023 15:16:32 GMT, Ashutosh Mehra <duke at openjdk.org> wrote:

> > Maybe it is better to make this change differently, and combine with https://bugs.openjdk.org/browse/JDK-8308854: archive allocation removes/uncommits regions from the heap first, then allocates the new memory. This keeps -Xms. Later deallocation simply frees that memory.
> 
> +1 for this approach.

Retracting this change to try the other one.

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

PR Comment: https://git.openjdk.org/jdk/pull/14145#issuecomment-1573275004

From tschatzl at openjdk.org  Fri Jun  2 07:24:17 2023
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Fri, 2 Jun 2023 07:24:17 GMT
Subject: Withdrawn: 8232722: G1 archive region deallocation may shrink the heap
 below -Xms
In-Reply-To: <olsv22PYjiSq7AOROlS48ALEEvZryCilV4X0pIZ9fzM=.e87699c0-2e12-4da1-bf01-0792e4a97057@github.com>
References: <olsv22PYjiSq7AOROlS48ALEEvZryCilV4X0pIZ9fzM=.e87699c0-2e12-4da1-bf01-0792e4a97057@github.com>
Message-ID: <pX1pwNtkT7LM3vntT8zbGLzPgBnDIaONjQMGEzmHuQc=.df2a278c-b92d-4506-a2d0-259754a49372@github.com>

On Thu, 25 May 2023 09:09:06 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   can I have reviews for this change that properly deallocates/uncommits CDS archive regions when failing to load the CDS archive?
> 
> In particular this caused the nuisance mentioned in the CR where even if -Xms==-Xmx, g1 uncommitted the heap memory anyway.
> 
> Testing: gha, manual testing as below
> 
> There is no (existing) way to induce CDS load errors easily, so what I did was adding `-XX:+UseNewCode` in `filemap.cpp:2202` to simulate failures when enabled. Obviously I removed the flag in this change.
> 
> Here's the problematic case:
> 
> 
> $java -XX:GCCardSizeInBytes=128 -Xmx128m -Xms128m -Xlog:gc+region=trace,gc+ergo+heap=debug -XX:+UseNewCode -version
> 
> [0.050s][trace][gc,region   ] G1HR ALLOC(OLD) [0x00000000ffe00000, 0x00000000fff00000, 0x00000000fff00000]
> [0.050s][trace][gc,region   ] G1HR ALLOC(OLD) [0x00000000fff00000, 0x00000000fff06278, 0x0000000100000000]
> [0.050s][trace][gc,region   ] G1HR INACTIVE(FREE) [0x00000000ffe00000, 0x00000000ffe00000, 0x00000000fff00000]
> [0.050s][trace][gc,region   ] G1HR INACTIVE(FREE) [0x00000000fff00000, 0x00000000fff00000, 0x0000000100000000]
> [0.050s][debug][gc,ergo,heap] Attempt heap shrinking (CDS archive regions). Total size: 2097152B
> [0.050s][trace][gc,region   ] G1HR UNCOMMIT(FREE) [0x00000000ffe00000, 0x00000000ffe00000, 0x00000000fff00000]
> [0.050s][trace][gc,region   ] G1HR UNCOMMIT(FREE) [0x00000000fff00000, 0x00000000fff00000, 0x0000000100000000]
> [0.057s][trace][gc,region   ] G1HR ALLOC(EDEN) [0x00000000ffd00000, 0x00000000ffd00000, 0x00000000ffe00000]
> [0.129s][trace][gc,region   ] G1HR ALLOC(EDEN) [0x00000000ffc00000, 0x00000000ffc00000, 0x00000000ffd00000]
> openjdk version "21-internal" 2023-09-19
> 
> 
> (The `GCCardSizeInBytes` option is there to decrease the minimum heap alignment to 512kb/1M so that setting `-Xms` to an odd value in a later test works)
> 
> I.e. the CDS regions are unconditionally uncommitted even through `-Xms == -Xmx`.
> 
> The next case just illustrates current (pre-existing) behavior with `-Xms != -Xmx`, showing that CDS regions are always committed, leading to higher than `-Xms` memory usage. I will file an enhancement here, as it is acceptable behavior (to me).
> 
> 
> $ java -XX:GCCardSizeInBytes=128 -Xmx128m -Xms126m -Xlog:gc+region=trace,gc+ergo+heap=debug -XX:+UseNewCode -version
> 
> [0.048s][trace][gc,region   ] G1HR COMMIT(FREE) [0x00000000fff00000, 0x00000000fff00000, 0x0000000100000000]
> [0.048s][trace][gc,region   ] G1HR ACTIVE(FREE) [0x00000000fff00000, 0x00000...

This pull request has been closed without being integrated.

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

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

From tschatzl at openjdk.org  Fri Jun  2 07:43:10 2023
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Fri, 2 Jun 2023 07:43:10 GMT
Subject: RFR: 8047998: Abort the vm if MaxNewSize is not the same as
 NewSize when MaxHeapSize is the same as InitialHeapSize [v2]
In-Reply-To: <OyY_PtBrYl63cgc1lVohoqRJ3tQy0sXZNubwCeb-mGY=.6ebb9afa-9812-4505-85ba-4dfcdfb9cf98@github.com>
References: <x0XiQ_v_hgW3zTJeni10F93buDr224ALn-oqzJeH0j8=.48b829a2-dd45-48d1-bbdd-3cfb3037ebea@github.com>
 <OyY_PtBrYl63cgc1lVohoqRJ3tQy0sXZNubwCeb-mGY=.6ebb9afa-9812-4505-85ba-4dfcdfb9cf98@github.com>
Message-ID: <CHDuKh9vMT5B7j08yLWLSSSTzCIAPbaFz24dSu1frV8=.c9a5cebd-f0bc-4c14-a54f-7fe645b3cfbd@github.com>

On Thu, 1 Jun 2023 09:33:10 GMT, Guoxiong Li <gli at openjdk.org> wrote:

>> Hi all,
>> 
>> When `MaxHeapSize` is equal to `InitialHeapSize` and `NewSize` is set in command line,
>> currently, the `max_young_size/MaxNewSize` will be set to the value of `NewSize`.
>> 
>> Considering the document of the `NewSize` (shown below), someone may set the `NewSize` 
>> to a very small value and expect the JVM to adjust the value dynamically.
>> Then when the `MaxHeapSize` is equal to `InitialHeapSize` (set by user or ergonomics),
>> the `MaxNewSize` is set to the value of `NewSize`, which is small unexpectedly.
>> 
>> 
>>   product(size_t, NewSize, ScaleForWordSize(1*M),                           \
>>           "Initial new generation size (in bytes)")                         \
>>           constraint(NewSizeConstraintFunc,AfterErgo)                       \
>> 
>> 
>> This patch fixes the issue by setting the `MaxNewSize` to `NewSize` only when the `NewSize` 
>> is larger than the original `max_young_size/MaxNewSize`.
>> 
>> The title of JDK-8047998 may need to adjusted.
>> 
>> Thanks for the review.
>> 
>> Best Regards,
>> -- Guoxiong
>
> Guoxiong Li 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:
> 
>  - Abort the vm instead of setting it implicitly.
>  - Merge branch 'master' into JDK-8047998
>  - JDK-8047998

Marked as reviewed by tschatzl (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/13876#pullrequestreview-1456821605

From iwalulya at openjdk.org  Fri Jun  2 08:37:35 2023
From: iwalulya at openjdk.org (Ivan Walulya)
Date: Fri, 2 Jun 2023 08:37:35 GMT
Subject: RFR: 8308507: G1: GClocker induced GCs can starve threads
 requiring memory leading to OOME [v5]
In-Reply-To: <OA_NUok57_CwYFRa6FjYHfQpxEIQrxO7tHQ-1VM3Cus=.1621f0a2-7766-41a0-a45b-94c2703ff4bf@github.com>
References: <OA_NUok57_CwYFRa6FjYHfQpxEIQrxO7tHQ-1VM3Cus=.1621f0a2-7766-41a0-a45b-94c2703ff4bf@github.com>
Message-ID: <l9EtH3rgOSNgsbSZi_LxK2KNzVpDkW60MHymlU_WDoM=.71c756a8-d621-46df-a2cd-543a568549a1@github.com>

> Please review this change which fixes the thread starvation problem during allocation for G1.
> 
> The starvation problem is not limited to GCLocker, however, currently, it manifests as an OOME only when GCLocker is active. In other cases, the starvation only affects the "starved" thread as it may loop indefinitely. 
> 
> Starvation with an active GCLocker happens as below:
> 
> 1. Thread A tries to allocate memory as normal, and tries to start a GC; the GCLocker is active and so the thread gets stalled waiting for the GC.
> 2. GCLocker induced GC executes and frees some memory.
> 3. Thread A does not get any of that memory, but other threads also waiting for memory.
> 4. Goto 1 until the gclocker retry count has been reached.
> 
> In this change, we take the general approach to solving starvation problems with announcement tables (request queues). On slow allocation, a thread that wishes to complete an Allocation GC and then attempt an allocation, announces its allocation request before proceeding to participate in a race to execute a GC safepoint. Whichever thread succeeds in executing the Allocation GC safepoint will be tasked with completing all allocation requests that were announced before the safepoint. This guarantees that all announced allocation requests are either satisfied during the safepoint, or failed in case there is not enough memory to complete all requests. This effectively deals with the starvation issue and reduces the number of allocation GCs triggered.
> 
> Note: The change also adopts ZList from ZGC and makes it available under utilities as DoublyLinkedList with slight modifications. 
> 
> Testing: Tier 1-7

Ivan Walulya has updated the pull request incrementally with two additional commits since the last revision:

 - Albert review: remove leftovers from previous implementation
 - merge_lists

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14077/files
  - new: https://git.openjdk.org/jdk/pull/14077/files/a544c066..f9fb408a

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

  Stats: 105 lines in 4 files changed: 10 ins; 63 del; 32 mod
  Patch: https://git.openjdk.org/jdk/pull/14077.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14077/head:pull/14077

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

From iwalulya at openjdk.org  Fri Jun  2 08:37:36 2023
From: iwalulya at openjdk.org (Ivan Walulya)
Date: Fri, 2 Jun 2023 08:37:36 GMT
Subject: RFR: 8308507: G1: GClocker induced GCs can starve threads
 requiring memory leading to OOME [v4]
In-Reply-To: <w3KQqCP-8CV42be4xNWwavlV7BYWhnz9EPN9TTg7SyI=.e2ba6e10-bbae-4121-bb5e-45c85597971c@github.com>
References: <OA_NUok57_CwYFRa6FjYHfQpxEIQrxO7tHQ-1VM3Cus=.1621f0a2-7766-41a0-a45b-94c2703ff4bf@github.com>
 <bOFF29fUhB222MjlbU-ib-PqYwpxNp1crY-FcqQStck=.19433b75-5ef0-4364-b79f-35136f450d2c@github.com>
 <aaqgAVbBdwg6QO1wEKg_fzuaCxSVDzZYvvhjghv_diE=.120d8991-be9d-4cf0-9f26-89d4026abe82@github.com>
 <FCF44hnq7vrgcbH2ajIZ23tBEeAmG1N8ZyXSKz4Nkag=.618003f5-d6c3-4285-9eeb-b1996167fd99@github.com>
 <w3KQqCP-8CV42be4xNWwavlV7BYWhnz9EPN9TTg7SyI=.e2ba6e10-bbae-4121-bb5e-45c85597971c@github.com>
Message-ID: <-hhaqdXy-_XcbPyFtkboexWjyJLmwDeanak8UfbSXyE=.2a9f37b4-6e80-4650-98df-1043b630a397@github.com>

On Thu, 1 Jun 2023 12:08:12 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> I thought it would be easier to follow with the two lists. I can merge them, If that is easier.
>
> I think it's the `state` that determines how element should be processed, regardless which list it lives on. If so, merging them sounds simpler. Could you try and see which approach is shorter/clearer/easier?

Done! could have more optimisations on early return from some of the list iterations. But pre-mature at this point.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14077#discussion_r1214086480

From iwalulya at openjdk.org  Fri Jun  2 08:42:43 2023
From: iwalulya at openjdk.org (Ivan Walulya)
Date: Fri, 2 Jun 2023 08:42:43 GMT
Subject: RFR: 8308507: G1: GClocker induced GCs can starve threads
 requiring memory leading to OOME [v6]
In-Reply-To: <OA_NUok57_CwYFRa6FjYHfQpxEIQrxO7tHQ-1VM3Cus=.1621f0a2-7766-41a0-a45b-94c2703ff4bf@github.com>
References: <OA_NUok57_CwYFRa6FjYHfQpxEIQrxO7tHQ-1VM3Cus=.1621f0a2-7766-41a0-a45b-94c2703ff4bf@github.com>
Message-ID: <6a-iJHxjX7wMzQB8VLkSkY4PjgpNFSrMmWodjZGWG4I=.815d0959-5646-49b8-8220-b5d68b9f4e90@github.com>

> Please review this change which fixes the thread starvation problem during allocation for G1.
> 
> The starvation problem is not limited to GCLocker, however, currently, it manifests as an OOME only when GCLocker is active. In other cases, the starvation only affects the "starved" thread as it may loop indefinitely. 
> 
> Starvation with an active GCLocker happens as below:
> 
> 1. Thread A tries to allocate memory as normal, and tries to start a GC; the GCLocker is active and so the thread gets stalled waiting for the GC.
> 2. GCLocker induced GC executes and frees some memory.
> 3. Thread A does not get any of that memory, but other threads also waiting for memory.
> 4. Goto 1 until the gclocker retry count has been reached.
> 
> In this change, we take the general approach to solving starvation problems with announcement tables (request queues). On slow allocation, a thread that wishes to complete an Allocation GC and then attempt an allocation, announces its allocation request before proceeding to participate in a race to execute a GC safepoint. Whichever thread succeeds in executing the Allocation GC safepoint will be tasked with completing all allocation requests that were announced before the safepoint. This guarantees that all announced allocation requests are either satisfied during the safepoint, or failed in case there is not enough memory to complete all requests. This effectively deals with the starvation issue and reduces the number of allocation GCs triggered.
> 
> Note: The change also adopts ZList from ZGC and makes it available under utilities as DoublyLinkedList with slight modifications. 
> 
> Testing: Tier 1-7

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

  remove newlines

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14077/files
  - new: https://git.openjdk.org/jdk/pull/14077/files/f9fb408a..c83f6e58

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

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

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

From ayang at openjdk.org  Fri Jun  2 12:52:11 2023
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Fri, 2 Jun 2023 12:52:11 GMT
Subject: RFR: 8309286: G1: Remove unused G1HeapRegionAttr::is_valid_gen
In-Reply-To: <Zvcf0ZHkxNpQ4SBxnYuyXC2CNQoY2_MY49Ru13JkNE4=.f31fe4f5-886e-41a4-a0b1-fcc3c9d11de9@github.com>
References: <Zvcf0ZHkxNpQ4SBxnYuyXC2CNQoY2_MY49Ru13JkNE4=.f31fe4f5-886e-41a4-a0b1-fcc3c9d11de9@github.com>
Message-ID: <tEhXJd0CF2ZjFzaZgYNmoOQwFkVypyrgei5vd9YNDHk=.452a39ef-5b5a-400b-91f4-de9895216867@github.com>

On Thu, 1 Jun 2023 11:47:14 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Trivial removing dead code.

Thanks for the review.

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

PR Comment: https://git.openjdk.org/jdk/pull/14260#issuecomment-1573679408

From ayang at openjdk.org  Fri Jun  2 12:52:12 2023
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Fri, 2 Jun 2023 12:52:12 GMT
Subject: Integrated: 8309286: G1: Remove unused G1HeapRegionAttr::is_valid_gen
In-Reply-To: <Zvcf0ZHkxNpQ4SBxnYuyXC2CNQoY2_MY49Ru13JkNE4=.f31fe4f5-886e-41a4-a0b1-fcc3c9d11de9@github.com>
References: <Zvcf0ZHkxNpQ4SBxnYuyXC2CNQoY2_MY49Ru13JkNE4=.f31fe4f5-886e-41a4-a0b1-fcc3c9d11de9@github.com>
Message-ID: <95fg3X10-5cK45qEW6zpiy0N4yacYGSRiojZtpHkvdw=.bb97d976-fdb2-41c5-ae98-7c908f78f8e9@github.com>

On Thu, 1 Jun 2023 11:47:14 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Trivial removing dead code.

This pull request has now been integrated.

Changeset: cb1e5e3f
Author:    Albert Mingkun Yang <ayang at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/cb1e5e3f0fb499ce3420a57a08fb9ec434809d13
Stats:     1 line in 1 file changed: 0 ins; 1 del; 0 mod

8309286: G1: Remove unused G1HeapRegionAttr::is_valid_gen

Reviewed-by: tschatzl

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

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

From kdnilsen at openjdk.org  Fri Jun  2 15:07:08 2023
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Fri, 2 Jun 2023 15:07:08 GMT
Subject: RFR: JDK-8309297: Adjust ShenandoahHeap print_heap_regions_on
In-Reply-To: <3EEbuWYZF264cbHXTzb825CwzVXY-5puhsWsZOS9ySM=.80200999-fc25-447f-9421-b5681e8cca02@github.com>
References: <3EEbuWYZF264cbHXTzb825CwzVXY-5puhsWsZOS9ySM=.80200999-fc25-447f-9421-b5681e8cca02@github.com>
Message-ID: <NJxo9G9aTbrkaC9eP_5T3gyNPn4ePzsgiXJKGA8X8z0=.f6e3a356-4ff3-4521-9d21-19f64a70fe50@github.com>

On Thu, 1 Jun 2023 14:45:16 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> The ShenandoahHeap print_heap_regions_on method prints some brief description of the columns of the heap table, however the description is unsorted and seems to be not fully up to date.
> 
> Another thought - is the critical pins column (CP=critical pins)  still needed or always 0  and obsolete now?

Looks good to me.  I believe we still need critical pins count.

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

PR Review: https://git.openjdk.org/jdk/pull/14264#pullrequestreview-1457738716

From duke at openjdk.org  Fri Jun  2 15:20:22 2023
From: duke at openjdk.org (Daohan Qu)
Date: Fri, 2 Jun 2023 15:20:22 GMT
Subject: RFR: 8309346: Extend hs_err logging for all VM operations deriving
 from VM_GC_Operation
Message-ID: <dC9MZQokYTzvraaYv40Ey67JeQrI-00f_trI7rhquzo=.b5df643c-3fc7-4f61-a593-0fd6cddbd948@github.com>

This patch implements `cause()` for `VM_GC_Operation` and its derived classes. It follows [JDK-8309210](https://bugs.openjdk.org/browse/JDK-8309210) to provide more detailed info for `VM_GC_Operation`s in hs_err log file.

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

Commit messages:
 - Implement cause() for VM_GC_Operation and classes derived from it

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

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

From mdoerr at openjdk.org  Fri Jun  2 15:24:07 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Fri, 2 Jun 2023 15:24:07 GMT
Subject: RFR: JDK-8309297: Adjust ShenandoahHeap print_heap_regions_on
In-Reply-To: <NJxo9G9aTbrkaC9eP_5T3gyNPn4ePzsgiXJKGA8X8z0=.f6e3a356-4ff3-4521-9d21-19f64a70fe50@github.com>
References: <3EEbuWYZF264cbHXTzb825CwzVXY-5puhsWsZOS9ySM=.80200999-fc25-447f-9421-b5681e8cca02@github.com>
 <NJxo9G9aTbrkaC9eP_5T3gyNPn4ePzsgiXJKGA8X8z0=.f6e3a356-4ff3-4521-9d21-19f64a70fe50@github.com>
Message-ID: <S1jNFG-cLrT54W-pCd8Nc7MFUbTw6TDG-8GggAJo2Tg=.b99a5574-c264-432a-aea4-064918a3d7e9@github.com>

On Fri, 2 Jun 2023 15:03:59 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

> Looks good to me. I believe we still need critical pins count.

Correct. I already checked that. See my comment above.

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

PR Comment: https://git.openjdk.org/jdk/pull/14264#issuecomment-1573911256

From ysr at openjdk.org  Fri Jun  2 16:57:07 2023
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Fri, 2 Jun 2023 16:57:07 GMT
Subject: RFR: JDK-8309297: Adjust ShenandoahHeap print_heap_regions_on
In-Reply-To: <3EEbuWYZF264cbHXTzb825CwzVXY-5puhsWsZOS9ySM=.80200999-fc25-447f-9421-b5681e8cca02@github.com>
References: <3EEbuWYZF264cbHXTzb825CwzVXY-5puhsWsZOS9ySM=.80200999-fc25-447f-9421-b5681e8cca02@github.com>
Message-ID: <AZ_prri5x_X-9-wFGWQqsOlUbWX9CErtelNwCPHIQHs=.71470cac-2c93-4cd8-9ddf-199e52d2ee28@github.com>

On Thu, 1 Jun 2023 14:45:16 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> The ShenandoahHeap print_heap_regions_on method prints some brief description of the columns of the heap table, however the description is unsorted and seems to be not fully up to date.
> 
> Another thought - is the critical pins column (CP=critical pins)  still needed or always 0  and obsolete now?

Marked as reviewed by ysr (Reviewer).

src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp line 1032:

> 1030:   st->print_cr("S=shared allocs, L=live data");
> 1031:   st->print_cr("CP=critical pins");
> 1032:   //st->print_cr("SN=alloc sequence number");

You can delete this line since what it used to print `_seqnum_last_alloc_mutator` appears to no longer be present in `ShenandoahHeapRegion`.

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

PR Review: https://git.openjdk.org/jdk/pull/14264#pullrequestreview-1458029253
PR Review Comment: https://git.openjdk.org/jdk/pull/14264#discussion_r1214606446

From gli at openjdk.org  Sat Jun  3 03:48:13 2023
From: gli at openjdk.org (Guoxiong Li)
Date: Sat, 3 Jun 2023 03:48:13 GMT
Subject: RFR: 8309265: Serial: Remove the code related to GC overheap limit
In-Reply-To: <CunRidxshw8CxM0WkiuTmGkLY7Maaib5fitKuhtzHfo=.a575a673-4d92-4233-bb60-9494abf6f481@github.com>
References: <DsF4t8TB4x-hC4LZ0cWJuiVcOV3pk3-jUOEpplZPd30=.66e8793f-ae2f-4237-8bfc-e581fc9fc9a8@github.com>
 <CunRidxshw8CxM0WkiuTmGkLY7Maaib5fitKuhtzHfo=.a575a673-4d92-4233-bb60-9494abf6f481@github.com>
Message-ID: <HC1RTm7UGJW7YbEQvs8DeSpGg5ssn2-TKji-ohQ1kys=.2728f00e-74a7-4413-95ea-b3587c795039@github.com>

On Thu, 1 Jun 2023 11:38:11 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Hi all,
>> 
>> This patch removes the unimplemented GC overhead limit related code in serial GC, mainly in `genCollectedHeap`.
>> It seems a leftover when removing the CMS.
>> 
>> Thanks for the review.
>> 
>> Best Regards,
>> -- Guoxiong
>
> Marked as reviewed by ayang (Reviewer).

@albertnetymk @tschatzl Thanks for your reviews. Integrating.

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

PR Comment: https://git.openjdk.org/jdk/pull/14258#issuecomment-1574618442

From gli at openjdk.org  Sat Jun  3 03:48:14 2023
From: gli at openjdk.org (Guoxiong Li)
Date: Sat, 3 Jun 2023 03:48:14 GMT
Subject: Integrated: 8309265: Serial: Remove the code related to GC overheap
 limit
In-Reply-To: <DsF4t8TB4x-hC4LZ0cWJuiVcOV3pk3-jUOEpplZPd30=.66e8793f-ae2f-4237-8bfc-e581fc9fc9a8@github.com>
References: <DsF4t8TB4x-hC4LZ0cWJuiVcOV3pk3-jUOEpplZPd30=.66e8793f-ae2f-4237-8bfc-e581fc9fc9a8@github.com>
Message-ID: <HVFvzGXcxDO3xcyTPEjkYp0icWyAPGfup0sgggtKhgA=.83e74002-32c7-4771-ac35-b64b94b9d6eb@github.com>

On Thu, 1 Jun 2023 11:15:17 GMT, Guoxiong Li <gli at openjdk.org> wrote:

> Hi all,
> 
> This patch removes the unimplemented GC overhead limit related code in serial GC, mainly in `genCollectedHeap`.
> It seems a leftover when removing the CMS.
> 
> Thanks for the review.
> 
> Best Regards,
> -- Guoxiong

This pull request has now been integrated.

Changeset: 6edd786b
Author:    Guoxiong Li <gli at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/6edd786bf6d8b1008a292b26fc0f901cbae1d03b
Stats:     30 lines in 2 files changed: 0 ins; 26 del; 4 mod

8309265: Serial: Remove the code related to GC overheap limit

Reviewed-by: ayang, tschatzl

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

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

From gli at openjdk.org  Sat Jun  3 07:34:07 2023
From: gli at openjdk.org (Guoxiong Li)
Date: Sat, 3 Jun 2023 07:34:07 GMT
Subject: RFR: 8309403: Serial: Remove the useless adaptive size policy in
 GenCollectedHeap
Message-ID: <AgndfVJuqHKLBUtf3Q8srBUH_BnNnXmxnvTz1rNXuRU=.36ab3363-d8b4-4fe3-b7e5-83f92af37d06@github.com>

Hi all,

This patch removes the useless code related to the `AdaptiveSizePolicy` in `GenCollectedHeap`.
As a result, the `SoftRefGenPolicy` is unnecessary too, use `SoftRefPolicy` instead.

Thanks for the review.

Best Regards,
-- Guoxiong

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

Commit messages:
 - JDK-8309403

Changes: https://git.openjdk.org/jdk/pull/14296/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14296&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8309403
  Stats: 114 lines in 5 files changed: 0 ins; 110 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/14296.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14296/head:pull/14296

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

From gli at openjdk.org  Sat Jun  3 10:04:34 2023
From: gli at openjdk.org (Guoxiong Li)
Date: Sat, 3 Jun 2023 10:04:34 GMT
Subject: RFR: 8309404: Parallel: Process class loader data graph in parallel in
 young gc
Message-ID: <VdC7jNuh7ZP2VFwKi3THctD2znSFVDQNGf6dUe4LCow=.2220db44-7d8f-4c04-a2dc-31f8885998c3@github.com>

Hi all,

This patch parallelizes the process of the class loader data graph in young gc.

The class `ClassLoaderData` has a field `_claim` to avoid applying oop closure more than once 
and the method `ClassLoaderData::oops_do` can check if the CLD had been claimed.
The parallel full gc has already used them in `MarkFromRootsTask::work` and `PSAdjustTask::work`.

But I don't have experience to test/verify the performance improvement of the GC.
If this patch needs such test data before integrating, please guide and help me here.

Thanks for the review and guidance.

Best Regards,
-- Guoxiong

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

Commit messages:
 - JDK-8309404

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

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

From tschatzl at openjdk.org  Mon Jun  5 10:06:42 2023
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Mon, 5 Jun 2023 10:06:42 GMT
Subject: RFR: 8140326: G1: Consider putting regions where evacuation failed
 into next collection set [v2]
In-Reply-To: <mmq6sEkAicO7Mc5FKkk5tcRVJDU6qtjYoyySho56F80=.aea5db50-0ec5-4e27-944e-2750af3d0bd7@github.com>
References: <mmq6sEkAicO7Mc5FKkk5tcRVJDU6qtjYoyySho56F80=.aea5db50-0ec5-4e27-944e-2750af3d0bd7@github.com>
Message-ID: <aq0h1SwvCubZvrTyFDvFJvP1M-_nNb-9pWhKWSsNX3c=.3a861802-e994-41a4-8eb5-6effb0060452@github.com>

> This change adds management of retained regions, i.e. trying to evacuate evacuation failed regions asap.
> 
> The advantage is that evacuation failed regions do not need to wait until the next marking to be cleaned out; as they are often very sparsely occupied (often being eden regions), this occupies a lot of space, potentially causing additional evacuation failures later on.
> Another use of this change will be region pinning, which are basically evacuation failed regions that can not be reclaimed as long as they are pinned - however as soon as they are unpinned, they should be reclaimed for the same reasons as well.
> 
> It consists of several behavioral changes:
> 
> During garbage collection:
> 
> ... in the Evacuation phase:
> * always collect dirty cards into evacuation failed regions proactively. In tests, the amount of cards/live objects per evacuation failed region is typically very small. Dirty cards are always put into the global refinement buffer immediately, assuming that we will keep most if not all evacuation failed regions.
> 
> ... during Post Evacuation 2/Free Collection Set phase:
> * determine whether the region will be retained (kept for "immediate" evacuation) or not. Highly occupied regions are assumed to stay (mostly) live at least until the next marking, so do not bother with them.
> 
> These "retained" regions are collected in a new "from retained" set in the collection set candidates and managed separately from "from marking" regions. Having the "from retained" and "from marking" sets separate in the collection set candidates is easier to manage than to use a single list and the picking stuff from it. Particularly wrt to making sure that mixed gcs preferentially pick from the "from marking" list first, then second from the "from retained" list.
> 
> ... determining the collection set during the pause:
>   * during gc, the collection set is preferentially (first) populated with regions from the "from marking" candidates (these are the important regions to get cleaned out), second from the "from retained" list.
>   * g1 reserves up to 20% of max gc pause time for retained regions as optional candidates (this is a random number) to make sure that these are cleared out asap to free memory. There is also a minimum number of regions to take from the retained regions list.
> 
> During marking
> 
> ... changes to marking proper
> * retained regions will not be marked through during concurrent mark, i.e. they are considered outside of the snapshot. So they are ...

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

  Doc additions

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14220/files
  - new: https://git.openjdk.org/jdk/pull/14220/files/24d7c499..a957eaac

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

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

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

From iwalulya at openjdk.org  Mon Jun  5 10:37:12 2023
From: iwalulya at openjdk.org (Ivan Walulya)
Date: Mon, 5 Jun 2023 10:37:12 GMT
Subject: RFR: 8140326: G1: Consider putting regions where evacuation failed
 into next collection set [v2]
In-Reply-To: <aq0h1SwvCubZvrTyFDvFJvP1M-_nNb-9pWhKWSsNX3c=.3a861802-e994-41a4-8eb5-6effb0060452@github.com>
References: <mmq6sEkAicO7Mc5FKkk5tcRVJDU6qtjYoyySho56F80=.aea5db50-0ec5-4e27-944e-2750af3d0bd7@github.com>
 <aq0h1SwvCubZvrTyFDvFJvP1M-_nNb-9pWhKWSsNX3c=.3a861802-e994-41a4-8eb5-6effb0060452@github.com>
Message-ID: <A8xEpzzHz8_L4AHI5H1ry93ANWL9H2OZQxrB43Wm70Y=.794f53d6-48c4-405c-a375-615e727b77e3@github.com>

On Mon, 5 Jun 2023 10:06:42 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> This change adds management of retained regions, i.e. trying to evacuate evacuation failed regions asap.
>> 
>> The advantage is that evacuation failed regions do not need to wait until the next marking to be cleaned out; as they are often very sparsely occupied (often being eden regions), this occupies a lot of space, potentially causing additional evacuation failures later on.
>> Another use of this change will be region pinning, which are basically evacuation failed regions that can not be reclaimed as long as they are pinned - however as soon as they are unpinned, they should be reclaimed for the same reasons as well.
>> 
>> It consists of several behavioral changes:
>> 
>> During garbage collection:
>> 
>> ... in the Evacuation phase:
>> * always collect dirty cards into evacuation failed regions proactively. In tests, the amount of cards/live objects per evacuation failed region is typically very small. Dirty cards are always put into the global refinement buffer immediately, assuming that we will keep most if not all evacuation failed regions.
>> 
>> ... during Post Evacuation 2/Free Collection Set phase:
>> * determine whether the region will be retained (kept for "immediate" evacuation) or not. Highly occupied regions are assumed to stay (mostly) live at least until the next marking, so do not bother with them.
>> 
>> These "retained" regions are collected in a new "from retained" set in the collection set candidates and managed separately from "from marking" regions. Having the "from retained" and "from marking" sets separate in the collection set candidates is easier to manage than to use a single list and the picking stuff from it. Particularly wrt to making sure that mixed gcs preferentially pick from the "from marking" list first, then second from the "from retained" list.
>> 
>> ... determining the collection set during the pause:
>>   * during gc, the collection set is preferentially (first) populated with regions from the "from marking" candidates (these are the important regions to get cleaned out), second from the "from retained" list.
>>   * g1 reserves up to 20% of max gc pause time for retained regions as optional candidates (this is a random number) to make sure that these are cleared out asap to free memory. There is also a minimum number of regions to take from the retained regions list.
>> 
>> During marking
>> 
>> ... changes to marking proper
>> * retained regions will not be marked through during concurrent mark, i.e. they are considered outside of ...
>
> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Doc additions

Changes requested by iwalulya (Reviewer).

src/hotspot/share/gc/g1/g1CollectionSetCandidates.cpp line 217:

> 215: 
> 216: void G1CollectionSetCandidates::remove(G1CollectionCandidateRegionList* other) {
> 217:   // During removal we exploit the fact that elements in the marking_regions,

Suggestion:

  // During removal, we exploit the fact that elements in the marking_regions,

src/hotspot/share/gc/g1/g1CollectionSetChooser.cpp line 35:

> 33: 
> 34: // Determine collection set candidates (from marking): For all regions determine
> 35: // whether they should be a collection set candidates, calculate their efficiency,

Suggestion:

// whether they should be collection set candidates, calculate their efficiency,

src/hotspot/share/gc/g1/g1CollectionSetChooser.cpp line 153:

> 151:       // alloc region (we should not consider those for collection
> 152:       // before we fill them up).
> 153:       if (should_add(r) && !G1CollectedHeap::heap()->is_old_gc_alloc_region(r)) {

Pre-existing: why not move the `!G1CollectedHeap::heap()->is_old_gc_alloc_region(r)` to `should_add` helper?

src/hotspot/share/gc/g1/g1CollectionSetChooser.cpp line 155:

> 153:       if (should_add(r) && !G1CollectedHeap::heap()->is_old_gc_alloc_region(r)) {
> 154:         add_region(r);
> 155:         assert(r->rem_set()->is_complete(), "must be %u", r->hrm_index());

Maybe the assert comes before the `add_region(r);`

src/hotspot/share/gc/g1/g1ParScanThreadState.hpp line 115:

> 113:   // the local DCQS. This is an approximation, as cards that would be added later
> 114:   // outside of evacuation failure will not be subtracted again.
> 115:   size_t _evac_failure_enqeued_cards;

Suggestion:

  size_t _evac_failure_enqueued_cards;

src/hotspot/share/gc/g1/g1Policy.cpp line 1534:

> 1532: void G1Policy::select_candidates_from_retained(G1CollectionCandidateList* retained_list,
> 1533:                                                double time_remaining_ms,
> 1534:                                                G1CollectionCandidateRegionList* initial_old_regions,

Might be called on empty `retained_list`, probably better to have an early return. Same should be added to `select_candidates_from_retained`

src/hotspot/share/gc/g1/g1Policy.cpp line 1544:

> 1542:   uint num_optional_regions_selected = 0;
> 1543:   uint num_expensive_regions_selected = 0;
> 1544:   uint num_unreclaimable_regions = 0;

how is `num_unreclaimable_regions` set?

test/hotspot/jtreg/gc/g1/TestVerifyGCType.java line 147:

> 145:         output.shouldHaveExitValue(0);
> 146: 
> 147: System.out.println(output.getStdout());

seems like leftover from debugging

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

PR Review: https://git.openjdk.org/jdk/pull/14220#pullrequestreview-1461900812
PR Review Comment: https://git.openjdk.org/jdk/pull/14220#discussion_r1217759095
PR Review Comment: https://git.openjdk.org/jdk/pull/14220#discussion_r1217831930
PR Review Comment: https://git.openjdk.org/jdk/pull/14220#discussion_r1217847077
PR Review Comment: https://git.openjdk.org/jdk/pull/14220#discussion_r1217835890
PR Review Comment: https://git.openjdk.org/jdk/pull/14220#discussion_r1217851534
PR Review Comment: https://git.openjdk.org/jdk/pull/14220#discussion_r1217658060
PR Review Comment: https://git.openjdk.org/jdk/pull/14220#discussion_r1217696095
PR Review Comment: https://git.openjdk.org/jdk/pull/14220#discussion_r1217873522

From ayang at openjdk.org  Mon Jun  5 11:10:06 2023
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Mon, 5 Jun 2023 11:10:06 GMT
Subject: RFR: 8309403: Serial: Remove the useless adaptive size policy in
 GenCollectedHeap
In-Reply-To: <AgndfVJuqHKLBUtf3Q8srBUH_BnNnXmxnvTz1rNXuRU=.36ab3363-d8b4-4fe3-b7e5-83f92af37d06@github.com>
References: <AgndfVJuqHKLBUtf3Q8srBUH_BnNnXmxnvTz1rNXuRU=.36ab3363-d8b4-4fe3-b7e5-83f92af37d06@github.com>
Message-ID: <th101U_7ZJ0PzJyxkX3r63Fz6ENOjPJXxysCYV7CBWE=.6a2e1dc4-69c7-4575-be92-5f24c7fb0e56@github.com>

On Sat, 3 Jun 2023 07:27:52 GMT, Guoxiong Li <gli at openjdk.org> wrote:

> Hi all,
> 
> This patch removes the useless code related to the `AdaptiveSizePolicy` in `GenCollectedHeap`.
> As a result, the `SoftRefGenPolicy` is unnecessary too, use `SoftRefPolicy` instead.
> 
> Thanks for the review.
> 
> Best Regards,
> -- Guoxiong

src/hotspot/share/gc/shared/softRefGenPolicy.cpp line 36:

> 34:   AdaptiveSizePolicy* size_policy = GenCollectedHeap::heap()->size_policy();
> 35:   if (size_policy != nullptr) {
> 36:     set_should_clear_all_soft_refs(size_policy->gc_overhead_limit_near());

Why is this call removed? I'd expect `set_should_clear_all_soft_refs(false);` here.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14296#discussion_r1217911071

From ayang at openjdk.org  Mon Jun  5 11:23:15 2023
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Mon, 5 Jun 2023 11:23:15 GMT
Subject: RFR: 8308507: G1: GClocker induced GCs can starve threads
 requiring memory leading to OOME [v6]
In-Reply-To: <6a-iJHxjX7wMzQB8VLkSkY4PjgpNFSrMmWodjZGWG4I=.815d0959-5646-49b8-8220-b5d68b9f4e90@github.com>
References: <OA_NUok57_CwYFRa6FjYHfQpxEIQrxO7tHQ-1VM3Cus=.1621f0a2-7766-41a0-a45b-94c2703ff4bf@github.com>
 <6a-iJHxjX7wMzQB8VLkSkY4PjgpNFSrMmWodjZGWG4I=.815d0959-5646-49b8-8220-b5d68b9f4e90@github.com>
Message-ID: <rTphVQdePKZ-y7ay2FQTUSYO5zpg0K76smpZeOO4jSQ=.d44724f8-bf4f-40bb-bc9d-47c68d81912c@github.com>

On Fri, 2 Jun 2023 08:42:43 GMT, Ivan Walulya <iwalulya at openjdk.org> wrote:

>> Please review this change which fixes the thread starvation problem during allocation for G1.
>> 
>> The starvation problem is not limited to GCLocker, however, currently, it manifests as an OOME only when GCLocker is active. In other cases, the starvation only affects the "starved" thread as it may loop indefinitely. 
>> 
>> Starvation with an active GCLocker happens as below:
>> 
>> 1. Thread A tries to allocate memory as normal, and tries to start a GC; the GCLocker is active and so the thread gets stalled waiting for the GC.
>> 2. GCLocker induced GC executes and frees some memory.
>> 3. Thread A does not get any of that memory, but other threads also waiting for memory.
>> 4. Goto 1 until the gclocker retry count has been reached.
>> 
>> In this change, we take the general approach to solving starvation problems with announcement tables (request queues). On slow allocation, a thread that wishes to complete an Allocation GC and then attempt an allocation, announces its allocation request before proceeding to participate in a race to execute a GC safepoint. Whichever thread succeeds in executing the Allocation GC safepoint will be tasked with completing all allocation requests that were announced before the safepoint. This guarantees that all announced allocation requests are either satisfied during the safepoint, or failed in case there is not enough memory to complete all requests. This effectively deals with the starvation issue and reduces the number of allocation GCs triggered.
>> 
>> Note: The change also adopts ZList from ZGC and makes it available under utilities as DoublyLinkedList with slight modifications. 
>> 
>> Testing: Tier 1-7
>
> Ivan Walulya has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove newlines

src/hotspot/share/gc/g1/g1CollectedHeap.cpp line 1015:

> 1013: }
> 1014: 
> 1015: bool G1CollectedHeap::handle_allocation_requests(bool expect_null_mutator_alloc_region) {

The arg seems unused.

src/hotspot/share/gc/g1/g1CollectedHeap.hpp line 190:

> 188:       Success,
> 189:       Failed,
> 190:       Pending,

Could you put `Pending` at the top? It's more symmetric to its lifecycle.

src/hotspot/share/gc/g1/g1VMOperations.cpp line 138:

> 136:   bool has_allocation_requests = !g1h->_stalled_allocations.is_empty();
> 137:   if (has_allocation_requests) {
> 138:     bool alloc_succeeded = g1h->handle_allocation_requests(false /* expect_null_mutator_alloc_region*/);

This eventually calls `expand`. On master, I believe `expand` is called always after a gc-cycle, based on the implicit assumption that running a gc-cycle is more desirable than expanding the heap.

src/hotspot/share/gc/g1/g1VMOperations.cpp line 149:

> 147: 
> 148:   GCCauseSetter x(g1h, _gc_cause);
> 149:   bool gc_succeeded = false;

Seems unused.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14077#discussion_r1214355270
PR Review Comment: https://git.openjdk.org/jdk/pull/14077#discussion_r1214403517
PR Review Comment: https://git.openjdk.org/jdk/pull/14077#discussion_r1214968545
PR Review Comment: https://git.openjdk.org/jdk/pull/14077#discussion_r1214354622

From tschatzl at openjdk.org  Mon Jun  5 11:37:06 2023
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Mon, 5 Jun 2023 11:37:06 GMT
Subject: RFR: 8140326: G1: Consider putting regions where evacuation failed
 into next collection set [v2]
In-Reply-To: <A8xEpzzHz8_L4AHI5H1ry93ANWL9H2OZQxrB43Wm70Y=.794f53d6-48c4-405c-a375-615e727b77e3@github.com>
References: <mmq6sEkAicO7Mc5FKkk5tcRVJDU6qtjYoyySho56F80=.aea5db50-0ec5-4e27-944e-2750af3d0bd7@github.com>
 <aq0h1SwvCubZvrTyFDvFJvP1M-_nNb-9pWhKWSsNX3c=.3a861802-e994-41a4-8eb5-6effb0060452@github.com>
 <A8xEpzzHz8_L4AHI5H1ry93ANWL9H2OZQxrB43Wm70Y=.794f53d6-48c4-405c-a375-615e727b77e3@github.com>
Message-ID: <3NPTPjYGEaVtKf8RwA3SDNUVFQqmypbThBd0euQdr2w=.53c0492d-7b06-41ca-b250-15789139b623@github.com>

On Mon, 5 Jun 2023 08:14:07 GMT, Ivan Walulya <iwalulya at openjdk.org> wrote:

>> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Doc additions
>
> src/hotspot/share/gc/g1/g1Policy.cpp line 1544:
> 
>> 1542:   uint num_optional_regions_selected = 0;
>> 1543:   uint num_expensive_regions_selected = 0;
>> 1544:   uint num_unreclaimable_regions = 0;
> 
> how is `num_unreclaimable_regions` set?

Leftover from the next PR where pinned regions are deemed "unreclaimable". I managed to remove it from the marking region selection code...

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14220#discussion_r1217941488

From tschatzl at openjdk.org  Mon Jun  5 11:40:08 2023
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Mon, 5 Jun 2023 11:40:08 GMT
Subject: RFR: 8140326: G1: Consider putting regions where evacuation failed
 into next collection set [v2]
In-Reply-To: <A8xEpzzHz8_L4AHI5H1ry93ANWL9H2OZQxrB43Wm70Y=.794f53d6-48c4-405c-a375-615e727b77e3@github.com>
References: <mmq6sEkAicO7Mc5FKkk5tcRVJDU6qtjYoyySho56F80=.aea5db50-0ec5-4e27-944e-2750af3d0bd7@github.com>
 <aq0h1SwvCubZvrTyFDvFJvP1M-_nNb-9pWhKWSsNX3c=.3a861802-e994-41a4-8eb5-6effb0060452@github.com>
 <A8xEpzzHz8_L4AHI5H1ry93ANWL9H2OZQxrB43Wm70Y=.794f53d6-48c4-405c-a375-615e727b77e3@github.com>
Message-ID: <mOMV7BkSvbXP7exOurRL1FFegAISyipeW4QQDb8yfMk=.fb395e46-8673-49b8-abb9-873022c0b36a@github.com>

On Mon, 5 Jun 2023 10:10:36 GMT, Ivan Walulya <iwalulya at openjdk.org> wrote:

>> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Doc additions
>
> src/hotspot/share/gc/g1/g1CollectionSetChooser.cpp line 153:
> 
>> 151:       // alloc region (we should not consider those for collection
>> 152:       // before we fill them up).
>> 153:       if (should_add(r) && !G1CollectedHeap::heap()->is_old_gc_alloc_region(r)) {
> 
> Pre-existing: why not move the `!G1CollectedHeap::heap()->is_old_gc_alloc_region(r)` to `should_add` helper?

I already discussed this with @albertnetymk with the result of moving this to a separate commit.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14220#discussion_r1217944998

From lkorinth at openjdk.org  Mon Jun  5 12:21:07 2023
From: lkorinth at openjdk.org (Leo Korinth)
Date: Mon, 5 Jun 2023 12:21:07 GMT
Subject: RFR: 8309346: Extend hs_err logging for all VM operations deriving
 from VM_GC_Operation
In-Reply-To: <dC9MZQokYTzvraaYv40Ey67JeQrI-00f_trI7rhquzo=.b5df643c-3fc7-4f61-a593-0fd6cddbd948@github.com>
References: <dC9MZQokYTzvraaYv40Ey67JeQrI-00f_trI7rhquzo=.b5df643c-3fc7-4f61-a593-0fd6cddbd948@github.com>
Message-ID: <XBlNs89FJ1dxe-fsKTtBWMgRLSYgxtWomH9HVei6Nks=.10869453-c7ed-475d-9c20-c11a5fd611b4@github.com>

On Fri, 2 Jun 2023 15:13:33 GMT, Daohan Qu <duke at openjdk.org> wrote:

> This patch implements `cause()` for `VM_GC_Operation` and its derived classes. It follows [JDK-8309210](https://bugs.openjdk.org/browse/JDK-8309210) to provide more detailed info for `VM_GC_Operation`s in hs_err log file.

(this is not a review) How about using `override` instead of `virtual`? I think it better shows how the method is used, and also create compile time errors if we miss to rename the method during refactoring.

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

PR Comment: https://git.openjdk.org/jdk/pull/14287#issuecomment-1576681827

From tschatzl at openjdk.org  Mon Jun  5 12:24:25 2023
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Mon, 5 Jun 2023 12:24:25 GMT
Subject: RFR: 8140326: G1: Consider putting regions where evacuation failed
 into next collection set [v3]
In-Reply-To: <mmq6sEkAicO7Mc5FKkk5tcRVJDU6qtjYoyySho56F80=.aea5db50-0ec5-4e27-944e-2750af3d0bd7@github.com>
References: <mmq6sEkAicO7Mc5FKkk5tcRVJDU6qtjYoyySho56F80=.aea5db50-0ec5-4e27-944e-2750af3d0bd7@github.com>
Message-ID: <wBC_hhvUTiU1gYr0J85hPbwomjeSvR8zKkFavnp6lTw=.9996615f-3544-4dd2-9857-c8113cbb73fd@github.com>

> This change adds management of retained regions, i.e. trying to evacuate evacuation failed regions asap.
> 
> The advantage is that evacuation failed regions do not need to wait until the next marking to be cleaned out; as they are often very sparsely occupied (often being eden regions), this occupies a lot of space, potentially causing additional evacuation failures later on.
> Another use of this change will be region pinning, which are basically evacuation failed regions that can not be reclaimed as long as they are pinned - however as soon as they are unpinned, they should be reclaimed for the same reasons as well.
> 
> It consists of several behavioral changes:
> 
> During garbage collection:
> 
> ... in the Evacuation phase:
> * always collect dirty cards into evacuation failed regions proactively. In tests, the amount of cards/live objects per evacuation failed region is typically very small. Dirty cards are always put into the global refinement buffer immediately, assuming that we will keep most if not all evacuation failed regions.
> 
> ... during Post Evacuation 2/Free Collection Set phase:
> * determine whether the region will be retained (kept for "immediate" evacuation) or not. Highly occupied regions are assumed to stay (mostly) live at least until the next marking, so do not bother with them.
> 
> These "retained" regions are collected in a new "from retained" set in the collection set candidates and managed separately from "from marking" regions. Having the "from retained" and "from marking" sets separate in the collection set candidates is easier to manage than to use a single list and the picking stuff from it. Particularly wrt to making sure that mixed gcs preferentially pick from the "from marking" list first, then second from the "from retained" list.
> 
> ... determining the collection set during the pause:
>   * during gc, the collection set is preferentially (first) populated with regions from the "from marking" candidates (these are the important regions to get cleaned out), second from the "from retained" list.
>   * g1 reserves up to 20% of max gc pause time for retained regions as optional candidates (this is a random number) to make sure that these are cleared out asap to free memory. There is also a minimum number of regions to take from the retained regions list.
> 
> During marking
> 
> ... changes to marking proper
> * retained regions will not be marked through during concurrent mark, i.e. they are considered outside of the snapshot. So they are ...

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

  iwalulya review #1

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14220/files
  - new: https://git.openjdk.org/jdk/pull/14220/files/a957eaac..364fa823

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

  Stats: 14 lines in 7 files changed: 1 ins; 4 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/14220.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14220/head:pull/14220

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

From tschatzl at openjdk.org  Mon Jun  5 13:22:07 2023
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Mon, 5 Jun 2023 13:22:07 GMT
Subject: RFR: 8140326: G1: Consider putting regions where evacuation failed
 into next collection set [v3]
In-Reply-To: <A8xEpzzHz8_L4AHI5H1ry93ANWL9H2OZQxrB43Wm70Y=.794f53d6-48c4-405c-a375-615e727b77e3@github.com>
References: <mmq6sEkAicO7Mc5FKkk5tcRVJDU6qtjYoyySho56F80=.aea5db50-0ec5-4e27-944e-2750af3d0bd7@github.com>
 <aq0h1SwvCubZvrTyFDvFJvP1M-_nNb-9pWhKWSsNX3c=.3a861802-e994-41a4-8eb5-6effb0060452@github.com>
 <A8xEpzzHz8_L4AHI5H1ry93ANWL9H2OZQxrB43Wm70Y=.794f53d6-48c4-405c-a375-615e727b77e3@github.com>
Message-ID: <xP_IOky_4zu7OMNxB78N6ZpRQifkm0h4Vor-4ruU-uw=.4ffa4494-8398-4e9e-9136-530af91efdd5@github.com>

On Mon, 5 Jun 2023 07:42:09 GMT, Ivan Walulya <iwalulya at openjdk.org> wrote:

>> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   iwalulya review #1
>
> src/hotspot/share/gc/g1/g1Policy.cpp line 1534:
> 
>> 1532: void G1Policy::select_candidates_from_retained(G1CollectionCandidateList* retained_list,
>> 1533:                                                double time_remaining_ms,
>> 1534:                                                G1CollectionCandidateRegionList* initial_old_regions,
> 
> Might be called on empty `retained_list`, probably better to have an early return. Same should be added to `select_candidates_from_retained`

I would prefer to keep things as is. The overhead isn't big: after some initialization, the main loop will not be entered anyway, but we'd need to duplicate the log messages (or add a special one) in both cases.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14220#discussion_r1218064787

From duke at openjdk.org  Mon Jun  5 13:35:30 2023
From: duke at openjdk.org (Daohan Qu)
Date: Mon, 5 Jun 2023 13:35:30 GMT
Subject: RFR: 8309346: Extend hs_err logging for all VM operations deriving
 from VM_GC_Operation [v2]
In-Reply-To: <dC9MZQokYTzvraaYv40Ey67JeQrI-00f_trI7rhquzo=.b5df643c-3fc7-4f61-a593-0fd6cddbd948@github.com>
References: <dC9MZQokYTzvraaYv40Ey67JeQrI-00f_trI7rhquzo=.b5df643c-3fc7-4f61-a593-0fd6cddbd948@github.com>
Message-ID: <syaePfZU-6hWG8Bl3j7aJUsjDiYp6vqSt78xrc0VDP0=.29bc535e-c344-4d6f-aee2-c87a0856441e@github.com>

> This patch implements `cause()` for `VM_GC_Operation` and its derived classes. It follows [JDK-8309210](https://bugs.openjdk.org/browse/JDK-8309210) to provide more detailed info for `VM_GC_Operation`s in hs_err log file.

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

  Use override instead of virtual

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14287/files
  - new: https://git.openjdk.org/jdk/pull/14287/files/6424880e..63d5edf4

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

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

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

From duke at openjdk.org  Mon Jun  5 13:35:32 2023
From: duke at openjdk.org (Daohan Qu)
Date: Mon, 5 Jun 2023 13:35:32 GMT
Subject: RFR: 8309346: Extend hs_err logging for all VM operations deriving
 from VM_GC_Operation
In-Reply-To: <XBlNs89FJ1dxe-fsKTtBWMgRLSYgxtWomH9HVei6Nks=.10869453-c7ed-475d-9c20-c11a5fd611b4@github.com>
References: <dC9MZQokYTzvraaYv40Ey67JeQrI-00f_trI7rhquzo=.b5df643c-3fc7-4f61-a593-0fd6cddbd948@github.com>
 <XBlNs89FJ1dxe-fsKTtBWMgRLSYgxtWomH9HVei6Nks=.10869453-c7ed-475d-9c20-c11a5fd611b4@github.com>
Message-ID: <CNnUHQiYyUEnIQOydOCtX1YYFOhlytoOanqftW-yFrc=.437d062a-f33c-4dc8-9e22-85d304183278@github.com>

On Mon, 5 Jun 2023 12:18:46 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> (this is not a review) How about using `override` instead of `virtual`? I think it better shows how the method is used, and also create compile time errors if we miss to rename the method during refactoring.

Good advice, thanks @lkorinth !

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

PR Comment: https://git.openjdk.org/jdk/pull/14287#issuecomment-1576811952

From iwalulya at openjdk.org  Mon Jun  5 14:24:08 2023
From: iwalulya at openjdk.org (Ivan Walulya)
Date: Mon, 5 Jun 2023 14:24:08 GMT
Subject: RFR: 8140326: G1: Consider putting regions where evacuation failed
 into next collection set [v3]
In-Reply-To: <xP_IOky_4zu7OMNxB78N6ZpRQifkm0h4Vor-4ruU-uw=.4ffa4494-8398-4e9e-9136-530af91efdd5@github.com>
References: <mmq6sEkAicO7Mc5FKkk5tcRVJDU6qtjYoyySho56F80=.aea5db50-0ec5-4e27-944e-2750af3d0bd7@github.com>
 <aq0h1SwvCubZvrTyFDvFJvP1M-_nNb-9pWhKWSsNX3c=.3a861802-e994-41a4-8eb5-6effb0060452@github.com>
 <A8xEpzzHz8_L4AHI5H1ry93ANWL9H2OZQxrB43Wm70Y=.794f53d6-48c4-405c-a375-615e727b77e3@github.com>
 <xP_IOky_4zu7OMNxB78N6ZpRQifkm0h4Vor-4ruU-uw=.4ffa4494-8398-4e9e-9136-530af91efdd5@github.com>
Message-ID: <xuxR0F08SDB3CkZxYs3kkReiWnww1bnPrKiXtzA_oog=.fbfc6d02-46b6-4dac-9ca2-f22dae347dae@github.com>

On Mon, 5 Jun 2023 13:19:48 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> src/hotspot/share/gc/g1/g1Policy.cpp line 1534:
>> 
>>> 1532: void G1Policy::select_candidates_from_retained(G1CollectionCandidateList* retained_list,
>>> 1533:                                                double time_remaining_ms,
>>> 1534:                                                G1CollectionCandidateRegionList* initial_old_regions,
>> 
>> Might be called on empty `retained_list`, probably better to have an early return. Same should be added to `select_candidates_from_retained`
>
> I would prefer to keep things as is. The overhead isn't big: after some initialization, the main loop will not be entered anyway, but we'd need to duplicate the log messages (or add a special one) in both cases.

Noted!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14220#discussion_r1218147077

From duke at openjdk.org  Mon Jun  5 14:50:42 2023
From: duke at openjdk.org (Daohan Qu)
Date: Mon, 5 Jun 2023 14:50:42 GMT
Subject: RFR: 8309346: Extend hs_err logging for all VM operations deriving
 from VM_GC_Operation [v3]
In-Reply-To: <dC9MZQokYTzvraaYv40Ey67JeQrI-00f_trI7rhquzo=.b5df643c-3fc7-4f61-a593-0fd6cddbd948@github.com>
References: <dC9MZQokYTzvraaYv40Ey67JeQrI-00f_trI7rhquzo=.b5df643c-3fc7-4f61-a593-0fd6cddbd948@github.com>
Message-ID: <L-8VWepxDbmHiCmqC_HdTCHsYtmhqTgXUceNMKIwK5E=.9702c2d9-b0e8-4805-9e19-c90d85776c87@github.com>

> This patch implements `cause()` for `VM_GC_Operation` and its derived classes. It follows [JDK-8309210](https://bugs.openjdk.org/browse/JDK-8309210) to provide more detailed info for `VM_GC_Operation`s in hs_err log file.

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

  Revert the change and leave it for further cleaning up

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14287/files
  - new: https://git.openjdk.org/jdk/pull/14287/files/63d5edf4..62c1da2c

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

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

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

From tschatzl at openjdk.org  Mon Jun  5 14:57:05 2023
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Mon, 5 Jun 2023 14:57:05 GMT
Subject: RFR: 8309346: Extend hs_err logging for all VM operations deriving
 from VM_GC_Operation [v3]
In-Reply-To: <L-8VWepxDbmHiCmqC_HdTCHsYtmhqTgXUceNMKIwK5E=.9702c2d9-b0e8-4805-9e19-c90d85776c87@github.com>
References: <dC9MZQokYTzvraaYv40Ey67JeQrI-00f_trI7rhquzo=.b5df643c-3fc7-4f61-a593-0fd6cddbd948@github.com>
 <L-8VWepxDbmHiCmqC_HdTCHsYtmhqTgXUceNMKIwK5E=.9702c2d9-b0e8-4805-9e19-c90d85776c87@github.com>
Message-ID: <mkxVgy7Oej4JSIPjUC8mv8NLqrwIfqF3wxdVBOcGViM=.f492471e-185c-4840-a675-68319d1f502c@github.com>

On Mon, 5 Jun 2023 14:50:42 GMT, Daohan Qu <duke at openjdk.org> wrote:

>> This patch implements `cause()` for `VM_GC_Operation` and its derived classes. It follows [JDK-8309210](https://bugs.openjdk.org/browse/JDK-8309210) to provide more detailed info for `VM_GC_Operation`s in hs_err log file.
>
> Daohan Qu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert the change and leave it for further cleaning up

Lgtm.

Would it be possible to also add some description string for `VM_Verify` and `VM_PopulateDynamicDumpSharedSpace` (separately)? I'll file an RFE which you could pick up if you want.

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

Marked as reviewed by tschatzl (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14287#pullrequestreview-1462745064

From duke at openjdk.org  Mon Jun  5 15:20:07 2023
From: duke at openjdk.org (Daohan Qu)
Date: Mon, 5 Jun 2023 15:20:07 GMT
Subject: RFR: 8309346: Extend hs_err logging for all VM operations deriving
 from VM_GC_Operation [v3]
In-Reply-To: <mkxVgy7Oej4JSIPjUC8mv8NLqrwIfqF3wxdVBOcGViM=.f492471e-185c-4840-a675-68319d1f502c@github.com>
References: <dC9MZQokYTzvraaYv40Ey67JeQrI-00f_trI7rhquzo=.b5df643c-3fc7-4f61-a593-0fd6cddbd948@github.com>
 <L-8VWepxDbmHiCmqC_HdTCHsYtmhqTgXUceNMKIwK5E=.9702c2d9-b0e8-4805-9e19-c90d85776c87@github.com>
 <mkxVgy7Oej4JSIPjUC8mv8NLqrwIfqF3wxdVBOcGViM=.f492471e-185c-4840-a675-68319d1f502c@github.com>
Message-ID: <-NrxGT0Chp1CxHQupT64JIj2DdKnTmsjDtldTS73tLE=.7b9daf5b-335e-4ceb-9e26-89b808ee02f4@github.com>

On Mon, 5 Jun 2023 14:54:48 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Would it be possible to also add some description string for `VM_Verify` and `VM_PopulateDynamicDumpSharedSpace` (separately)? I'll file an RFE which you could pick up if you want.
> 
> Edit: filed https://bugs.openjdk.org/browse/JDK-8309482

Thanks for your review @tschatzl ! I'll take it.

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

PR Comment: https://git.openjdk.org/jdk/pull/14287#issuecomment-1577001390

From iwalulya at openjdk.org  Mon Jun  5 15:59:44 2023
From: iwalulya at openjdk.org (Ivan Walulya)
Date: Mon, 5 Jun 2023 15:59:44 GMT
Subject: RFR: 8308507: G1: GClocker induced GCs can starve threads
 requiring memory leading to OOME [v7]
In-Reply-To: <OA_NUok57_CwYFRa6FjYHfQpxEIQrxO7tHQ-1VM3Cus=.1621f0a2-7766-41a0-a45b-94c2703ff4bf@github.com>
References: <OA_NUok57_CwYFRa6FjYHfQpxEIQrxO7tHQ-1VM3Cus=.1621f0a2-7766-41a0-a45b-94c2703ff4bf@github.com>
Message-ID: <isFkAGDYVetvjxYWgCRuJVVrW624DJCUCjbfI2wwSEE=.f007866e-f3ce-486b-8953-f6003600957f@github.com>

> Please review this change which fixes the thread starvation problem during allocation for G1.
> 
> The starvation problem is not limited to GCLocker, however, currently, it manifests as an OOME only when GCLocker is active. In other cases, the starvation only affects the "starved" thread as it may loop indefinitely. 
> 
> Starvation with an active GCLocker happens as below:
> 
> 1. Thread A tries to allocate memory as normal, and tries to start a GC; the GCLocker is active and so the thread gets stalled waiting for the GC.
> 2. GCLocker induced GC executes and frees some memory.
> 3. Thread A does not get any of that memory, but other threads also waiting for memory.
> 4. Goto 1 until the gclocker retry count has been reached.
> 
> In this change, we take the general approach to solving starvation problems with announcement tables (request queues). On slow allocation, a thread that wishes to complete an Allocation GC and then attempt an allocation, announces its allocation request before proceeding to participate in a race to execute a GC safepoint. Whichever thread succeeds in executing the Allocation GC safepoint will be tasked with completing all allocation requests that were announced before the safepoint. This guarantees that all announced allocation requests are either satisfied during the safepoint, or failed in case there is not enough memory to complete all requests. This effectively deals with the starvation issue and reduces the number of allocation GCs triggered.
> 
> Note: The change also adopts ZList from ZGC and makes it available under utilities as DoublyLinkedList with slight modifications. 
> 
> Testing: Tier 1-7

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

  prefer gc pause over heap expansion

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14077/files
  - new: https://git.openjdk.org/jdk/pull/14077/files/c83f6e58..06687557

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

  Stats: 20 lines in 3 files changed: 5 ins; 3 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/14077.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14077/head:pull/14077

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

From iwalulya at openjdk.org  Mon Jun  5 15:59:45 2023
From: iwalulya at openjdk.org (Ivan Walulya)
Date: Mon, 5 Jun 2023 15:59:45 GMT
Subject: RFR: 8308507: G1: GClocker induced GCs can starve threads
 requiring memory leading to OOME [v6]
In-Reply-To: <rTphVQdePKZ-y7ay2FQTUSYO5zpg0K76smpZeOO4jSQ=.d44724f8-bf4f-40bb-bc9d-47c68d81912c@github.com>
References: <OA_NUok57_CwYFRa6FjYHfQpxEIQrxO7tHQ-1VM3Cus=.1621f0a2-7766-41a0-a45b-94c2703ff4bf@github.com>
 <6a-iJHxjX7wMzQB8VLkSkY4PjgpNFSrMmWodjZGWG4I=.815d0959-5646-49b8-8220-b5d68b9f4e90@github.com>
 <rTphVQdePKZ-y7ay2FQTUSYO5zpg0K76smpZeOO4jSQ=.d44724f8-bf4f-40bb-bc9d-47c68d81912c@github.com>
Message-ID: <OglQ_jqA4cp7T2sYai595cjXmSukQDM0-xufKZ-3x4s=.a5283bc9-4f74-4392-b9f7-375962f90405@github.com>

On Fri, 2 Jun 2023 23:45:48 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Ivan Walulya has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   remove newlines
>
> src/hotspot/share/gc/g1/g1VMOperations.cpp line 138:
> 
>> 136:   bool has_allocation_requests = !g1h->_stalled_allocations.is_empty();
>> 137:   if (has_allocation_requests) {
>> 138:     bool alloc_succeeded = g1h->handle_allocation_requests(false /* expect_null_mutator_alloc_region*/);
> 
> This eventually calls `expand`. On master, I believe `expand` is called always after a gc-cycle, based on the implicit assumption that running a gc-cycle is more desirable than expanding the heap.

Reset to preferring the gc pause over heap expansion.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14077#discussion_r1218276770

From ayang at openjdk.org  Mon Jun  5 16:19:09 2023
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Mon, 5 Jun 2023 16:19:09 GMT
Subject: RFR: 8272147: Consolidate preserved marks handling with other STW
 collectors
In-Reply-To: <jXZiOVJDgymUKJne7d-LXCpIx7xcPoFPGATHIGSw_HE=.cb5e5aa0-001c-4842-9c16-7cb70e41b8a2@github.com>
References: <jXZiOVJDgymUKJne7d-LXCpIx7xcPoFPGATHIGSw_HE=.cb5e5aa0-001c-4842-9c16-7cb70e41b8a2@github.com>
Message-ID: <QShvVPwXfVTRPqtV31xcc32SpiPcU1E6CN8AWftCpL0=.9da386fe-b4cb-45fa-ac98-7bb4f7633bf1@github.com>

On Thu, 1 Jun 2023 22:32:52 GMT, Guoxiong Li <gli at openjdk.org> wrote:

> Hi all,
> 
> This patch removes the class `markSweep.hpp::PreservedMark` and uses the shared `PreservedMarksSet` instead.
> 
> In order to keep the meaning of the field `_preserved_marks` in `markSweep`,
> I need to use `OopAndMarkWord` explicitly. So I move `OopAndMarkWord` out of `PreservedMarks`.
> 
> Tests:
> `hotspot:tier1` passed locally (x86 & linux).
> 
> Thanks for the review.
> 
> Best Regards,
> -- Guoxiong

src/hotspot/share/gc/shared/preservedMarks.hpp line 60:

> 58: 
> 59: public:
> 60:   OopAndMarkWordStack& get_stack() { return _stack; }

Could you explain why this new API is required for Serial but not other collectors, e.g. G1? (IOW, can Serial do sth similar as G1 so that no new API is introduced?)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14274#discussion_r1218301433

From stefank at openjdk.org  Mon Jun  5 16:42:10 2023
From: stefank at openjdk.org (Stefan Karlsson)
Date: Mon, 5 Jun 2023 16:42:10 GMT
Subject: RFR: 8309346: Extend hs_err logging for all VM operations deriving
 from VM_GC_Operation [v3]
In-Reply-To: <L-8VWepxDbmHiCmqC_HdTCHsYtmhqTgXUceNMKIwK5E=.9702c2d9-b0e8-4805-9e19-c90d85776c87@github.com>
References: <dC9MZQokYTzvraaYv40Ey67JeQrI-00f_trI7rhquzo=.b5df643c-3fc7-4f61-a593-0fd6cddbd948@github.com>
 <L-8VWepxDbmHiCmqC_HdTCHsYtmhqTgXUceNMKIwK5E=.9702c2d9-b0e8-4805-9e19-c90d85776c87@github.com>
Message-ID: <ePawYOKV1odE91MK4TC5dn34q5EEQnSHfY_-1SZ5INM=.8621399c-ab44-4e87-88a7-5d328b0268cd@github.com>

On Mon, 5 Jun 2023 14:50:42 GMT, Daohan Qu <duke at openjdk.org> wrote:

>> This patch implements `cause()` for `VM_GC_Operation` and its derived classes. It follows [JDK-8309210](https://bugs.openjdk.org/browse/JDK-8309210) to provide more detailed info for `VM_GC_Operation`s in hs_err log file.
>
> Daohan Qu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert the change and leave it for further cleaning up

Could you move the implementation over to the .cpp file? We should strive to not add non-trivial implementation in .hpp files.

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

Changes requested by stefank (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14287#pullrequestreview-1462957960

From duke at openjdk.org  Mon Jun  5 16:59:44 2023
From: duke at openjdk.org (Daohan Qu)
Date: Mon, 5 Jun 2023 16:59:44 GMT
Subject: RFR: 8309346: Extend hs_err logging for all VM operations deriving
 from VM_GC_Operation [v3]
In-Reply-To: <ePawYOKV1odE91MK4TC5dn34q5EEQnSHfY_-1SZ5INM=.8621399c-ab44-4e87-88a7-5d328b0268cd@github.com>
References: <dC9MZQokYTzvraaYv40Ey67JeQrI-00f_trI7rhquzo=.b5df643c-3fc7-4f61-a593-0fd6cddbd948@github.com>
 <L-8VWepxDbmHiCmqC_HdTCHsYtmhqTgXUceNMKIwK5E=.9702c2d9-b0e8-4805-9e19-c90d85776c87@github.com>
 <ePawYOKV1odE91MK4TC5dn34q5EEQnSHfY_-1SZ5INM=.8621399c-ab44-4e87-88a7-5d328b0268cd@github.com>
Message-ID: <D_RQ5qCzd52AKwX_njUcAr7u8zIzvWNZx2Il3yF71pQ=.eded7910-1704-41b6-8a84-b6b38ba19369@github.com>

On Mon, 5 Jun 2023 16:39:03 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> Could you move the implementation over to the .cpp file? We should strive to not add non-trivial implementation in .hpp files.

Make sense, thanks for your review @stefank !

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

PR Comment: https://git.openjdk.org/jdk/pull/14287#issuecomment-1577141867

From duke at openjdk.org  Mon Jun  5 16:59:44 2023
From: duke at openjdk.org (Daohan Qu)
Date: Mon, 5 Jun 2023 16:59:44 GMT
Subject: RFR: 8309346: Extend hs_err logging for all VM operations deriving
 from VM_GC_Operation [v4]
In-Reply-To: <dC9MZQokYTzvraaYv40Ey67JeQrI-00f_trI7rhquzo=.b5df643c-3fc7-4f61-a593-0fd6cddbd948@github.com>
References: <dC9MZQokYTzvraaYv40Ey67JeQrI-00f_trI7rhquzo=.b5df643c-3fc7-4f61-a593-0fd6cddbd948@github.com>
Message-ID: <K9ZCKCHxQONWkdHiffIoEx_QwN-sWwEA0BYBvs0ZZzc=.c69af061-423b-4e82-bc10-1c0c2f6885ca@github.com>

> This patch implements `cause()` for `VM_GC_Operation` and its derived classes. It follows [JDK-8309210](https://bugs.openjdk.org/browse/JDK-8309210) to provide more detailed info for `VM_GC_Operation`s in hs_err log file.

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

  Move impl to .cpp file

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14287/files
  - new: https://git.openjdk.org/jdk/pull/14287/files/62c1da2c..8d4d729f

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

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

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

From gli at openjdk.org  Mon Jun  5 17:03:06 2023
From: gli at openjdk.org (Guoxiong Li)
Date: Mon, 5 Jun 2023 17:03:06 GMT
Subject: RFR: 8272147: Consolidate preserved marks handling with other STW
 collectors
In-Reply-To: <QShvVPwXfVTRPqtV31xcc32SpiPcU1E6CN8AWftCpL0=.9da386fe-b4cb-45fa-ac98-7bb4f7633bf1@github.com>
References: <jXZiOVJDgymUKJne7d-LXCpIx7xcPoFPGATHIGSw_HE=.cb5e5aa0-001c-4842-9c16-7cb70e41b8a2@github.com>
 <QShvVPwXfVTRPqtV31xcc32SpiPcU1E6CN8AWftCpL0=.9da386fe-b4cb-45fa-ac98-7bb4f7633bf1@github.com>
Message-ID: <ZMaKdK8M28yJ0hJkX2lEZ_3rqiLr7-RegW3NZBxphvM=.1fac828a-2436-4c02-a1ea-4ca1046ca34e@github.com>

On Mon, 5 Jun 2023 16:16:32 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Hi all,
>> 
>> This patch removes the class `markSweep.hpp::PreservedMark` and uses the shared `PreservedMarksSet` instead.
>> 
>> In order to keep the meaning of the field `_preserved_marks` in `markSweep`,
>> I need to use `OopAndMarkWord` explicitly. So I move `OopAndMarkWord` out of `PreservedMarks`.
>> 
>> Tests:
>> `hotspot:tier1` passed locally (x86 & linux).
>> 
>> Thanks for the review.
>> 
>> Best Regards,
>> -- Guoxiong
>
> src/hotspot/share/gc/shared/preservedMarks.hpp line 60:
> 
>> 58: 
>> 59: public:
>> 60:   OopAndMarkWordStack& get_stack() { return _stack; }
> 
> Could you explain why this new API is required for Serial but not other collectors, e.g. G1? (IOW, can Serial do sth similar as G1 so that no new API is introduced?)

The methods `MarkSweep::adjust_pointer` and `PreservedMarks::adjust_during_full_gc` have different implementations. The method `MarkSweep::adjust_pointer` seems doing more thing. So in `MarkSweep::adjust_marks`, I use `get_stack` to get the stack and invoke `MarkSweep::adjust_pointer` explicitly. If you can confirm `PreservedMarks::adjust_during_full_gc` is good to replace `MarkSweep::adjust_pointer`, I will remove `get_stack` and use `PreservedMarks::adjust_during_full_gc` instead of `MarkSweep::adjust_pointer`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14274#discussion_r1218348409

From stefank at openjdk.org  Mon Jun  5 19:17:45 2023
From: stefank at openjdk.org (Stefan Karlsson)
Date: Mon, 5 Jun 2023 19:17:45 GMT
Subject: RFR: 8309346: Extend hs_err logging for all VM operations deriving
 from VM_GC_Operation [v4]
In-Reply-To: <K9ZCKCHxQONWkdHiffIoEx_QwN-sWwEA0BYBvs0ZZzc=.c69af061-423b-4e82-bc10-1c0c2f6885ca@github.com>
References: <dC9MZQokYTzvraaYv40Ey67JeQrI-00f_trI7rhquzo=.b5df643c-3fc7-4f61-a593-0fd6cddbd948@github.com>
 <K9ZCKCHxQONWkdHiffIoEx_QwN-sWwEA0BYBvs0ZZzc=.c69af061-423b-4e82-bc10-1c0c2f6885ca@github.com>
Message-ID: <K8Qp2RPRQaOUkuEydBQwq_V5JA6IoobVBXCn2Pl-wKY=.50e578ad-8dbf-4914-8d16-3e735d9a0a11@github.com>

On Mon, 5 Jun 2023 16:59:44 GMT, Daohan Qu <duke at openjdk.org> wrote:

>> This patch implements `cause()` for `VM_GC_Operation` and its derived classes. It follows [JDK-8309210](https://bugs.openjdk.org/browse/JDK-8309210) to provide more detailed info for `VM_GC_Operation`s in hs_err log file.
>
> Daohan Qu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move impl to .cpp file

Looks good.

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

Marked as reviewed by stefank (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14287#pullrequestreview-1463224760

From gli at openjdk.org  Mon Jun  5 21:05:00 2023
From: gli at openjdk.org (Guoxiong Li)
Date: Mon, 5 Jun 2023 21:05:00 GMT
Subject: RFR: 8309403: Serial: Remove the useless adaptive size policy in
 GenCollectedHeap
In-Reply-To: <th101U_7ZJ0PzJyxkX3r63Fz6ENOjPJXxysCYV7CBWE=.6a2e1dc4-69c7-4575-be92-5f24c7fb0e56@github.com>
References: <AgndfVJuqHKLBUtf3Q8srBUH_BnNnXmxnvTz1rNXuRU=.36ab3363-d8b4-4fe3-b7e5-83f92af37d06@github.com>
 <th101U_7ZJ0PzJyxkX3r63Fz6ENOjPJXxysCYV7CBWE=.6a2e1dc4-69c7-4575-be92-5f24c7fb0e56@github.com>
Message-ID: <Ti2vvexSpP3ykFTJLmjxLo_vKSCkP4dTcjlnz-BSW98=.b4ed2aee-66bf-486d-af6b-2312a1f11426@github.com>

On Mon, 5 Jun 2023 11:07:11 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Hi all,
>> 
>> This patch removes the useless code related to the `AdaptiveSizePolicy` in `GenCollectedHeap`.
>> As a result, the `SoftRefGenPolicy` is unnecessary too, use `SoftRefPolicy` instead.
>> 
>> Thanks for the review.
>> 
>> Best Regards,
>> -- Guoxiong
>
> src/hotspot/share/gc/shared/softRefGenPolicy.cpp line 36:
> 
>> 34:   AdaptiveSizePolicy* size_policy = GenCollectedHeap::heap()->size_policy();
>> 35:   if (size_policy != nullptr) {
>> 36:     set_should_clear_all_soft_refs(size_policy->gc_overhead_limit_near());
> 
> Why is this call removed? I'd expect `set_should_clear_all_soft_refs(false);` here.

The default value of `_should_clear_all_soft_refs` is `false` and I don't see other places to set it to `true` in Serial GC. And from the comment, I think it is a leftover of CMS.

>  // If near gc overhear limit, continue to clear SoftRefs.  SoftRefs may
>  // have been cleared in the last collection but if the gc overhear
>  // limit continues to be near, SoftRefs should still be cleared.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14296#discussion_r1218590519

From duke at openjdk.org  Tue Jun  6 07:33:06 2023
From: duke at openjdk.org (Daohan Qu)
Date: Tue, 6 Jun 2023 07:33:06 GMT
Subject: Integrated: 8309346: Extend hs_err logging for all VM operations
 deriving from VM_GC_Operation
In-Reply-To: <dC9MZQokYTzvraaYv40Ey67JeQrI-00f_trI7rhquzo=.b5df643c-3fc7-4f61-a593-0fd6cddbd948@github.com>
References: <dC9MZQokYTzvraaYv40Ey67JeQrI-00f_trI7rhquzo=.b5df643c-3fc7-4f61-a593-0fd6cddbd948@github.com>
Message-ID: <WiGKP6-v7DoHyRIr5hUtzCZ4DPt2IrV_CVeeGWw8E0w=.f8084cdb-4d54-4bdc-9fad-f9a9c5dd7574@github.com>

On Fri, 2 Jun 2023 15:13:33 GMT, Daohan Qu <duke at openjdk.org> wrote:

> This patch implements `cause()` for `VM_GC_Operation` and its derived classes. It follows [JDK-8309210](https://bugs.openjdk.org/browse/JDK-8309210) to provide more detailed info for `VM_GC_Operation`s in hs_err log file.

This pull request has now been integrated.

Changeset: a7a09130
Author:    quadhier <quadhier at 163.com>
Committer: Thomas Schatzl <tschatzl at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a7a0913005f9ac3c64546e194ea14176daadac5d
Stats:     6 lines in 2 files changed: 6 ins; 0 del; 0 mod

8309346: Extend hs_err logging for all VM operations deriving from VM_GC_Operation

Reviewed-by: tschatzl, stefank

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

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

From tschatzl at openjdk.org  Tue Jun  6 07:33:05 2023
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Tue, 6 Jun 2023 07:33:05 GMT
Subject: RFR: 8309346: Extend hs_err logging for all VM operations deriving
 from VM_GC_Operation [v4]
In-Reply-To: <K9ZCKCHxQONWkdHiffIoEx_QwN-sWwEA0BYBvs0ZZzc=.c69af061-423b-4e82-bc10-1c0c2f6885ca@github.com>
References: <dC9MZQokYTzvraaYv40Ey67JeQrI-00f_trI7rhquzo=.b5df643c-3fc7-4f61-a593-0fd6cddbd948@github.com>
 <K9ZCKCHxQONWkdHiffIoEx_QwN-sWwEA0BYBvs0ZZzc=.c69af061-423b-4e82-bc10-1c0c2f6885ca@github.com>
Message-ID: <2knOYcubo3zdkT6S7NCjDPKAgWnZAkoM4fA9DqL6qQw=.df58b215-66f4-4685-8af9-97a9bfad1fda@github.com>

On Mon, 5 Jun 2023 16:59:44 GMT, Daohan Qu <duke at openjdk.org> wrote:

>> This patch implements `cause()` for `VM_GC_Operation` and its derived classes. It follows [JDK-8309210](https://bugs.openjdk.org/browse/JDK-8309210) to provide more detailed info for `VM_GC_Operation`s in hs_err log file.
>
> Daohan Qu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move impl to .cpp file

Still good.

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

Marked as reviewed by tschatzl (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14287#pullrequestreview-1464465272

From duke at openjdk.org  Tue Jun  6 07:35:58 2023
From: duke at openjdk.org (Daohan Qu)
Date: Tue, 6 Jun 2023 07:35:58 GMT
Subject: RFR: 8309346: Extend hs_err logging for all VM operations deriving
 from VM_GC_Operation
In-Reply-To: <XBlNs89FJ1dxe-fsKTtBWMgRLSYgxtWomH9HVei6Nks=.10869453-c7ed-475d-9c20-c11a5fd611b4@github.com>
References: <dC9MZQokYTzvraaYv40Ey67JeQrI-00f_trI7rhquzo=.b5df643c-3fc7-4f61-a593-0fd6cddbd948@github.com>
 <XBlNs89FJ1dxe-fsKTtBWMgRLSYgxtWomH9HVei6Nks=.10869453-c7ed-475d-9c20-c11a5fd611b4@github.com>
Message-ID: <it1jLkEIgHoKvksU1IcU-Vt4lcy3zzFmsZyY18Whq24=.e1dfcc11-b6cd-4ea5-a808-b21988d0b422@github.com>

On Mon, 5 Jun 2023 12:18:46 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

>> This patch implements `cause()` for `VM_GC_Operation` and its derived classes. It follows [JDK-8309210](https://bugs.openjdk.org/browse/JDK-8309210) to provide more detailed info for `VM_GC_Operation`s in hs_err log file.
>
> (this is not a review) How about using `override` instead of `virtual`? I think it better shows how the method is used, and also create compile time errors if we miss to rename the method during refactoring.

Thanks again for your comments and reviews @lkorinth @tschatzl @stefank !

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

PR Comment: https://git.openjdk.org/jdk/pull/14287#issuecomment-1578083152

From iwalulya at openjdk.org  Tue Jun  6 07:48:52 2023
From: iwalulya at openjdk.org (Ivan Walulya)
Date: Tue, 6 Jun 2023 07:48:52 GMT
Subject: RFR: 8140326: G1: Consider putting regions where evacuation failed
 into next collection set [v3]
In-Reply-To: <wBC_hhvUTiU1gYr0J85hPbwomjeSvR8zKkFavnp6lTw=.9996615f-3544-4dd2-9857-c8113cbb73fd@github.com>
References: <mmq6sEkAicO7Mc5FKkk5tcRVJDU6qtjYoyySho56F80=.aea5db50-0ec5-4e27-944e-2750af3d0bd7@github.com>
 <wBC_hhvUTiU1gYr0J85hPbwomjeSvR8zKkFavnp6lTw=.9996615f-3544-4dd2-9857-c8113cbb73fd@github.com>
Message-ID: <lDLXhbw3zZ1_7-DuyYrOAlmWe0LaojPnCdOg_lgeOhc=.d1d6a874-7d4a-4229-8cda-06491f47ced3@github.com>

On Mon, 5 Jun 2023 12:24:25 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> This change adds management of retained regions, i.e. trying to evacuate evacuation failed regions asap.
>> 
>> The advantage is that evacuation failed regions do not need to wait until the next marking to be cleaned out; as they are often very sparsely occupied (often being eden regions), this occupies a lot of space, potentially causing additional evacuation failures later on.
>> Another use of this change will be region pinning, which are basically evacuation failed regions that can not be reclaimed as long as they are pinned - however as soon as they are unpinned, they should be reclaimed for the same reasons as well.
>> 
>> It consists of several behavioral changes:
>> 
>> During garbage collection:
>> 
>> ... in the Evacuation phase:
>> * always collect dirty cards into evacuation failed regions proactively. In tests, the amount of cards/live objects per evacuation failed region is typically very small. Dirty cards are always put into the global refinement buffer immediately, assuming that we will keep most if not all evacuation failed regions.
>> 
>> ... during Post Evacuation 2/Free Collection Set phase:
>> * determine whether the region will be retained (kept for "immediate" evacuation) or not. Highly occupied regions are assumed to stay (mostly) live at least until the next marking, so do not bother with them.
>> 
>> These "retained" regions are collected in a new "from retained" set in the collection set candidates and managed separately from "from marking" regions. Having the "from retained" and "from marking" sets separate in the collection set candidates is easier to manage than to use a single list and the picking stuff from it. Particularly wrt to making sure that mixed gcs preferentially pick from the "from marking" list first, then second from the "from retained" list.
>> 
>> ... determining the collection set during the pause:
>>   * during gc, the collection set is preferentially (first) populated with regions from the "from marking" candidates (these are the important regions to get cleaned out), second from the "from retained" list.
>>   * g1 reserves up to 20% of max gc pause time for retained regions as optional candidates (this is a random number) to make sure that these are cleared out asap to free memory. There is also a minimum number of regions to take from the retained regions list.
>> 
>> During marking
>> 
>> ... changes to marking proper
>> * retained regions will not be marked through during concurrent mark, i.e. they are considered outside of ...
>
> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:
> 
>   iwalulya review #1

Lgtm!

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

Marked as reviewed by iwalulya (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14220#pullrequestreview-1464499812

From tschatzl at openjdk.org  Tue Jun  6 08:03:53 2023
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Tue, 6 Jun 2023 08:03:53 GMT
Subject: RFR: 8272147: Consolidate preserved marks handling with other STW
 collectors
In-Reply-To: <jXZiOVJDgymUKJne7d-LXCpIx7xcPoFPGATHIGSw_HE=.cb5e5aa0-001c-4842-9c16-7cb70e41b8a2@github.com>
References: <jXZiOVJDgymUKJne7d-LXCpIx7xcPoFPGATHIGSw_HE=.cb5e5aa0-001c-4842-9c16-7cb70e41b8a2@github.com>
Message-ID: <2pzMX3PFWEAw66zFvRqoHT7IU4dBK3a45rBsAtol1vs=.cc5fb7ed-fabe-460b-a4d0-7ec09a0c0a8e@github.com>

On Thu, 1 Jun 2023 22:32:52 GMT, Guoxiong Li <gli at openjdk.org> wrote:

> Hi all,
> 
> This patch removes the class `markSweep.hpp::PreservedMark` and uses the shared `PreservedMarksSet` instead.
> 
> In order to keep the meaning of the field `_preserved_marks` in `markSweep`,
> I need to use `OopAndMarkWord` explicitly. So I move `OopAndMarkWord` out of `PreservedMarks`.
> 
> Tests:
> `hotspot:tier1` passed locally (x86 & linux).
> 
> Thanks for the review.
> 
> Best Regards,
> -- Guoxiong

Changes requested by tschatzl (Reviewer).

src/hotspot/share/gc/serial/genMarkSweep.cpp line 51:

> 49: #include "gc/shared/strongRootsScope.hpp"
> 50: #include "gc/shared/weakProcessor.hpp"
> 51: #include "gc/shared/preservedMarks.inline.hpp"

Includes should be ordered alphabetically.

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

PR Review: https://git.openjdk.org/jdk/pull/14274#pullrequestreview-1462762622
PR Review Comment: https://git.openjdk.org/jdk/pull/14274#discussion_r1218206815

From tschatzl at openjdk.org  Tue Jun  6 08:03:55 2023
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Tue, 6 Jun 2023 08:03:55 GMT
Subject: RFR: 8272147: Consolidate preserved marks handling with other STW
 collectors
In-Reply-To: <ZMaKdK8M28yJ0hJkX2lEZ_3rqiLr7-RegW3NZBxphvM=.1fac828a-2436-4c02-a1ea-4ca1046ca34e@github.com>
References: <jXZiOVJDgymUKJne7d-LXCpIx7xcPoFPGATHIGSw_HE=.cb5e5aa0-001c-4842-9c16-7cb70e41b8a2@github.com>
 <QShvVPwXfVTRPqtV31xcc32SpiPcU1E6CN8AWftCpL0=.9da386fe-b4cb-45fa-ac98-7bb4f7633bf1@github.com>
 <ZMaKdK8M28yJ0hJkX2lEZ_3rqiLr7-RegW3NZBxphvM=.1fac828a-2436-4c02-a1ea-4ca1046ca34e@github.com>
Message-ID: <vCkqVwip-nyVeXCX18Yx-j04uJQuS1PGol1K7DIMXwk=.df999bd6-21ba-4fbf-9654-359fb523faf1@github.com>

On Mon, 5 Jun 2023 17:00:14 GMT, Guoxiong Li <gli at openjdk.org> wrote:

>> src/hotspot/share/gc/shared/preservedMarks.hpp line 60:
>> 
>>> 58: 
>>> 59: public:
>>> 60:   OopAndMarkWordStack& get_stack() { return _stack; }
>> 
>> Could you explain why this new API is required for Serial but not other collectors, e.g. G1? (IOW, can Serial do sth similar as G1 so that no new API is introduced?)
>
> The methods `MarkSweep::adjust_pointer` and `PreservedMarks::adjust_during_full_gc` have different implementations. The method `MarkSweep::adjust_pointer` seems doing more thing. So in `MarkSweep::adjust_marks`, I use `get_stack` to get the stack and invoke `MarkSweep::adjust_pointer` explicitly. If you can confirm `PreservedMarks::adjust_during_full_gc` is good to replace `MarkSweep::adjust_pointer`, I will remove `get_stack` and use `PreservedMarks::adjust_during_full_gc` instead of `MarkSweep::adjust_pointer`.

You can replace that code with `PreservedMarks::adjust_during_full_gc` from what I can see; the additional code in `MarkSweep::adjust_pointer` only deals with the generic case if the passed `oop` is null, which can't be the case for oops in the preserved marks set.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14274#discussion_r1219129319

From tschatzl at openjdk.org  Tue Jun  6 08:13:42 2023
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Tue, 6 Jun 2023 08:13:42 GMT
Subject: RFR: 8140326: G1: Consider putting regions where evacuation failed
 into next collection set [v4]
In-Reply-To: <mmq6sEkAicO7Mc5FKkk5tcRVJDU6qtjYoyySho56F80=.aea5db50-0ec5-4e27-944e-2750af3d0bd7@github.com>
References: <mmq6sEkAicO7Mc5FKkk5tcRVJDU6qtjYoyySho56F80=.aea5db50-0ec5-4e27-944e-2750af3d0bd7@github.com>
Message-ID: <siD6FS-fypLat5u9YQDYdzP6z2-8PiCzsn2xqMRXJc4=.55fa90c6-72c3-4442-a228-fef52bab717c@github.com>

> This change adds management of retained regions, i.e. trying to evacuate evacuation failed regions asap.
> 
> The advantage is that evacuation failed regions do not need to wait until the next marking to be cleaned out; as they are often very sparsely occupied (often being eden regions), this occupies a lot of space, potentially causing additional evacuation failures later on.
> Another use of this change will be region pinning, which are basically evacuation failed regions that can not be reclaimed as long as they are pinned - however as soon as they are unpinned, they should be reclaimed for the same reasons as well.
> 
> It consists of several behavioral changes:
> 
> During garbage collection:
> 
> ... in the Evacuation phase:
> * always collect dirty cards into evacuation failed regions proactively. In tests, the amount of cards/live objects per evacuation failed region is typically very small. Dirty cards are always put into the global refinement buffer immediately, assuming that we will keep most if not all evacuation failed regions.
> 
> ... during Post Evacuation 2/Free Collection Set phase:
> * determine whether the region will be retained (kept for "immediate" evacuation) or not. Highly occupied regions are assumed to stay (mostly) live at least until the next marking, so do not bother with them.
> 
> These "retained" regions are collected in a new "from retained" set in the collection set candidates and managed separately from "from marking" regions. Having the "from retained" and "from marking" sets separate in the collection set candidates is easier to manage than to use a single list and the picking stuff from it. Particularly wrt to making sure that mixed gcs preferentially pick from the "from marking" list first, then second from the "from retained" list.
> 
> ... determining the collection set during the pause:
>   * during gc, the collection set is preferentially (first) populated with regions from the "from marking" candidates (these are the important regions to get cleaned out), second from the "from retained" list.
>   * g1 reserves up to 20% of max gc pause time for retained regions as optional candidates (this is a random number) to make sure that these are cleared out asap to free memory. There is also a minimum number of regions to take from the retained regions list.
> 
> During marking
> 
> ... changes to marking proper
> * retained regions will not be marked through during concurrent mark, i.e. they are considered outside of the snapshot. So they are ...

Thomas Schatzl has updated the pull request incrementally with two additional commits since the last revision:

 - More debug option removal
 - Remove debug options for tests

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14220/files
  - new: https://git.openjdk.org/jdk/pull/14220/files/364fa823..a304afed

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

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

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

From mbaesken at openjdk.org  Tue Jun  6 08:30:09 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 6 Jun 2023 08:30:09 GMT
Subject: RFR: JDK-8309297: Adjust ShenandoahHeap print_heap_regions_on [v2]
In-Reply-To: <3EEbuWYZF264cbHXTzb825CwzVXY-5puhsWsZOS9ySM=.80200999-fc25-447f-9421-b5681e8cca02@github.com>
References: <3EEbuWYZF264cbHXTzb825CwzVXY-5puhsWsZOS9ySM=.80200999-fc25-447f-9421-b5681e8cca02@github.com>
Message-ID: <6Sd_Wq_SP5TkAmMgCeuFe8-6nP7A7dZVO1h0_nmZUEo=.a7f588e9-c3bf-4e5d-b0ff-f1c7051fa71f@github.com>

> The ShenandoahHeap print_heap_regions_on method prints some brief description of the columns of the heap table, however the description is unsorted and seems to be not fully up to date.
> 
> Another thought - is the critical pins column (CP=critical pins)  still needed or always 0  and obsolete now?

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

  remove comment line

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14264/files
  - new: https://git.openjdk.org/jdk/pull/14264/files/463e1e02..4e96461f

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

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

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

From mbaesken at openjdk.org  Tue Jun  6 08:30:10 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 6 Jun 2023 08:30:10 GMT
Subject: RFR: JDK-8309297: Adjust ShenandoahHeap print_heap_regions_on [v2]
In-Reply-To: <AZ_prri5x_X-9-wFGWQqsOlUbWX9CErtelNwCPHIQHs=.71470cac-2c93-4cd8-9ddf-199e52d2ee28@github.com>
References: <3EEbuWYZF264cbHXTzb825CwzVXY-5puhsWsZOS9ySM=.80200999-fc25-447f-9421-b5681e8cca02@github.com>
 <AZ_prri5x_X-9-wFGWQqsOlUbWX9CErtelNwCPHIQHs=.71470cac-2c93-4cd8-9ddf-199e52d2ee28@github.com>
Message-ID: <USyLnoHDE3yTJmkNLznktm22U0iI_DbLUMAuBs18-0Q=.67b314b6-71d7-41aa-b03a-a395fa9c8ab9@github.com>

On Fri, 2 Jun 2023 16:54:43 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

>> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   remove comment line
>
> src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp line 1032:
> 
>> 1030:   st->print_cr("S=shared allocs, L=live data");
>> 1031:   st->print_cr("CP=critical pins");
>> 1032:   //st->print_cr("SN=alloc sequence number");
> 
> You can delete this line since what it used to print `_seqnum_last_alloc_mutator` appears to no longer be present in `ShenandoahHeapRegion`.

I removed the comment line.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14264#discussion_r1219165028

From tschatzl at openjdk.org  Tue Jun  6 09:06:53 2023
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Tue, 6 Jun 2023 09:06:53 GMT
Subject: RFR: 8309404: Parallel: Process class loader data graph in
 parallel in young gc
In-Reply-To: <VdC7jNuh7ZP2VFwKi3THctD2znSFVDQNGf6dUe4LCow=.2220db44-7d8f-4c04-a2dc-31f8885998c3@github.com>
References: <VdC7jNuh7ZP2VFwKi3THctD2znSFVDQNGf6dUe4LCow=.2220db44-7d8f-4c04-a2dc-31f8885998c3@github.com>
Message-ID: <0H9H0i9CJh1aMs971hNUBJVxSjpYrkozgO3b_W2iG6o=.af658eb7-bc82-4bbe-a35c-5a0b9535321f@github.com>

On Sat, 3 Jun 2023 09:57:43 GMT, Guoxiong Li <gli at openjdk.org> wrote:

> Hi all,
> 
> This patch parallelizes the process of the class loader data graph in young gc.
> 
> The class `ClassLoaderData` has a field `_claim` to avoid applying oop closure more than once 
> and the method `ClassLoaderData::oops_do` can check if the CLD had been claimed.
> The parallel full gc has already used them in `MarkFromRootsTask::work` and `PSAdjustTask::work`.
> 
> But I don't have experience to test/verify the performance improvement of the GC.
> If this patch needs such test data before integrating, please guide and help me here.
> 
> Thanks for the review and guidance.
> 
> Best Regards,
> -- Guoxiong

The reason why this is not parallelized in stw pauses is because the CLD data structure is not amenable to parallelization at all. This is basically a linked list, and when parallelizing it this way, 
* every thread visits every CLD anyway (doing the pointer chasing)
* threads are massively choking themselves on obtaining the claim value
* the code adds another pass through the CLD linked list clearing the claim marks
In my experience you *will* get significant negative scaling (i.e. that phase taking significant multiples of the original time) with this simple approach.

I.e. this has been analyzed before, see https://bugs.openjdk.org/browse/JDK-8030144; only Shenandoah does a parallel walk, but with limited number of threads (e.g. https://bugs.openjdk.org/browse/JDK-8246097)

The latter CR also provides some applications with apparently many CLDG entries (Spring Boot and CLion), which may be used for this investigation.
Fwiw, it may be easier to start this investigation with G1 as it has the timing logging already implmented (but it is no problem to add this to Parallel temporarily(?)).

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

Changes requested by tschatzl (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14297#pullrequestreview-1464673943

From tschatzl at openjdk.org  Tue Jun  6 09:43:52 2023
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Tue, 6 Jun 2023 09:43:52 GMT
Subject: RFR: 8309065: Move the logic to determine archive heap location
 from CDS to G1 GC [v3]
In-Reply-To: <aAFtZq9f67wMS8JaitCjfwU9sZjE6k_ahqYNM8CBiec=.12f16641-161b-4352-ad95-e9d83228a68d@github.com>
References: <Jy8pV1WnLW6fMktk9Jmx5SF4JDWL8fl1zPNKOpV6FpA=.324de220-9ad8-4316-b871-c2b7dea5e6d2@github.com>
 <XATqoeHqYdc-FRfVKQqlJP8bsUXN7R9MqueuHQ0HGaQ=.ce7e8c50-c8d1-480e-83d7-c56a13d748a8@github.com>
 <0_uC7OzsWkpKayYwBA4Q3h1ZJuyD3GNukoB8B_6jSdE=.a549624f-75b7-4c5f-abc2-ccdf4954d013@github.com>
 <hE6cwIGMbxYC2Z7OPSukLRQNZ4JvSwQrD2T79H4dE68=.e5deb8b0-8b99-48cc-8afd-dedf9e31ca6e@github.com>
 <aAFtZq9f67wMS8JaitCjfwU9sZjE6k_ahqYNM8CBiec=.12f16641-161b-4352-ad95-e9d83228a68d@github.com>
Message-ID: <ueJ3wFmeMVQfJSaqaxvWbiuUzr6mfSrCLiaCglCJfwI=.b588279b-e3d7-4ce4-ada8-08e7044e4735@github.com>

On Tue, 6 Jun 2023 00:11:29 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> How about replacing `allocate_archive_range` with  `allocate_archive_space` which is actually planned for the next patch?
>> I am more inclined to keep size and address as separate parameters because the address is just a hint for the collectors, while size is not. With MemRegion as the type this information is not conveyed to the reader without reading the comments/code. This is also the reason why I prefer using "preferred_addr" rather than "requested_addr".
>> But if you feel otherwise I will update the API to use MemRegion.
>> 
>>> Maybe we should also change populate_archive_regions_bot_part and dealloc_archive_regions to use _range as well
>> 
>> I am not sure if it is necessary to update these APIs, as I would anyway be replacing them with fixup_archive_space() and handle_archive_space_failure() as mentioned in the description of main issue [JDK-8296263](https://bugs.openjdk.org/browse/JDK-8296263). IMO these names are more generic. If you want I can update the code to use these new names in this patch.
>
> If you plan to change these soon I think it's OK to leave the names as you have for this PR.

> Sorry to be picky, but I think `region` implies a single region, but G1 could allocate one or more regions to satisfy the request. I think it's better to use `allocate_archive_range(MemRegion requested_range)` to be more neutral. Passing the range in a `MemRegion` will also look similar to the API right above this one.
> 
> Maybe we should also change `populate_archive_regions_bot_part` and `dealloc_archive_regions` to use `_range` as well. What do you think, @tschatzl

I remember suggesting a rename long time ago in some earlier PR about refactoring this code..

> How about replacing `allocate_archive_range` with `allocate_archive_space` which is actually planned for the next patch?

As long as the naming is consistent throughout. 

> I am more inclined to keep size and address as separate parameters because the address is just a hint for the collectors, while size is not. With MemRegion as the type this information is not conveyed to the reader without reading the comments/code. This is also the reason why I prefer using "preferred_addr" rather than "requested_addr".
But if you feel otherwise I will update the API to use MemRegion.

I think separating the arguments for the above mentioned reasons is fine.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14208#discussion_r1219296138

From mdoerr at openjdk.org  Tue Jun  6 12:07:52 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Tue, 6 Jun 2023 12:07:52 GMT
Subject: RFR: JDK-8309297: Adjust ShenandoahHeap print_heap_regions_on [v2]
In-Reply-To: <6Sd_Wq_SP5TkAmMgCeuFe8-6nP7A7dZVO1h0_nmZUEo=.a7f588e9-c3bf-4e5d-b0ff-f1c7051fa71f@github.com>
References: <3EEbuWYZF264cbHXTzb825CwzVXY-5puhsWsZOS9ySM=.80200999-fc25-447f-9421-b5681e8cca02@github.com>
 <6Sd_Wq_SP5TkAmMgCeuFe8-6nP7A7dZVO1h0_nmZUEo=.a7f588e9-c3bf-4e5d-b0ff-f1c7051fa71f@github.com>
Message-ID: <R1xXnKFJaePfOFHZ9AWuNb8ynhhLwO3N-F48onTMRD4=.0c14d7c3-ecf5-448f-b309-589bc31938e0@github.com>

On Tue, 6 Jun 2023 08:30:09 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> The ShenandoahHeap print_heap_regions_on method prints some brief description of the columns of the heap table, however the description is unsorted and seems to be not fully up to date.
>> 
>> Another thought - is the critical pins column (CP=critical pins)  still needed or always 0  and obsolete now?
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove comment line

LGTM.

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

Marked as reviewed by mdoerr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14264#pullrequestreview-1465021722

From duke at openjdk.org  Tue Jun  6 12:16:53 2023
From: duke at openjdk.org (Ashutosh Mehra)
Date: Tue, 6 Jun 2023 12:16:53 GMT
Subject: RFR: 8309065: Move the logic to determine archive heap location
 from CDS to G1 GC [v3]
In-Reply-To: <ueJ3wFmeMVQfJSaqaxvWbiuUzr6mfSrCLiaCglCJfwI=.b588279b-e3d7-4ce4-ada8-08e7044e4735@github.com>
References: <Jy8pV1WnLW6fMktk9Jmx5SF4JDWL8fl1zPNKOpV6FpA=.324de220-9ad8-4316-b871-c2b7dea5e6d2@github.com>
 <XATqoeHqYdc-FRfVKQqlJP8bsUXN7R9MqueuHQ0HGaQ=.ce7e8c50-c8d1-480e-83d7-c56a13d748a8@github.com>
 <0_uC7OzsWkpKayYwBA4Q3h1ZJuyD3GNukoB8B_6jSdE=.a549624f-75b7-4c5f-abc2-ccdf4954d013@github.com>
 <hE6cwIGMbxYC2Z7OPSukLRQNZ4JvSwQrD2T79H4dE68=.e5deb8b0-8b99-48cc-8afd-dedf9e31ca6e@github.com>
 <aAFtZq9f67wMS8JaitCjfwU9sZjE6k_ahqYNM8CBiec=.12f16641-161b-4352-ad95-e9d83228a68d@github.com>
 <ueJ3wFmeMVQfJSaqaxvWbiuUzr6mfSrCLiaCglCJfwI=.b588279b-e3d7-4ce4-ada8-08e7044e4735@github.com>
Message-ID: <_6oVhOi34xxHPz9f0DqKPqCunDLqTHOfzbYfAxdUns8=.b6743e6e-ab1f-4007-b2d1-884e98add0eb@github.com>

On Tue, 6 Jun 2023 09:41:03 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> If you plan to change these soon I think it's OK to leave the names as you have for this PR.
>
>> Sorry to be picky, but I think `region` implies a single region, but G1 could allocate one or more regions to satisfy the request. I think it's better to use `allocate_archive_range(MemRegion requested_range)` to be more neutral. Passing the range in a `MemRegion` will also look similar to the API right above this one.
>> 
>> Maybe we should also change `populate_archive_regions_bot_part` and `dealloc_archive_regions` to use `_range` as well. What do you think, @tschatzl
> 
> I remember suggesting a rename long time ago in some earlier PR about refactoring this code..
> 
>> How about replacing `allocate_archive_range` with `allocate_archive_space` which is actually planned for the next patch?
> 
> As long as the naming is consistent throughout. 
> 
>> I am more inclined to keep size and address as separate parameters because the address is just a hint for the collectors, while size is not. With MemRegion as the type this information is not conveyed to the reader without reading the comments/code. This is also the reason why I prefer using "preferred_addr" rather than "requested_addr".
> But if you feel otherwise I will update the API to use MemRegion.
> 
> I think separating the arguments for the above mentioned reasons is fine.

> If you plan to change these soon I think it's OK to leave the names as you have for this PR.

Okay, then lets do the renaming in the next PR.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14208#discussion_r1219528842

From duke at openjdk.org  Tue Jun  6 12:31:52 2023
From: duke at openjdk.org (Ashutosh Mehra)
Date: Tue, 6 Jun 2023 12:31:52 GMT
Subject: RFR: 8309065: Move the logic to determine archive heap location
 from CDS to G1 GC [v2]
In-Reply-To: <TnWhtiQtK8m2lQdWjGrGGLiT1n5bpRPss_GL7jIDPhQ=.96375783-23be-40de-8ad8-a9b1d2fc35b1@github.com>
References: <Jy8pV1WnLW6fMktk9Jmx5SF4JDWL8fl1zPNKOpV6FpA=.324de220-9ad8-4316-b871-c2b7dea5e6d2@github.com>
 <ey6eW1-ONjMObQp1jtbC-2jIg1x2CQaRlYaL1GpGyR4=.07039560-65e1-48d0-a6a9-1d5f5e3c13c4@github.com>
 <jBHVW4u8FaDWBW36hKDpaU4tPloYdLnktXP0_ZuCjTI=.576feedf-1983-47be-bd0d-ff1bb849e919@github.com>
 <_wIgfWGtjNLtTm6s9_WsLWWEbLlBsW-xEr1CwBBoM0M=.3ce944c1-23ed-4376-8896-e3a437de17b0@github.com>
 <TnWhtiQtK8m2lQdWjGrGGLiT1n5bpRPss_GL7jIDPhQ=.96375783-23be-40de-8ad8-a9b1d2fc35b1@github.com>
Message-ID: <6ib0Q1-yxhxQZWw14G9C1x1eCgZ06-wbIx-5FYAQtkU=.f7cfb363-ffbd-4ac0-8668-2f2ff7a95a6a@github.com>

On Fri, 2 Jun 2023 07:27:17 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>>> @tschatzl
>>> 
>>> > I'm not convinced not giving a preferred location is a good idea. That seems to reduce the opportunity to directly map archives significantly. Previously, with only heap size changes, the archive could be mapped in still.
>>> 
>>> I am not sure I get this. The patch does not change the ability to map the archive. It just moved the calculation to map the archive region from CDS to G1. Before this patch CDS code would determine the address for mapping the archive space towards the top of the heap and pass that address to G1. This patch just moves that calculation to G1. So it should be at-par with the current state. If it is not, please point out and I can work on fixing that.
>>> 
>>> > Since this change is an intermediate step, could you provide an overview of the final API/change too? It is hard to comment on this without knowing where you are going with that.
>>> 
>>> Ok, I have updated the description of the main issue [JDK-8296263](https://bugs.openjdk.org/browse/JDK-8296263) with some details on the expected changes in the future patches. My main aim with this work is mainly code reorganization to avoid using different GC APIs in CDS depending on the GC policy in use. When this is completed I expect it to provide same functionality as today. Any enhancement, like passing preferred location to map archive heap, can be built on top of this.
>>> 
>>> Hope this helps.
>> 
>> Hi Ashutosh,
>> 
>> You are right that in the existing code, although filemap.cpp finds out where the requested range is, it doesn't actually pass that to G1. It just requests G1 to reserve a range at the end of the runtime heap. So your PR preserves this behavior.
>> 
>> I think Thomas's point is, the requested range should be passed to the `alloc_archive_regions()` API, even though the collector may simply ignore it.
>> 
>> In the past, the archive G1 regions were not movable, so it was preferable to put them at the end of the heap, even though that might cause relocation. Now that the archive regions are just regular "old" regions, which can move, it may be preferable to reserve them at the requested range.
>> 
>> BTW, perhaps `alloc_archive_regions()` should be renamed to `alloc_archive_range()` going forward.  The plural form of "regions" sounds odd for non-region based collectors.
>
>> Hi Ashutosh,
>> 
>> You are right that in the existing code, although filemap.cpp finds out where the requested range is, it doesn't actually pass that to G1. It just requests G1 to reserve a range at the end of the runtime heap. So your PR preserves this behavior.
>> 
>> I think Thomas's point is, the requested range should be passed to the `alloc_archive_regions()` API, even though the collector may simply ignore it.
> 
> Exactly, sorry if I wasn't clear enough.
> 
>> 
>> In the past, the archive G1 regions were not movable, so it was preferable to put them at the end of the heap, even though that might cause relocation. Now that the archive regions are just regular "old" regions, which can move, it may be preferable to reserve them at the requested range.
>> 
>> BTW, perhaps `alloc_archive_regions()` should be renamed to `alloc_archive_range()` going forward. The plural form of "regions" sounds odd for non-region based collectors.
> 
> +1
> 
> Thanks,
>   Thomas

@tschatzl let me know if there are any other concerns to address in this patch.

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

PR Comment: https://git.openjdk.org/jdk/pull/14208#issuecomment-1578676159

From tschatzl at openjdk.org  Tue Jun  6 12:44:53 2023
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Tue, 6 Jun 2023 12:44:53 GMT
Subject: RFR: 8309065: Move the logic to determine archive heap location
 from CDS to G1 GC [v2]
In-Reply-To: <TnWhtiQtK8m2lQdWjGrGGLiT1n5bpRPss_GL7jIDPhQ=.96375783-23be-40de-8ad8-a9b1d2fc35b1@github.com>
References: <Jy8pV1WnLW6fMktk9Jmx5SF4JDWL8fl1zPNKOpV6FpA=.324de220-9ad8-4316-b871-c2b7dea5e6d2@github.com>
 <ey6eW1-ONjMObQp1jtbC-2jIg1x2CQaRlYaL1GpGyR4=.07039560-65e1-48d0-a6a9-1d5f5e3c13c4@github.com>
 <jBHVW4u8FaDWBW36hKDpaU4tPloYdLnktXP0_ZuCjTI=.576feedf-1983-47be-bd0d-ff1bb849e919@github.com>
 <_wIgfWGtjNLtTm6s9_WsLWWEbLlBsW-xEr1CwBBoM0M=.3ce944c1-23ed-4376-8896-e3a437de17b0@github.com>
 <TnWhtiQtK8m2lQdWjGrGGLiT1n5bpRPss_GL7jIDPhQ=.96375783-23be-40de-8ad8-a9b1d2fc35b1@github.com>
Message-ID: <RMoOr6OHD1UC8Ytb91JeYhK-Roui3dOWD1zxZdkX0nA=.d5bde896-a757-48de-b757-2a69c964879a@github.com>

On Fri, 2 Jun 2023 07:27:17 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>>> @tschatzl
>>> 
>>> > I'm not convinced not giving a preferred location is a good idea. That seems to reduce the opportunity to directly map archives significantly. Previously, with only heap size changes, the archive could be mapped in still.
>>> 
>>> I am not sure I get this. The patch does not change the ability to map the archive. It just moved the calculation to map the archive region from CDS to G1. Before this patch CDS code would determine the address for mapping the archive space towards the top of the heap and pass that address to G1. This patch just moves that calculation to G1. So it should be at-par with the current state. If it is not, please point out and I can work on fixing that.
>>> 
>>> > Since this change is an intermediate step, could you provide an overview of the final API/change too? It is hard to comment on this without knowing where you are going with that.
>>> 
>>> Ok, I have updated the description of the main issue [JDK-8296263](https://bugs.openjdk.org/browse/JDK-8296263) with some details on the expected changes in the future patches. My main aim with this work is mainly code reorganization to avoid using different GC APIs in CDS depending on the GC policy in use. When this is completed I expect it to provide same functionality as today. Any enhancement, like passing preferred location to map archive heap, can be built on top of this.
>>> 
>>> Hope this helps.
>> 
>> Hi Ashutosh,
>> 
>> You are right that in the existing code, although filemap.cpp finds out where the requested range is, it doesn't actually pass that to G1. It just requests G1 to reserve a range at the end of the runtime heap. So your PR preserves this behavior.
>> 
>> I think Thomas's point is, the requested range should be passed to the `alloc_archive_regions()` API, even though the collector may simply ignore it.
>> 
>> In the past, the archive G1 regions were not movable, so it was preferable to put them at the end of the heap, even though that might cause relocation. Now that the archive regions are just regular "old" regions, which can move, it may be preferable to reserve them at the requested range.
>> 
>> BTW, perhaps `alloc_archive_regions()` should be renamed to `alloc_archive_range()` going forward.  The plural form of "regions" sounds odd for non-region based collectors.
>
>> Hi Ashutosh,
>> 
>> You are right that in the existing code, although filemap.cpp finds out where the requested range is, it doesn't actually pass that to G1. It just requests G1 to reserve a range at the end of the runtime heap. So your PR preserves this behavior.
>> 
>> I think Thomas's point is, the requested range should be passed to the `alloc_archive_regions()` API, even though the collector may simply ignore it.
> 
> Exactly, sorry if I wasn't clear enough.
> 
>> 
>> In the past, the archive G1 regions were not movable, so it was preferable to put them at the end of the heap, even though that might cause relocation. Now that the archive regions are just regular "old" regions, which can move, it may be preferable to reserve them at the requested range.
>> 
>> BTW, perhaps `alloc_archive_regions()` should be renamed to `alloc_archive_range()` going forward. The plural form of "regions" sounds odd for non-region based collectors.
> 
> +1
> 
> Thanks,
>   Thomas

> @tschatzl let me know if there are any other concerns to address in this patch.

Given the API is in flux, and the follow-up not certain to be reviewed by Thursday I would like to have this patch *at least* moved to after the JDK 21 fork. Otherwise maintainers need to deal with this awkwardness for a long time unnecessarily.

Unlike Ioi I am not good with the current naming.

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

PR Comment: https://git.openjdk.org/jdk/pull/14208#issuecomment-1578693782

From mbaesken at openjdk.org  Tue Jun  6 12:47:54 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 6 Jun 2023 12:47:54 GMT
Subject: RFR: JDK-8309297: Adjust ShenandoahHeap print_heap_regions_on [v2]
In-Reply-To: <6Sd_Wq_SP5TkAmMgCeuFe8-6nP7A7dZVO1h0_nmZUEo=.a7f588e9-c3bf-4e5d-b0ff-f1c7051fa71f@github.com>
References: <3EEbuWYZF264cbHXTzb825CwzVXY-5puhsWsZOS9ySM=.80200999-fc25-447f-9421-b5681e8cca02@github.com>
 <6Sd_Wq_SP5TkAmMgCeuFe8-6nP7A7dZVO1h0_nmZUEo=.a7f588e9-c3bf-4e5d-b0ff-f1c7051fa71f@github.com>
Message-ID: <UqS8x2Mu03VZDX3Lk49HyaaAZwWvPvoFuvsKhGOop84=.79a79ad2-0835-4bae-b887-0baab2f88f3c@github.com>

On Tue, 6 Jun 2023 08:30:09 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> The ShenandoahHeap print_heap_regions_on method prints some brief description of the columns of the heap table, however the description is unsorted and seems to be not fully up to date.
>> 
>> Another thought - is the critical pins column (CP=critical pins)  still needed or always 0  and obsolete now?
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove comment line

Hi  Kelvin, Y. S. Ramakrishna and Martin, thanks for the reviews.

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

PR Comment: https://git.openjdk.org/jdk/pull/14264#issuecomment-1578700487

From tschatzl at openjdk.org  Tue Jun  6 12:48:55 2023
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Tue, 6 Jun 2023 12:48:55 GMT
Subject: RFR: 8309065: Move the logic to determine archive heap location
 from CDS to G1 GC [v3]
In-Reply-To: <XATqoeHqYdc-FRfVKQqlJP8bsUXN7R9MqueuHQ0HGaQ=.ce7e8c50-c8d1-480e-83d7-c56a13d748a8@github.com>
References: <Jy8pV1WnLW6fMktk9Jmx5SF4JDWL8fl1zPNKOpV6FpA=.324de220-9ad8-4316-b871-c2b7dea5e6d2@github.com>
 <XATqoeHqYdc-FRfVKQqlJP8bsUXN7R9MqueuHQ0HGaQ=.ce7e8c50-c8d1-480e-83d7-c56a13d748a8@github.com>
Message-ID: <UbOI9-maMNPi2yLcYzkLw82BCPgyI8eCmfxP7w_hE1Q=.8b7cd532-f4aa-4f39-99eb-f03e322c8ccb@github.com>

On Fri, 2 Jun 2023 19:46:31 GMT, Ashutosh Mehra <duke at openjdk.org> wrote:

>> This patch is the first step towards having a single set of GC APIs for allocating heap space for the archived objects (See https://bugs.openjdk.org/browse/JDK-8296263).
>> It moves some of the G1 specific logic from CDS to G1 gc without changing the functionality.
>> 
>> Changes that add/update GC APIs for handling archive heap would be introduced in upcoming patches.
>
> Ashutosh Mehra has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments - updates to alloc_archive_regions() api
>   
>   Signed-off-by: Ashutosh Mehra <asmehra at redhat.com>

(I can't just request changes without a comment, although I commented before, so here the same again)

Given soon JDK21 fork, and the risk of having this API change for a long time in JDK 21, I am not good with leaving the change as is. Please either fix up the naming or leave integration until after the fork.

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

Changes requested by tschatzl (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14208#pullrequestreview-1465116293

From duke at openjdk.org  Tue Jun  6 12:57:56 2023
From: duke at openjdk.org (Ashutosh Mehra)
Date: Tue, 6 Jun 2023 12:57:56 GMT
Subject: RFR: 8309065: Move the logic to determine archive heap location
 from CDS to G1 GC [v2]
In-Reply-To: <RMoOr6OHD1UC8Ytb91JeYhK-Roui3dOWD1zxZdkX0nA=.d5bde896-a757-48de-b757-2a69c964879a@github.com>
References: <Jy8pV1WnLW6fMktk9Jmx5SF4JDWL8fl1zPNKOpV6FpA=.324de220-9ad8-4316-b871-c2b7dea5e6d2@github.com>
 <ey6eW1-ONjMObQp1jtbC-2jIg1x2CQaRlYaL1GpGyR4=.07039560-65e1-48d0-a6a9-1d5f5e3c13c4@github.com>
 <jBHVW4u8FaDWBW36hKDpaU4tPloYdLnktXP0_ZuCjTI=.576feedf-1983-47be-bd0d-ff1bb849e919@github.com>
 <_wIgfWGtjNLtTm6s9_WsLWWEbLlBsW-xEr1CwBBoM0M=.3ce944c1-23ed-4376-8896-e3a437de17b0@github.com>
 <TnWhtiQtK8m2lQdWjGrGGLiT1n5bpRPss_GL7jIDPhQ=.96375783-23be-40de-8ad8-a9b1d2fc35b1@github.com>
 <RMoOr6OHD1UC8Ytb91JeYhK-Roui3dOWD1zxZdkX0nA=.d5bde896-a757-48de-b757-2a69c964879a@github.com>
Message-ID: <I-I3SsFQrrb8ujz7zpbb3TwH0SHpliSKsAlNIKSrkVw=.8780a4a5-2527-4f42-8457-e71327f10893@github.com>

On Tue, 6 Jun 2023 12:40:48 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Given the API is in flux, and the follow-up not certain to be reviewed by Thursday I would like to have this patch at least moved to after the JDK 21 fork. Otherwise maintainers need to deal with this awkwardness for a long time unnecessarily.

@tschatzl thanks for clarifying. I agree with your reasoning and I am fine with not having this patch in JDK 21. Having partial changes in JDK 21 doesn't serve any purpose anyway.

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

PR Comment: https://git.openjdk.org/jdk/pull/14208#issuecomment-1578715693

From ayang at openjdk.org  Tue Jun  6 13:35:56 2023
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Tue, 6 Jun 2023 13:35:56 GMT
Subject: RFR: 8309403: Serial: Remove the useless adaptive size policy in
 GenCollectedHeap
In-Reply-To: <Ti2vvexSpP3ykFTJLmjxLo_vKSCkP4dTcjlnz-BSW98=.b4ed2aee-66bf-486d-af6b-2312a1f11426@github.com>
References: <AgndfVJuqHKLBUtf3Q8srBUH_BnNnXmxnvTz1rNXuRU=.36ab3363-d8b4-4fe3-b7e5-83f92af37d06@github.com>
 <th101U_7ZJ0PzJyxkX3r63Fz6ENOjPJXxysCYV7CBWE=.6a2e1dc4-69c7-4575-be92-5f24c7fb0e56@github.com>
 <Ti2vvexSpP3ykFTJLmjxLo_vKSCkP4dTcjlnz-BSW98=.b4ed2aee-66bf-486d-af6b-2312a1f11426@github.com>
Message-ID: <KSB6PPU4LCJ9NxmcBFmHbSXIAzmrn4v1Lg23J9Xef5k=.394bc572-d477-4fa7-8176-249600809fb6@github.com>

On Mon, 5 Jun 2023 21:02:30 GMT, Guoxiong Li <gli at openjdk.org> wrote:

> I don't see other places to set it to true in Serial GC

`set_should_clear_all_soft_refs(true)` in `WB_FullGC`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14296#discussion_r1219665079

From ayang at openjdk.org  Tue Jun  6 13:42:01 2023
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Tue, 6 Jun 2023 13:42:01 GMT
Subject: RFR: 8308507: G1: GClocker induced GCs can starve threads
 requiring memory leading to OOME [v7]
In-Reply-To: <isFkAGDYVetvjxYWgCRuJVVrW624DJCUCjbfI2wwSEE=.f007866e-f3ce-486b-8953-f6003600957f@github.com>
References: <OA_NUok57_CwYFRa6FjYHfQpxEIQrxO7tHQ-1VM3Cus=.1621f0a2-7766-41a0-a45b-94c2703ff4bf@github.com>
 <isFkAGDYVetvjxYWgCRuJVVrW624DJCUCjbfI2wwSEE=.f007866e-f3ce-486b-8953-f6003600957f@github.com>
Message-ID: <eltwJWdVpUWodbJ8L3myZ8tf5amwtjapflhlVI1YsQw=.a1b154ff-43f6-4c71-afe1-d2527bbdeeb3@github.com>

On Mon, 5 Jun 2023 15:59:44 GMT, Ivan Walulya <iwalulya at openjdk.org> wrote:

>> Please review this change which fixes the thread starvation problem during allocation for G1.
>> 
>> The starvation problem is not limited to GCLocker, however, currently, it manifests as an OOME only when GCLocker is active. In other cases, the starvation only affects the "starved" thread as it may loop indefinitely. 
>> 
>> Starvation with an active GCLocker happens as below:
>> 
>> 1. Thread A tries to allocate memory as normal, and tries to start a GC; the GCLocker is active and so the thread gets stalled waiting for the GC.
>> 2. GCLocker induced GC executes and frees some memory.
>> 3. Thread A does not get any of that memory, but other threads also waiting for memory.
>> 4. Goto 1 until the gclocker retry count has been reached.
>> 
>> In this change, we take the general approach to solving starvation problems with announcement tables (request queues). On slow allocation, a thread that wishes to complete an Allocation GC and then attempt an allocation, announces its allocation request before proceeding to participate in a race to execute a GC safepoint. Whichever thread succeeds in executing the Allocation GC safepoint will be tasked with completing all allocation requests that were announced before the safepoint. This guarantees that all announced allocation requests are either satisfied during the safepoint, or failed in case there is not enough memory to complete all requests. This effectively deals with the starvation issue and reduces the number of allocation GCs triggered.
>> 
>> Note: The change also adopts ZList from ZGC and makes it available under utilities as DoublyLinkedList with slight modifications. 
>> 
>> Testing: Tier 1-7
>
> Ivan Walulya has updated the pull request incrementally with one additional commit since the last revision:
> 
>   prefer gc pause over heap expansion

src/hotspot/share/gc/g1/g1CollectedHeap.cpp line 434:

> 432:   if (request.pending()) {
> 433:     // GC Safepoint did not handle our allocation request. We should retry.
> 434:     return false;

Is it possible for a thread to hit this point indefinitely, i.e. some form of starvation?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14077#discussion_r1219675658

From ayang at openjdk.org  Tue Jun  6 13:45:20 2023
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Tue, 6 Jun 2023 13:45:20 GMT
Subject: RFR: 8309538: G1: Move total collection increment from Cleanup to
 Remark
Message-ID: <uMB-xwYhtwBWqvVAkaFpTmfYhxTlO_Rzm-XZxo6zsbA=.53ac8ffa-f346-4024-8b16-eebf0428c489@github.com>

Simple moving `increment_total_collections` to where empty-region reclaim lives.

Test: hotspot_gc

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

Commit messages:
 - g1-gc-counter

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

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

From iwalulya at openjdk.org  Tue Jun  6 13:48:05 2023
From: iwalulya at openjdk.org (Ivan Walulya)
Date: Tue, 6 Jun 2023 13:48:05 GMT
Subject: RFR: 8308507: G1: GClocker induced GCs can starve threads
 requiring memory leading to OOME [v7]
In-Reply-To: <eltwJWdVpUWodbJ8L3myZ8tf5amwtjapflhlVI1YsQw=.a1b154ff-43f6-4c71-afe1-d2527bbdeeb3@github.com>
References: <OA_NUok57_CwYFRa6FjYHfQpxEIQrxO7tHQ-1VM3Cus=.1621f0a2-7766-41a0-a45b-94c2703ff4bf@github.com>
 <isFkAGDYVetvjxYWgCRuJVVrW624DJCUCjbfI2wwSEE=.f007866e-f3ce-486b-8953-f6003600957f@github.com>
 <eltwJWdVpUWodbJ8L3myZ8tf5amwtjapflhlVI1YsQw=.a1b154ff-43f6-4c71-afe1-d2527bbdeeb3@github.com>
Message-ID: <Jzyh-gMbSkijR14urO74_masfCyMbmYz38suCJ3wnqo=.e1fe4469-8a06-4df1-8242-e8af850cb0be@github.com>

On Tue, 6 Jun 2023 13:39:21 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Ivan Walulya has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   prefer gc pause over heap expansion
>
> src/hotspot/share/gc/g1/g1CollectedHeap.cpp line 434:
> 
>> 432:   if (request.pending()) {
>> 433:     // GC Safepoint did not handle our allocation request. We should retry.
>> 434:     return false;
> 
> Is it possible for a thread to hit this point indefinitely, i.e. some form of starvation?

Only if you have indefinite triggering of non-allocating GCs. I wouldn't consider that starvation, as starvation here should imply some threads being able to allocate, and some other threads being unable to allocate even with allocation GCs triggered.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14077#discussion_r1219686118

From gli at openjdk.org  Tue Jun  6 16:10:00 2023
From: gli at openjdk.org (Guoxiong Li)
Date: Tue, 6 Jun 2023 16:10:00 GMT
Subject: RFR: 8309404: Parallel: Process class loader data graph in
 parallel in young gc
In-Reply-To: <VdC7jNuh7ZP2VFwKi3THctD2znSFVDQNGf6dUe4LCow=.2220db44-7d8f-4c04-a2dc-31f8885998c3@github.com>
References: <VdC7jNuh7ZP2VFwKi3THctD2znSFVDQNGf6dUe4LCow=.2220db44-7d8f-4c04-a2dc-31f8885998c3@github.com>
Message-ID: <D_F5F1TaI0rOw8oXHQozi4ErYtCQ2BETy6ZiwlBwmKE=.8e006467-3291-4508-8b8c-402be6617a73@github.com>

On Sat, 3 Jun 2023 09:57:43 GMT, Guoxiong Li <gli at openjdk.org> wrote:

> Hi all,
> 
> This patch parallelizes the process of the class loader data graph in young gc.
> 
> The class `ClassLoaderData` has a field `_claim` to avoid applying oop closure more than once 
> and the method `ClassLoaderData::oops_do` can check if the CLD had been claimed.
> The parallel full gc has already used them in `MarkFromRootsTask::work` and `PSAdjustTask::work`.
> 
> But I don't have experience to test/verify the performance improvement of the GC.
> If this patch needs such test data before integrating, please guide and help me here.
> 
> Thanks for the review and guidance.
> 
> Best Regards,
> -- Guoxiong

> The reason why this is not parallelized in stw pauses is because the CLD data structure is not amenable to parallelization at all. This is basically a linked list, and when parallelizing it this way,
> 
> * every thread visits every CLD anyway (doing the pointer chasing)
> * threads are massively choking themselves on obtaining the claim value
> * the code adds another pass through the CLD linked list clearing the claim marks
>   In my experience you _will_ get significant negative scaling (i.e. that phase taking significant multiples of the original time) with this simple approach.
> 
> I.e. this has been analyzed before, see https://bugs.openjdk.org/browse/JDK-8030144; only Shenandoah does a parallel walk, but with limited number of threads (e.g. https://bugs.openjdk.org/browse/JDK-8246097)
> 
> The latter CR also provides some applications with apparently many CLDG entries (Spring Boot and CLion), which may be used for this investigation. Fwiw, it may be easier to start this investigation with G1 as it has the timing logging already implmented (but it is no problem to add this to Parallel temporarily(?)).

Thanks for the guidance. The full GC in `Parallel` had parallelized it, so previously, I thought it is good to do the same thing in young GC. One of young GC or full GC should be adjusted. I will investigate more information in related issues (mainly test the performance).

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

PR Comment: https://git.openjdk.org/jdk/pull/14297#issuecomment-1579053881

From gli at openjdk.org  Tue Jun  6 16:26:44 2023
From: gli at openjdk.org (Guoxiong Li)
Date: Tue, 6 Jun 2023 16:26:44 GMT
Subject: RFR: 8309403: Serial: Remove the useless adaptive size policy in
 GenCollectedHeap
In-Reply-To: <KSB6PPU4LCJ9NxmcBFmHbSXIAzmrn4v1Lg23J9Xef5k=.394bc572-d477-4fa7-8176-249600809fb6@github.com>
References: <AgndfVJuqHKLBUtf3Q8srBUH_BnNnXmxnvTz1rNXuRU=.36ab3363-d8b4-4fe3-b7e5-83f92af37d06@github.com>
 <th101U_7ZJ0PzJyxkX3r63Fz6ENOjPJXxysCYV7CBWE=.6a2e1dc4-69c7-4575-be92-5f24c7fb0e56@github.com>
 <Ti2vvexSpP3ykFTJLmjxLo_vKSCkP4dTcjlnz-BSW98=.b4ed2aee-66bf-486d-af6b-2312a1f11426@github.com>
 <KSB6PPU4LCJ9NxmcBFmHbSXIAzmrn4v1Lg23J9Xef5k=.394bc572-d477-4fa7-8176-249600809fb6@github.com>
Message-ID: <wKX4XIMNXhFrnCaqyuYX2wKKf_r2U5f1T5E7gab3WEs=.224bd13f-6807-4186-b5d3-f4e60ca9871e@github.com>

On Tue, 6 Jun 2023 13:32:49 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> The default value of `_should_clear_all_soft_refs` is `false` and I don't see other places to set it to `true` in Serial GC. And from the comment, I think it is a leftover of CMS.
>> 
>>>  // If near gc overhear limit, continue to clear SoftRefs.  SoftRefs may
>>>  // have been cleared in the last collection but if the gc overhear
>>>  // limit continues to be near, SoftRefs should still be cleared.
>
>> I don't see other places to set it to true in Serial GC
> 
> `set_should_clear_all_soft_refs(true)` in `WB_FullGC`.

The `WB_FullGC` is just test code. I have several problems. If the test code wants the GC to clear all soft references (`set_should_clear_all_soft_refs(true)` in `WB_FullGC`), why do we set it to `false` again? If we have a reason to set it to `false` again, why do other GCs not set it (Why is `SoftRefGenPolicy` only used at Serial GC?).

> // If near gc overhear limit, continue to clear SoftRefs. SoftRefs may
> // have been cleared in the last collection but if the gc overhear
> // limit continues to be near, SoftRefs should still be cleared.

>From the comment, the intent of the method `SoftRefGenPolicy::cleared_all_soft_refs` is letting the next GC re-clear the soft reference if **near gc overhear limit**. But the Serial GC has no gc overhear limit check now. So I still think it is just a leftover of CMS.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14296#discussion_r1219951301

From gli at openjdk.org  Tue Jun  6 17:02:32 2023
From: gli at openjdk.org (Guoxiong Li)
Date: Tue, 6 Jun 2023 17:02:32 GMT
Subject: RFR: 8272147: Consolidate preserved marks handling with other STW
 collectors [v2]
In-Reply-To: <jXZiOVJDgymUKJne7d-LXCpIx7xcPoFPGATHIGSw_HE=.cb5e5aa0-001c-4842-9c16-7cb70e41b8a2@github.com>
References: <jXZiOVJDgymUKJne7d-LXCpIx7xcPoFPGATHIGSw_HE=.cb5e5aa0-001c-4842-9c16-7cb70e41b8a2@github.com>
Message-ID: <S1Tl2UbKhmi1ijfWk28_a51CL3C5NIlIVVJng-iuopw=.72e339b0-4796-46fb-92a0-3e5e7ab44e17@github.com>

> Hi all,
> 
> This patch removes the class `markSweep.hpp::PreservedMark` and uses the shared `PreservedMarksSet` instead.
> 
> In order to keep the meaning of the field `_preserved_marks` in `markSweep`,
> I need to use `OopAndMarkWord` explicitly. So I move `OopAndMarkWord` out of `PreservedMarks`.
> 
> Tests:
> `hotspot:tier1` passed locally (x86 & linux).
> 
> Thanks for the review.
> 
> Best Regards,
> -- Guoxiong

Guoxiong Li 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:

 - Use the method 'adjust_during_full_gc' and polish the included header.
 - Merge branch 'master' into JDK-8272147
 - JDK-8272147

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14274/files
  - new: https://git.openjdk.org/jdk/pull/14274/files/5f896236..bcf737c6

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

  Stats: 12076 lines in 159 files changed: 10642 ins; 838 del; 596 mod
  Patch: https://git.openjdk.org/jdk/pull/14274.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14274/head:pull/14274

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

From gli at openjdk.org  Tue Jun  6 17:02:34 2023
From: gli at openjdk.org (Guoxiong Li)
Date: Tue, 6 Jun 2023 17:02:34 GMT
Subject: RFR: 8272147: Consolidate preserved marks handling with other STW
 collectors [v2]
In-Reply-To: <2pzMX3PFWEAw66zFvRqoHT7IU4dBK3a45rBsAtol1vs=.cc5fb7ed-fabe-460b-a4d0-7ec09a0c0a8e@github.com>
References: <jXZiOVJDgymUKJne7d-LXCpIx7xcPoFPGATHIGSw_HE=.cb5e5aa0-001c-4842-9c16-7cb70e41b8a2@github.com>
 <2pzMX3PFWEAw66zFvRqoHT7IU4dBK3a45rBsAtol1vs=.cc5fb7ed-fabe-460b-a4d0-7ec09a0c0a8e@github.com>
Message-ID: <vNeFdVK7nEPgim0IRCAM7eBC6ePZannJ_iTWgpKXc1c=.2ac753bd-7bff-4128-b815-044de27c8627@github.com>

On Mon, 5 Jun 2023 15:03:12 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Guoxiong Li 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:
>> 
>>  - Use the method 'adjust_during_full_gc' and polish the included header.
>>  - Merge branch 'master' into JDK-8272147
>>  - JDK-8272147
>
> src/hotspot/share/gc/serial/genMarkSweep.cpp line 51:
> 
>> 49: #include "gc/shared/strongRootsScope.hpp"
>> 50: #include "gc/shared/weakProcessor.hpp"
>> 51: #include "gc/shared/preservedMarks.inline.hpp"
> 
> Includes should be ordered alphabetically.

Fixed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14274#discussion_r1220003647

From gli at openjdk.org  Tue Jun  6 17:02:35 2023
From: gli at openjdk.org (Guoxiong Li)
Date: Tue, 6 Jun 2023 17:02:35 GMT
Subject: RFR: 8272147: Consolidate preserved marks handling with other STW
 collectors [v2]
In-Reply-To: <vCkqVwip-nyVeXCX18Yx-j04uJQuS1PGol1K7DIMXwk=.df999bd6-21ba-4fbf-9654-359fb523faf1@github.com>
References: <jXZiOVJDgymUKJne7d-LXCpIx7xcPoFPGATHIGSw_HE=.cb5e5aa0-001c-4842-9c16-7cb70e41b8a2@github.com>
 <QShvVPwXfVTRPqtV31xcc32SpiPcU1E6CN8AWftCpL0=.9da386fe-b4cb-45fa-ac98-7bb4f7633bf1@github.com>
 <ZMaKdK8M28yJ0hJkX2lEZ_3rqiLr7-RegW3NZBxphvM=.1fac828a-2436-4c02-a1ea-4ca1046ca34e@github.com>
 <vCkqVwip-nyVeXCX18Yx-j04uJQuS1PGol1K7DIMXwk=.df999bd6-21ba-4fbf-9654-359fb523faf1@github.com>
Message-ID: <KdMwNicrDGsqVi3Hym087aX3AskqxWUQKjl8VowwwqU=.7712c01e-7e2e-451f-b12b-16b73e22f53b@github.com>

On Tue, 6 Jun 2023 08:00:45 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> The methods `MarkSweep::adjust_pointer` and `PreservedMarks::adjust_during_full_gc` have different implementations. The method `MarkSweep::adjust_pointer` seems doing more thing. So in `MarkSweep::adjust_marks`, I use `get_stack` to get the stack and invoke `MarkSweep::adjust_pointer` explicitly. If you can confirm `PreservedMarks::adjust_during_full_gc` is good to replace `MarkSweep::adjust_pointer`, I will remove `get_stack` and use `PreservedMarks::adjust_during_full_gc` instead of `MarkSweep::adjust_pointer`.
>
> You can replace that code with `PreservedMarks::adjust_during_full_gc` from what I can see; the additional code in `MarkSweep::adjust_pointer` only deals with the generic case if the passed `oop` is null, which can't be the case for oops in the preserved marks set.

I updated the code just now.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14274#discussion_r1220003565

From azafari at openjdk.org  Wed Jun  7 08:57:07 2023
From: azafari at openjdk.org (Afshin Zafari)
Date: Wed, 7 Jun 2023 08:57:07 GMT
Subject: RFR: 8281455: Change JVM options with small ranges from 64 to 32 bits, 
 for gc_globals.hpp
Message-ID: <PUZ-VNLsAs748dp0p0fknfkp6VxzSZRvBXp3cJvheko=.101c475e-a097-47ee-8ead-3464def85d7a@github.com>

The `uintx/intx` options whose ranges are small enough are changed to `uint/int`, otherwise gcc complains 
when `-Wconversion` is used in build.
Their uses in printf formats are changed accordingly.

### Tests
Locally hotspot:tier1 tested on linux-x64
mach5 tiers 1-4 on Linux and Windows 64bits platforms passed.

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

Commit messages:
 - move max_uint definition after uint def.
 - defined max_uint.
 - some more changes where juint were upperbounds.
 - JVM options limited to GC ones.
 - before rebase on master

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

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

From tschatzl at openjdk.org  Wed Jun  7 08:57:08 2023
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Wed, 7 Jun 2023 08:57:08 GMT
Subject: RFR: 8281455: Change JVM options with small ranges from 64 to 32
 bits, for gc_globals.hpp
In-Reply-To: <PUZ-VNLsAs748dp0p0fknfkp6VxzSZRvBXp3cJvheko=.101c475e-a097-47ee-8ead-3464def85d7a@github.com>
References: <PUZ-VNLsAs748dp0p0fknfkp6VxzSZRvBXp3cJvheko=.101c475e-a097-47ee-8ead-3464def85d7a@github.com>
Message-ID: <N2hrp2QaP5cIxAgZ5ACCBA78-S2cyZviQWdUZYCiw1Q=.11a8d6ad-b446-4dc3-995d-ac29672c0a20@github.com>

On Thu, 1 Jun 2023 11:15:48 GMT, Afshin Zafari <azafari at openjdk.org> wrote:

> The `uintx/intx` options whose ranges are small enough are changed to `uint/int`, otherwise gcc complains 
> when `-Wconversion` is used in build.
> Their uses in printf formats are changed accordingly.
> 
> ### Tests
> Locally hotspot:tier1 tested on linux-x64
> mach5 tiers 1-4 on Linux and Windows 64bits platforms passed.

Although it's a bit early to review, when I looked at this briefly, I believe also the `uintx` that have a `juint_max` upper range can be replaced with `uint` (and use the equivalent `UINT_MAX` as upper range, `j`-types should only be used with JNI code).

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

PR Comment: https://git.openjdk.org/jdk/pull/14259#issuecomment-1573295241

From azafari at openjdk.org  Wed Jun  7 08:57:09 2023
From: azafari at openjdk.org (Afshin Zafari)
Date: Wed, 7 Jun 2023 08:57:09 GMT
Subject: RFR: 8281455: Change JVM options with small ranges from 64 to 32
 bits, for gc_globals.hpp
In-Reply-To: <N2hrp2QaP5cIxAgZ5ACCBA78-S2cyZviQWdUZYCiw1Q=.11a8d6ad-b446-4dc3-995d-ac29672c0a20@github.com>
References: <PUZ-VNLsAs748dp0p0fknfkp6VxzSZRvBXp3cJvheko=.101c475e-a097-47ee-8ead-3464def85d7a@github.com>
 <N2hrp2QaP5cIxAgZ5ACCBA78-S2cyZviQWdUZYCiw1Q=.11a8d6ad-b446-4dc3-995d-ac29672c0a20@github.com>
Message-ID: <pGcpFapF-aPMQ_tDnJgEgMw7D7jLLXqYeX57yELbiPc=.c1d2daac-9e16-4385-92da-2b564c7c2d3d@github.com>

On Fri, 2 Jun 2023 07:38:56 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Although it's a bit early to review, when I looked at this briefly, I believe also the `uintx` that have a `juint_max` upper range can be replaced with `uint` (and use the equivalent `UINT_MAX` as upper range, `j`-types should only be used with JNI code).

Done.

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

PR Comment: https://git.openjdk.org/jdk/pull/14259#issuecomment-1580230319

From gli at openjdk.org  Wed Jun  7 09:13:54 2023
From: gli at openjdk.org (Guoxiong Li)
Date: Wed, 7 Jun 2023 09:13:54 GMT
Subject: RFR: 8309404: Parallel: Process class loader data graph in
 parallel in young gc
In-Reply-To: <0H9H0i9CJh1aMs971hNUBJVxSjpYrkozgO3b_W2iG6o=.af658eb7-bc82-4bbe-a35c-5a0b9535321f@github.com>
References: <VdC7jNuh7ZP2VFwKi3THctD2znSFVDQNGf6dUe4LCow=.2220db44-7d8f-4c04-a2dc-31f8885998c3@github.com>
 <0H9H0i9CJh1aMs971hNUBJVxSjpYrkozgO3b_W2iG6o=.af658eb7-bc82-4bbe-a35c-5a0b9535321f@github.com>
Message-ID: <6aVeq2e8L_KGhHS4677tVMLeU_CrowRfXdL3fNg5ux8=.11cd7746-cc4d-4ff6-a05c-b6c75aeb8add@github.com>

On Tue, 6 Jun 2023 09:03:47 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Hi all,
>> 
>> This patch parallelizes the process of the class loader data graph in young gc.
>> 
>> The class `ClassLoaderData` has a field `_claim` to avoid applying oop closure more than once 
>> and the method `ClassLoaderData::oops_do` can check if the CLD had been claimed.
>> The parallel full gc has already used them in `MarkFromRootsTask::work` and `PSAdjustTask::work`.
>> 
>> But I don't have experience to test/verify the performance improvement of the GC.
>> If this patch needs such test data before integrating, please guide and help me here.
>> 
>> Thanks for the review and guidance.
>> 
>> Best Regards,
>> -- Guoxiong
>
> The reason why this is not parallelized in stw pauses is because the CLD data structure is not amenable to parallelization at all. This is basically a linked list, and when parallelizing it this way, 
> * every thread visits every CLD anyway (doing the pointer chasing)
> * threads are massively choking themselves on obtaining the claim value
> * the code adds another pass through the CLD linked list clearing the claim marks
> In my experience you *will* get significant negative scaling (i.e. that phase taking significant multiples of the original time) with this simple approach.
> 
> I.e. this has been analyzed before, see https://bugs.openjdk.org/browse/JDK-8030144; only Shenandoah does a parallel walk, but with limited number of threads (e.g. https://bugs.openjdk.org/browse/JDK-8246097)
> 
> The latter CR also provides some applications with apparently many CLDG entries (Spring Boot and CLion), which may be used for this investigation.
> Fwiw, it may be easier to start this investigation with G1 as it has the timing logging already implmented (but it is no problem to add this to Parallel temporarily(?)).

@tschatzl I have a question. During searching the roots in parallel, the claim values of the threads also need to be changed atomically by all the worker threads. Does it also have the same problem? Do you know/do any research related to it?


// file threads.cpp
void Threads::possibly_parallel_threads_do(bool is_par, ThreadClosure* tc) {
  assert_at_safepoint();

  uintx claim_token = Threads::thread_claim_token();
  ALL_JAVA_THREADS(p) {
    if (p->claim_threads_do(is_par, claim_token)) {
      tc->do_thread(p);
    }
  }
  for (NonJavaThread::Iterator njti; !njti.end(); njti.step()) {
    Thread* current = njti.current();
    if (current->claim_threads_do(is_par, claim_token)) {
      tc->do_thread(current);
    }
  }
}

// file thread.cpp
bool Thread::claim_par_threads_do(uintx claim_token) {
  uintx token = _threads_do_token;
  if (token != claim_token) {
    uintx res = Atomic::cmpxchg(&_threads_do_token, token, claim_token);
    if (res == token) {
      return true;
    }
    guarantee(res == claim_token, "invariant");
  }
  return false;
}

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

PR Comment: https://git.openjdk.org/jdk/pull/14297#issuecomment-1580259670

From amitkumar at openjdk.org  Wed Jun  7 09:19:54 2023
From: amitkumar at openjdk.org (Amit Kumar)
Date: Wed, 7 Jun 2023 09:19:54 GMT
Subject: RFR: 8281455: Change JVM options with small ranges from 64 to 32
 bits, for gc_globals.hpp
In-Reply-To: <PUZ-VNLsAs748dp0p0fknfkp6VxzSZRvBXp3cJvheko=.101c475e-a097-47ee-8ead-3464def85d7a@github.com>
References: <PUZ-VNLsAs748dp0p0fknfkp6VxzSZRvBXp3cJvheko=.101c475e-a097-47ee-8ead-3464def85d7a@github.com>
Message-ID: <oASJk11pYFRHiAcPd9zDhgu-09zEO2H62qdQx4xbJWA=.82588ac1-f969-402c-9831-d66819a90bc6@github.com>

On Thu, 1 Jun 2023 11:15:48 GMT, Afshin Zafari <azafari at openjdk.org> wrote:

> The `uintx/intx` options whose ranges are small enough are changed to `uint/int`, otherwise gcc complains 
> when `-Wconversion` is used in build.
> Their uses in printf formats are changed accordingly.
> 
> ### Tests
> Locally hotspot:tier1 tested on linux-x64
> mach5 tiers 1-4 on Linux and Windows 64bits platforms passed.

Wouldn't that be good to keep the alignment for `` symbol in `gc_global.hpp` file ?

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

PR Comment: https://git.openjdk.org/jdk/pull/14259#issuecomment-1580275826

From stuefe at openjdk.org  Wed Jun  7 09:34:59 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Wed, 7 Jun 2023 09:34:59 GMT
Subject: RFR: 8309065: Move the logic to determine archive heap location
 from CDS to G1 GC [v3]
In-Reply-To: <XATqoeHqYdc-FRfVKQqlJP8bsUXN7R9MqueuHQ0HGaQ=.ce7e8c50-c8d1-480e-83d7-c56a13d748a8@github.com>
References: <Jy8pV1WnLW6fMktk9Jmx5SF4JDWL8fl1zPNKOpV6FpA=.324de220-9ad8-4316-b871-c2b7dea5e6d2@github.com>
 <XATqoeHqYdc-FRfVKQqlJP8bsUXN7R9MqueuHQ0HGaQ=.ce7e8c50-c8d1-480e-83d7-c56a13d748a8@github.com>
Message-ID: <M4Q8tx5azU88N1zScslx6oZjxQQPRFs0Ao2hfW41-iI=.9bdff767-e0ed-498c-8f6d-52b882649436@github.com>

On Fri, 2 Jun 2023 19:46:31 GMT, Ashutosh Mehra <duke at openjdk.org> wrote:

>> This patch is the first step towards having a single set of GC APIs for allocating heap space for the archived objects (See https://bugs.openjdk.org/browse/JDK-8296263).
>> It moves some of the G1 specific logic from CDS to G1 gc without changing the functionality.
>> 
>> Changes that add/update GC APIs for handling archive heap would be introduced in upcoming patches.
>
> Ashutosh Mehra has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments - updates to alloc_archive_regions() api
>   
>   Signed-off-by: Ashutosh Mehra <asmehra at redhat.com>

This looks okay, it is a cleaner separation than before.

Small nits and questions only. Approved (not for jdk21 and pending @tschatzl approval)

One note, I don't see a clear usage of INCLUDE_CDS and INCLUDE_G1GC, and it predates this patch. Don't we do this anymore? We still want to be buildable without CDS but with G1, and vice versa, right?

src/hotspot/share/cds/filemap.cpp line 2124:

> 2122: 
> 2123:   size_t word_size = size / HeapWordSize;
> 2124:   address requested_start = heap_region_requested_address();

Possibly for another RFE, if you intent to make this code move as verbatim as possible:

This feels like something that should use `r->mapping_offset()` directly - would make the code easier to understand.

src/hotspot/share/gc/g1/g1CollectedHeap.cpp line 551:

> 549:   HeapWord* start_addr = reserved.end() - align_up(word_size, HeapRegion::GrainWords);
> 550:   MemRegion range = MemRegion(start_addr, word_size);
> 551:   HeapWord* last_address = range.last();

Do I understand this - and the old code - correctly: we map the archive region at the end of the heap, therefore, if heap size changed between dump time and runtime, we will always have to relocate? I didn't look but I assume the dumptime heap size is the default heap size?

Another, possibly stupid, question: why don't we use the Heap bottom - we'd still avoid fragmentation but have a much higher chance of not relocating?

src/hotspot/share/gc/g1/g1CollectedHeap.hpp line 712:

> 710:   // the location of the archive space in the heap. The returned address may or may
> 711:   // not be same as the preferred address.
> 712:   HeapWord* alloc_archive_region(size_t word_size, HeapWord* preferred_addr);

The comment s good. This is only supposed to be used at JVM start, CDS runtime, before we start actually using the heap, right? Could we add this limitation to the comment for the casual reader?

Also, here and in other places G1: guard with `#ifdef INCLUDE_CDS` ?

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

Marked as reviewed by stuefe (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14208#pullrequestreview-1467074758
PR Review Comment: https://git.openjdk.org/jdk/pull/14208#discussion_r1221212920
PR Review Comment: https://git.openjdk.org/jdk/pull/14208#discussion_r1221241979
PR Review Comment: https://git.openjdk.org/jdk/pull/14208#discussion_r1221218276

From tschatzl at openjdk.org  Wed Jun  7 09:47:58 2023
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Wed, 7 Jun 2023 09:47:58 GMT
Subject: RFR: 8281455: Change JVM options with small ranges from 64 to 32
 bits, for gc_globals.hpp
In-Reply-To: <PUZ-VNLsAs748dp0p0fknfkp6VxzSZRvBXp3cJvheko=.101c475e-a097-47ee-8ead-3464def85d7a@github.com>
References: <PUZ-VNLsAs748dp0p0fknfkp6VxzSZRvBXp3cJvheko=.101c475e-a097-47ee-8ead-3464def85d7a@github.com>
Message-ID: <mma3GllWVHmYEY9J6GgTztWk6ma5xtFkiK8-YAf9i2w=.c042d1a1-3df5-4a1e-affa-2ca8296794a7@github.com>

On Thu, 1 Jun 2023 11:15:48 GMT, Afshin Zafari <azafari at openjdk.org> wrote:

> The `uintx/intx` options whose ranges are small enough are changed to `uint/int`, otherwise gcc complains 
> when `-Wconversion` is used in build.
> Their uses in printf formats are changed accordingly.
> 
> ### Tests
> Locally hotspot:tier1 tested on linux-x64
> mach5 tiers 1-4 on Linux and Windows 64bits platforms passed.

More candidates:

ParGCArrayScanChunk
MarkStackSize(Max) (these should probably be a `size_t`)
VerifyArchivedFields
ScavengeALotInterval
FullGCALotInterval
FullGCALotStart
FullGCALotDummies
VerifyGCLevel
MaxTenuringThreshold
InitialTenuringThreshold
GCDrainStackTargetSize

Some of these aren't uintx->uint conversions, so feel free to ignore.

src/hotspot/share/gc/parallel/psAdaptiveSizePolicy.cpp line 352:

> 350:           "PSAdaptiveSizePolicy::compute_eden_space_size: gc time limit"
> 351:           " gc_cost: %f "
> 352:           " GCTimeLimit: " UINT32_FORMAT,

We use `%u` as format specifiers for uint.

src/hotspot/share/gc/shared/gcOverheadChecker.cpp line 94:

> 92:   if (UseGCOverheadLimit) {
> 93:     if (gc_overhead_limit_exceeded()) {
> 94:       log_trace(gc, ergo)("GC is exceeding overhead limit of %d%%", GCTimeLimit);

Not sure why this place uses `%d` as format specifier compared to the `UINT32_FORMAT` the previous places did. Use `%u` ;)

src/hotspot/share/gc/shared/gc_globals.hpp line 169:

> 167:           "(effective only when using concurrent collectors)")              \
> 168:                                                                             \
> 169:   product(uint, GCLockerEdenExpansionPercent, 5,                           \

The `` needs to be aligned back.

src/hotspot/share/utilities/globalDefinitions.hpp line 442:

> 440: 
> 441: typedef unsigned int uint;   NEEDS_CLEANUP
> 442: const uint  max_uint  = (uint)-1;

The change should use the existing `UINT_MAX` instead of adding a new constant. Instead of a cast of `-1`, one should also use `~0` to get all-ones.

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

Changes requested by tschatzl (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14259#pullrequestreview-1467140885
PR Review Comment: https://git.openjdk.org/jdk/pull/14259#discussion_r1221262042
PR Review Comment: https://git.openjdk.org/jdk/pull/14259#discussion_r1221263784
PR Review Comment: https://git.openjdk.org/jdk/pull/14259#discussion_r1221264239
PR Review Comment: https://git.openjdk.org/jdk/pull/14259#discussion_r1221267209

From tschatzl at openjdk.org  Wed Jun  7 10:27:55 2023
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Wed, 7 Jun 2023 10:27:55 GMT
Subject: RFR: 8309404: Parallel: Process class loader data graph in
 parallel in young gc
In-Reply-To: <0H9H0i9CJh1aMs971hNUBJVxSjpYrkozgO3b_W2iG6o=.af658eb7-bc82-4bbe-a35c-5a0b9535321f@github.com>
References: <VdC7jNuh7ZP2VFwKi3THctD2znSFVDQNGf6dUe4LCow=.2220db44-7d8f-4c04-a2dc-31f8885998c3@github.com>
 <0H9H0i9CJh1aMs971hNUBJVxSjpYrkozgO3b_W2iG6o=.af658eb7-bc82-4bbe-a35c-5a0b9535321f@github.com>
Message-ID: <GsQ2zDNKPw1QySJN4hd0cfQrryct6vqR-ovv6L1FS3o=.25d38328-c8cf-459b-acf0-7f121a189823@github.com>

On Tue, 6 Jun 2023 09:03:47 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Hi all,
>> 
>> This patch parallelizes the process of the class loader data graph in young gc.
>> 
>> The class `ClassLoaderData` has a field `_claim` to avoid applying oop closure more than once 
>> and the method `ClassLoaderData::oops_do` can check if the CLD had been claimed.
>> The parallel full gc has already used them in `MarkFromRootsTask::work` and `PSAdjustTask::work`.
>> 
>> But I don't have experience to test/verify the performance improvement of the GC.
>> If this patch needs such test data before integrating, please guide and help me here.
>> 
>> Thanks for the review and guidance.
>> 
>> Best Regards,
>> -- Guoxiong
>
> The reason why this is not parallelized in stw pauses is because the CLD data structure is not amenable to parallelization at all. This is basically a linked list, and when parallelizing it this way, 
> * every thread visits every CLD anyway (doing the pointer chasing)
> * threads are massively choking themselves on obtaining the claim value
> * the code adds another pass through the CLD linked list clearing the claim marks
> In my experience you *will* get significant negative scaling (i.e. that phase taking significant multiples of the original time) with this simple approach.
> 
> I.e. this has been analyzed before, see https://bugs.openjdk.org/browse/JDK-8030144; only Shenandoah does a parallel walk, but with limited number of threads (e.g. https://bugs.openjdk.org/browse/JDK-8246097)
> 
> The latter CR also provides some applications with apparently many CLDG entries (Spring Boot and CLion), which may be used for this investigation.
> Fwiw, it may be easier to start this investigation with G1 as it has the timing logging already implmented (but it is no problem to add this to Parallel temporarily(?)).

> @tschatzl I have a question. During searching the roots in parallel, the claim values of the threads also need to be changed atomically by all the worker threads. Does it also have the same problem? Do you know/do any research related to it?
> 

It generally has the same problem, but is mitigated because the work per Thread is much larger (a Thread has typically many stacks levels to look through), so the relative impact smaller. The amount of contention on that is much lower too as the probability that multiple threads try to claim the same claim value is lower due to longer and more variable time to process the task.

There is also a newer API available that allows less contention claiming, see e.g. `G1JavaThreadsListClaimer` and the use in `G1PreEvacuateCollectionSetBatchTask`, however at this point it is only used in a few places. Replacement work isn't trivial.

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

PR Comment: https://git.openjdk.org/jdk/pull/14297#issuecomment-1580439963

From mbaesken at openjdk.org  Wed Jun  7 10:54:03 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 7 Jun 2023 10:54:03 GMT
Subject: Integrated: JDK-8309297: Adjust ShenandoahHeap print_heap_regions_on
In-Reply-To: <3EEbuWYZF264cbHXTzb825CwzVXY-5puhsWsZOS9ySM=.80200999-fc25-447f-9421-b5681e8cca02@github.com>
References: <3EEbuWYZF264cbHXTzb825CwzVXY-5puhsWsZOS9ySM=.80200999-fc25-447f-9421-b5681e8cca02@github.com>
Message-ID: <HgIvacRPdt_lgFWsdzQS9T1hPIxee-wlrmkoIHXBYaw=.a16af024-f505-4345-ab95-39098a51dbae@github.com>

On Thu, 1 Jun 2023 14:45:16 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> The ShenandoahHeap print_heap_regions_on method prints some brief description of the columns of the heap table, however the description is unsorted and seems to be not fully up to date.
> 
> Another thought - is the critical pins column (CP=critical pins)  still needed or always 0  and obsolete now?

This pull request has now been integrated.

Changeset: 9233dcc8
Author:    Matthias Baesken <mbaesken at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/9233dcc8380c6e7cd7bbf7a1f4c0a6873429ea53
Stats:     10 lines in 2 files changed: 5 ins; 0 del; 5 mod

8309297: Adjust ShenandoahHeap print_heap_regions_on

Reviewed-by: ysr, mdoerr

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

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

From ayang at openjdk.org  Wed Jun  7 11:10:02 2023
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Wed, 7 Jun 2023 11:10:02 GMT
Subject: RFR: 8309403: Serial: Remove the useless adaptive size policy in
 GenCollectedHeap
In-Reply-To: <wKX4XIMNXhFrnCaqyuYX2wKKf_r2U5f1T5E7gab3WEs=.224bd13f-6807-4186-b5d3-f4e60ca9871e@github.com>
References: <AgndfVJuqHKLBUtf3Q8srBUH_BnNnXmxnvTz1rNXuRU=.36ab3363-d8b4-4fe3-b7e5-83f92af37d06@github.com>
 <th101U_7ZJ0PzJyxkX3r63Fz6ENOjPJXxysCYV7CBWE=.6a2e1dc4-69c7-4575-be92-5f24c7fb0e56@github.com>
 <Ti2vvexSpP3ykFTJLmjxLo_vKSCkP4dTcjlnz-BSW98=.b4ed2aee-66bf-486d-af6b-2312a1f11426@github.com>
 <KSB6PPU4LCJ9NxmcBFmHbSXIAzmrn4v1Lg23J9Xef5k=.394bc572-d477-4fa7-8176-249600809fb6@github.com>
 <wKX4XIMNXhFrnCaqyuYX2wKKf_r2U5f1T5E7gab3WEs=.224bd13f-6807-4186-b5d3-f4e60ca9871e@github.com>
Message-ID: <ohSEjm03ZQXDl4grIKfntWdOxMkUk6nihsxebR3bSYc=.740ff53f-3228-4a52-9a53-f6314de402d3@github.com>

On Tue, 6 Jun 2023 16:23:36 GMT, Guoxiong Li <gli at openjdk.org> wrote:

> why do we set it to false again

`WB_FullGC` should restore the global env. Otherwise, the following non-whitebox-full-gc cycles can unnecessarily clear soft-refs.

> If we have a reason to set it to false again, why do other GCs not set it

G1 does that inside `WB_FullGC`. ZGC doesn't rely on `SoftRefPolicy::should_clear_all_soft_refs`. Parallel doesn't clear the flag, which I believe is a bug.

This inconsistency is probably accidental; keeping the global env intact (essentially what ZGC does) seems the cleanest approach IMO. I wonder if other collectors can also adopt it; in another PR(s) ofc.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14296#discussion_r1221397084

From azafari at openjdk.org  Wed Jun  7 11:29:06 2023
From: azafari at openjdk.org (Afshin Zafari)
Date: Wed, 7 Jun 2023 11:29:06 GMT
Subject: RFR: 8281455: Change JVM options with small ranges from 64 to 32
 bits, for gc_globals.hpp [v2]
In-Reply-To: <PUZ-VNLsAs748dp0p0fknfkp6VxzSZRvBXp3cJvheko=.101c475e-a097-47ee-8ead-3464def85d7a@github.com>
References: <PUZ-VNLsAs748dp0p0fknfkp6VxzSZRvBXp3cJvheko=.101c475e-a097-47ee-8ead-3464def85d7a@github.com>
Message-ID: <XMUVdBeWfiSjnXl3nWjC0Ew01rxKBb_dCV7f8EFtdwE=.4d42e4d6-ea04-46a2-9019-cf895c271290@github.com>

> The `uintx/intx` options whose ranges are small enough are changed to `uint/int`, otherwise gcc complains 
> when `-Wconversion` is used in build.
> Their uses in printf formats are changed accordingly.
> 
> ### Tests
> Locally hotspot:tier1 tested on linux-x64
> mach5 tiers 1-4 on Linux and Windows 64bits platforms passed.

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

  some more intx to int conversions.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14259/files
  - new: https://git.openjdk.org/jdk/pull/14259/files/9a489ae5..b0b1501c

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

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

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

From azafari at openjdk.org  Wed Jun  7 11:36:56 2023
From: azafari at openjdk.org (Afshin Zafari)
Date: Wed, 7 Jun 2023 11:36:56 GMT
Subject: RFR: 8281455: Change JVM options with small ranges from 64 to 32
 bits, for gc_globals.hpp [v2]
In-Reply-To: <XMUVdBeWfiSjnXl3nWjC0Ew01rxKBb_dCV7f8EFtdwE=.4d42e4d6-ea04-46a2-9019-cf895c271290@github.com>
References: <PUZ-VNLsAs748dp0p0fknfkp6VxzSZRvBXp3cJvheko=.101c475e-a097-47ee-8ead-3464def85d7a@github.com>
 <XMUVdBeWfiSjnXl3nWjC0Ew01rxKBb_dCV7f8EFtdwE=.4d42e4d6-ea04-46a2-9019-cf895c271290@github.com>
Message-ID: <sFa55o0uFvnL9TWKBcd9ZnXB8oR9VPNqlfx59PEveZg=.6ff01e44-0c87-458c-817b-6fd3ce970f4b@github.com>

On Wed, 7 Jun 2023 11:29:06 GMT, Afshin Zafari <azafari at openjdk.org> wrote:

>> The `uintx/intx` options whose ranges are small enough are changed to `uint/int`, otherwise gcc complains 
>> when `-Wconversion` is used in build.
>> Their uses in printf formats are changed accordingly.
>> 
>> ### Tests
>> Locally hotspot:tier1 tested on linux-x64
>> mach5 tiers 1-4 on Linux and Windows 64bits platforms passed.
>
> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:
> 
>   some more intx to int conversions.

Suggested changes in Comments are applied including the 'more candidates'.

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

PR Review: https://git.openjdk.org/jdk/pull/14259#pullrequestreview-1467411665

From azafari at openjdk.org  Wed Jun  7 11:37:02 2023
From: azafari at openjdk.org (Afshin Zafari)
Date: Wed, 7 Jun 2023 11:37:02 GMT
Subject: RFR: 8281455: Change JVM options with small ranges from 64 to 32
 bits, for gc_globals.hpp [v2]
In-Reply-To: <mma3GllWVHmYEY9J6GgTztWk6ma5xtFkiK8-YAf9i2w=.c042d1a1-3df5-4a1e-affa-2ca8296794a7@github.com>
References: <PUZ-VNLsAs748dp0p0fknfkp6VxzSZRvBXp3cJvheko=.101c475e-a097-47ee-8ead-3464def85d7a@github.com>
 <mma3GllWVHmYEY9J6GgTztWk6ma5xtFkiK8-YAf9i2w=.c042d1a1-3df5-4a1e-affa-2ca8296794a7@github.com>
Message-ID: <8gYnDzQfabS7tXY4QoPhdBryFYLovq3BBebT-DMwy2g=.655bcd7c-7a5d-4e23-8243-dd2dd0069b30@github.com>

On Wed, 7 Jun 2023 09:30:46 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   some more intx to int conversions.
>
> src/hotspot/share/gc/parallel/psAdaptiveSizePolicy.cpp line 352:
> 
>> 350:           "PSAdaptiveSizePolicy::compute_eden_space_size: gc time limit"
>> 351:           " gc_cost: %f "
>> 352:           " GCTimeLimit: " UINT32_FORMAT,
> 
> We use `%u` as format specifiers for uint.

`%u` is used.

> src/hotspot/share/gc/shared/gcOverheadChecker.cpp line 94:
> 
>> 92:   if (UseGCOverheadLimit) {
>> 93:     if (gc_overhead_limit_exceeded()) {
>> 94:       log_trace(gc, ergo)("GC is exceeding overhead limit of %d%%", GCTimeLimit);
> 
> Not sure why this place uses `%d` as format specifier compared to the `UINT32_FORMAT` the previous places did. Use `%u` ;)

`%u` is used.

> src/hotspot/share/gc/shared/gc_globals.hpp line 169:
> 
>> 167:           "(effective only when using concurrent collectors)")              \
>> 168:                                                                             \
>> 169:   product(uint, GCLockerEdenExpansionPercent, 5,                           \
> 
> The `` needs to be aligned back.

Fixed.

> src/hotspot/share/utilities/globalDefinitions.hpp line 442:
> 
>> 440: 
>> 441: typedef unsigned int uint;   NEEDS_CLEANUP
>> 442: const uint  max_uint  = (uint)-1;
> 
> The change should use the existing `UINT_MAX` instead of adding a new constant. Instead of a cast of `-1`, one should also use `~0` to get all-ones.

`UINT_MAX` is used. New definition of max_uint is removed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14259#discussion_r1221420802
PR Review Comment: https://git.openjdk.org/jdk/pull/14259#discussion_r1221421539
PR Review Comment: https://git.openjdk.org/jdk/pull/14259#discussion_r1221421846
PR Review Comment: https://git.openjdk.org/jdk/pull/14259#discussion_r1221423013

From gli at openjdk.org  Wed Jun  7 11:44:05 2023
From: gli at openjdk.org (Guoxiong Li)
Date: Wed, 7 Jun 2023 11:44:05 GMT
Subject: RFR: 8309403: Serial: Remove the useless adaptive size policy in
 GenCollectedHeap
In-Reply-To: <ohSEjm03ZQXDl4grIKfntWdOxMkUk6nihsxebR3bSYc=.740ff53f-3228-4a52-9a53-f6314de402d3@github.com>
References: <AgndfVJuqHKLBUtf3Q8srBUH_BnNnXmxnvTz1rNXuRU=.36ab3363-d8b4-4fe3-b7e5-83f92af37d06@github.com>
 <th101U_7ZJ0PzJyxkX3r63Fz6ENOjPJXxysCYV7CBWE=.6a2e1dc4-69c7-4575-be92-5f24c7fb0e56@github.com>
 <Ti2vvexSpP3ykFTJLmjxLo_vKSCkP4dTcjlnz-BSW98=.b4ed2aee-66bf-486d-af6b-2312a1f11426@github.com>
 <KSB6PPU4LCJ9NxmcBFmHbSXIAzmrn4v1Lg23J9Xef5k=.394bc572-d477-4fa7-8176-249600809fb6@github.com>
 <wKX4XIMNXhFrnCaqyuYX2wKKf_r2U5f1T5E7gab3WEs=.224bd13f-6807-4186-b5d3-f4e60ca9871e@github.com>
 <ohSEjm03ZQXDl4grIKfntWdOxMkUk6nihsxebR3bSYc=.740ff53f-3228-4a52-9a53-f6314de402d3@github.com>
Message-ID: <F4KPh3ceb_3xjtnSVO_SeQ5HpWmoZGqPgd0NdhIYvpE=.8d6bd26e-7671-4ee3-b868-f67dd887ed23@github.com>

On Wed, 7 Jun 2023 11:06:53 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> > why do we set it to false again
> 
> `WB_FullGC` should restore the global env. Otherwise, the following non-whitebox-full-gc cycles can unnecessarily clear soft-refs.
>
> > If we have a reason to set it to false again, why do other GCs not set it
> 
> G1 does that inside `WB_FullGC`. ZGC doesn't rely on `SoftRefPolicy::should_clear_all_soft_refs`. Parallel doesn't clear the flag, which I believe is a bug.
> 
> This inconsistency is probably accidental; keeping the global env intact (essentially what ZGC does) seems the cleanest approach IMO. I wonder if other collectors can also adopt it; in another PR(s) ofc.

Thanks for your answers. I propose the following changes.

In this patch:
- Serial GC should use `SoftRefPolicy` instead of `SoftRefGenPolicy`, which is done in this patch now.
- Serial GC should restore the global env inside `WB_FullGC`, just like the G1. Because both of them don't implement overheap limit check now.
- Don't remove the class `SoftRefGenPolicy` because it will be used by Parallel GC in the future. 

In another patch:
- Rename `SoftRefGenPolicy` in order to avoid misunderstanding, such as `GCOverhearLimitSoftRefPolicy`.
- Use `SoftRefGenPolicy` (may be renamed at the first step) in Parallel GC.

What do you think?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14296#discussion_r1221437135

From ayang at openjdk.org  Wed Jun  7 11:49:59 2023
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Wed, 7 Jun 2023 11:49:59 GMT
Subject: RFR: 8272147: Consolidate preserved marks handling with other STW
 collectors [v2]
In-Reply-To: <S1Tl2UbKhmi1ijfWk28_a51CL3C5NIlIVVJng-iuopw=.72e339b0-4796-46fb-92a0-3e5e7ab44e17@github.com>
References: <jXZiOVJDgymUKJne7d-LXCpIx7xcPoFPGATHIGSw_HE=.cb5e5aa0-001c-4842-9c16-7cb70e41b8a2@github.com>
 <S1Tl2UbKhmi1ijfWk28_a51CL3C5NIlIVVJng-iuopw=.72e339b0-4796-46fb-92a0-3e5e7ab44e17@github.com>
Message-ID: <qSmf6lKQXi73Qv12B-OV6u9gPnKWdzj7j8vlIOIcH2U=.d7609778-ea7a-438b-a7af-18c6a48fe37e@github.com>

On Tue, 6 Jun 2023 17:02:32 GMT, Guoxiong Li <gli at openjdk.org> wrote:

>> Hi all,
>> 
>> This patch removes the class `markSweep.hpp::PreservedMark` and uses the shared `PreservedMarksSet` instead.
>> 
>> In order to keep the meaning of the field `_preserved_marks` in `markSweep`,
>> I need to use `OopAndMarkWord` explicitly. So I move `OopAndMarkWord` out of `PreservedMarks`.
>> 
>> Tests:
>> `hotspot:tier1` passed locally (x86 & linux).
>> 
>> Thanks for the review.
>> 
>> Best Regards,
>> -- Guoxiong
>
> Guoxiong Li 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:
> 
>  - Use the method 'adjust_during_full_gc' and polish the included header.
>  - Merge branch 'master' into JDK-8272147
>  - JDK-8272147

src/hotspot/share/gc/serial/markSweep.cpp line 156:

> 154:     _preserved_marks[_preserved_count++] = OopAndMarkWord(obj, mark);
> 155:   } else {
> 156:     _preserved_overflow_stack_set.get()->push_if_necessary(obj, mark);

Why not `push_always`? I'd expect this mark must be preserved.

src/hotspot/share/gc/serial/markSweep.cpp line 200:

> 198:   // adjust the oops we saved earlier
> 199:   for (size_t i = 0; i < _preserved_count; i++) {
> 200:     MarkSweep::adjust_pointer(_preserved_marks[i].get_oop_pointer());

There are still some unnecessary null-checks.

I wonder if one can add new API in `PreservedMarks` to adjust oops.


void adjust_preserved_mark(OopAndMarkWord* elem) {
  oop obj = elem->get_oop();
  if (obj->is_forwarded()) {
    elem->set_oop(obj->forwardee());
  }
}


Then `_preserved_marks[]` serves just as a buffer to the overflow array  -- how their contents are processed is decided at one place and outside Serial.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14274#discussion_r1221407347
PR Review Comment: https://git.openjdk.org/jdk/pull/14274#discussion_r1221410875

From gli at openjdk.org  Wed Jun  7 12:05:57 2023
From: gli at openjdk.org (Guoxiong Li)
Date: Wed, 7 Jun 2023 12:05:57 GMT
Subject: RFR: 8272147: Consolidate preserved marks handling with other STW
 collectors [v2]
In-Reply-To: <qSmf6lKQXi73Qv12B-OV6u9gPnKWdzj7j8vlIOIcH2U=.d7609778-ea7a-438b-a7af-18c6a48fe37e@github.com>
References: <jXZiOVJDgymUKJne7d-LXCpIx7xcPoFPGATHIGSw_HE=.cb5e5aa0-001c-4842-9c16-7cb70e41b8a2@github.com>
 <S1Tl2UbKhmi1ijfWk28_a51CL3C5NIlIVVJng-iuopw=.72e339b0-4796-46fb-92a0-3e5e7ab44e17@github.com>
 <qSmf6lKQXi73Qv12B-OV6u9gPnKWdzj7j8vlIOIcH2U=.d7609778-ea7a-438b-a7af-18c6a48fe37e@github.com>
Message-ID: <2t85WpaaXY3vNlDC31vRu7zwpvz8vYpqM5rdeXDsGvc=.5d06d4d7-b346-49aa-a0bd-56c2f6e26983@github.com>

On Wed, 7 Jun 2023 11:17:20 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Guoxiong Li 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:
>> 
>>  - Use the method 'adjust_during_full_gc' and polish the included header.
>>  - Merge branch 'master' into JDK-8272147
>>  - JDK-8272147
>
> src/hotspot/share/gc/serial/markSweep.cpp line 156:
> 
>> 154:     _preserved_marks[_preserved_count++] = OopAndMarkWord(obj, mark);
>> 155:   } else {
>> 156:     _preserved_overflow_stack_set.get()->push_if_necessary(obj, mark);
> 
> Why not `push_always`? I'd expect this mark must be preserved.

Will fix it later.

> I wonder if one can add new API in PreservedMarks to adjust oops.

Should I add it in this patch? And, if such method is added, the method `PreservedMarks::adjust_during_full_gc` can use it too.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14274#discussion_r1221465866
PR Review Comment: https://git.openjdk.org/jdk/pull/14274#discussion_r1221466102

From gli at openjdk.org  Wed Jun  7 12:45:46 2023
From: gli at openjdk.org (Guoxiong Li)
Date: Wed, 7 Jun 2023 12:45:46 GMT
Subject: RFR: 8272147: Consolidate preserved marks handling with other STW
 collectors [v3]
In-Reply-To: <jXZiOVJDgymUKJne7d-LXCpIx7xcPoFPGATHIGSw_HE=.cb5e5aa0-001c-4842-9c16-7cb70e41b8a2@github.com>
References: <jXZiOVJDgymUKJne7d-LXCpIx7xcPoFPGATHIGSw_HE=.cb5e5aa0-001c-4842-9c16-7cb70e41b8a2@github.com>
Message-ID: <PwUtVvKY_2bAErjE_hWfrRDxhPItmCM9bBqGIVtRtcc=.7d474135-71e7-4f5e-b694-5a78f8855150@github.com>

> Hi all,
> 
> This patch removes the class `markSweep.hpp::PreservedMark` and uses the shared `PreservedMarksSet` instead.
> 
> In order to keep the meaning of the field `_preserved_marks` in `markSweep`,
> I need to use `OopAndMarkWord` explicitly. So I move `OopAndMarkWord` out of `PreservedMarks`.
> 
> Tests:
> `hotspot:tier1` passed locally (x86 & linux).
> 
> Thanks for the review.
> 
> Best Regards,
> -- Guoxiong

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

  Use method 'push_always'.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14274/files
  - new: https://git.openjdk.org/jdk/pull/14274/files/bcf737c6..db8976fa

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

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

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

From gli at openjdk.org  Wed Jun  7 12:45:48 2023
From: gli at openjdk.org (Guoxiong Li)
Date: Wed, 7 Jun 2023 12:45:48 GMT
Subject: RFR: 8272147: Consolidate preserved marks handling with other STW
 collectors [v2]
In-Reply-To: <2t85WpaaXY3vNlDC31vRu7zwpvz8vYpqM5rdeXDsGvc=.5d06d4d7-b346-49aa-a0bd-56c2f6e26983@github.com>
References: <jXZiOVJDgymUKJne7d-LXCpIx7xcPoFPGATHIGSw_HE=.cb5e5aa0-001c-4842-9c16-7cb70e41b8a2@github.com>
 <S1Tl2UbKhmi1ijfWk28_a51CL3C5NIlIVVJng-iuopw=.72e339b0-4796-46fb-92a0-3e5e7ab44e17@github.com>
 <qSmf6lKQXi73Qv12B-OV6u9gPnKWdzj7j8vlIOIcH2U=.d7609778-ea7a-438b-a7af-18c6a48fe37e@github.com>
 <2t85WpaaXY3vNlDC31vRu7zwpvz8vYpqM5rdeXDsGvc=.5d06d4d7-b346-49aa-a0bd-56c2f6e26983@github.com>
Message-ID: <aNVDoWkgU2cDtvteZH8bEr_oz3nPMfDFoyR4BdzY7_g=.0125859f-8e82-436f-ac02-d321b8e750e0@github.com>

On Wed, 7 Jun 2023 12:03:17 GMT, Guoxiong Li <gli at openjdk.org> wrote:

>> src/hotspot/share/gc/serial/markSweep.cpp line 156:
>> 
>>> 154:     _preserved_marks[_preserved_count++] = OopAndMarkWord(obj, mark);
>>> 155:   } else {
>>> 156:     _preserved_overflow_stack_set.get()->push_if_necessary(obj, mark);
>> 
>> Why not `push_always`? I'd expect this mark must be preserved.
>
> Will fix it later.

Fixed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14274#discussion_r1221522240

From ayang at openjdk.org  Wed Jun  7 13:42:58 2023
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Wed, 7 Jun 2023 13:42:58 GMT
Subject: RFR: 8272147: Consolidate preserved marks handling with other STW
 collectors [v2]
In-Reply-To: <2t85WpaaXY3vNlDC31vRu7zwpvz8vYpqM5rdeXDsGvc=.5d06d4d7-b346-49aa-a0bd-56c2f6e26983@github.com>
References: <jXZiOVJDgymUKJne7d-LXCpIx7xcPoFPGATHIGSw_HE=.cb5e5aa0-001c-4842-9c16-7cb70e41b8a2@github.com>
 <S1Tl2UbKhmi1ijfWk28_a51CL3C5NIlIVVJng-iuopw=.72e339b0-4796-46fb-92a0-3e5e7ab44e17@github.com>
 <qSmf6lKQXi73Qv12B-OV6u9gPnKWdzj7j8vlIOIcH2U=.d7609778-ea7a-438b-a7af-18c6a48fe37e@github.com>
 <2t85WpaaXY3vNlDC31vRu7zwpvz8vYpqM5rdeXDsGvc=.5d06d4d7-b346-49aa-a0bd-56c2f6e26983@github.com>
Message-ID: <qF6V2xxKj8JCEvZJXr0_PiazfqDbTyo5FZwTPGKOUTU=.f8fb8e00-c7a6-422d-995b-26d2da78ebbf@github.com>

On Wed, 7 Jun 2023 12:03:31 GMT, Guoxiong Li <gli at openjdk.org> wrote:

>> src/hotspot/share/gc/serial/markSweep.cpp line 200:
>> 
>>> 198:   // adjust the oops we saved earlier
>>> 199:   for (size_t i = 0; i < _preserved_count; i++) {
>>> 200:     MarkSweep::adjust_pointer(_preserved_marks[i].get_oop_pointer());
>> 
>> There are still some unnecessary null-checks.
>> 
>> I wonder if one can add new API in `PreservedMarks` to adjust oops.
>> 
>> 
>> void adjust_preserved_mark(OopAndMarkWord* elem) {
>>   oop obj = elem->get_oop();
>>   if (obj->is_forwarded()) {
>>     elem->set_oop(obj->forwardee());
>>   }
>> }
>> 
>> 
>> Then `_preserved_marks[]` serves just as a buffer to the overflow array  -- how their contents are processed is decided at one place and outside Serial.
>
>> I wonder if one can add new API in PreservedMarks to adjust oops.
> 
> Should I add it in this patch? And, if such method is added, the method `PreservedMarks::adjust_during_full_gc` can use it too.

Yes, please.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14274#discussion_r1221623001

From ayang at openjdk.org  Wed Jun  7 13:44:06 2023
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Wed, 7 Jun 2023 13:44:06 GMT
Subject: RFR: 8309403: Serial: Remove the useless adaptive size policy in
 GenCollectedHeap
In-Reply-To: <F4KPh3ceb_3xjtnSVO_SeQ5HpWmoZGqPgd0NdhIYvpE=.8d6bd26e-7671-4ee3-b868-f67dd887ed23@github.com>
References: <AgndfVJuqHKLBUtf3Q8srBUH_BnNnXmxnvTz1rNXuRU=.36ab3363-d8b4-4fe3-b7e5-83f92af37d06@github.com>
 <th101U_7ZJ0PzJyxkX3r63Fz6ENOjPJXxysCYV7CBWE=.6a2e1dc4-69c7-4575-be92-5f24c7fb0e56@github.com>
 <Ti2vvexSpP3ykFTJLmjxLo_vKSCkP4dTcjlnz-BSW98=.b4ed2aee-66bf-486d-af6b-2312a1f11426@github.com>
 <KSB6PPU4LCJ9NxmcBFmHbSXIAzmrn4v1Lg23J9Xef5k=.394bc572-d477-4fa7-8176-249600809fb6@github.com>
 <wKX4XIMNXhFrnCaqyuYX2wKKf_r2U5f1T5E7gab3WEs=.224bd13f-6807-4186-b5d3-f4e60ca9871e@github.com>
 <ohSEjm03ZQXDl4grIKfntWdOxMkUk6nihsxebR3bSYc=.740ff53f-3228-4a52-9a53-f6314de402d3@github.com>
 <F4KPh3ceb_3xjtnSVO_SeQ5HpWmoZGqPgd0NdhIYvpE=.8d6bd26e-7671-4ee3-b868-f67dd887ed23@github.com>
Message-ID: <J1qi51EZVAqw5RvK6N0gD9J2gG4cGGUoYb8HooU2Bjo=.541c8782-9005-4c29-8f6f-a8ba8245473f@github.com>

On Wed, 7 Jun 2023 11:39:55 GMT, Guoxiong Li <gli at openjdk.org> wrote:

> Don't remove the class SoftRefGenPolicy because it will be used by Parallel GC in the future.

I am not sure that using `SoftRefGenPolicy` is the cleanest way to solve the issue in Parallel. Can we check gc-overhead (and other relevant metrics) at gc-pause-start to decide soft-ref-policy, instead of relying on the global bool? (IOW, can GC make the more active decidion, in contrast to letting others tell GC what to do regarding to soft-refs?)

The approach in `should_clear_soft_references` of `zDriver` seems less intrusive to the global env.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14296#discussion_r1221624327

From duke at openjdk.org  Wed Jun  7 14:25:58 2023
From: duke at openjdk.org (Ashutosh Mehra)
Date: Wed, 7 Jun 2023 14:25:58 GMT
Subject: RFR: 8309065: Move the logic to determine archive heap location
 from CDS to G1 GC [v3]
In-Reply-To: <M4Q8tx5azU88N1zScslx6oZjxQQPRFs0Ao2hfW41-iI=.9bdff767-e0ed-498c-8f6d-52b882649436@github.com>
References: <Jy8pV1WnLW6fMktk9Jmx5SF4JDWL8fl1zPNKOpV6FpA=.324de220-9ad8-4316-b871-c2b7dea5e6d2@github.com>
 <XATqoeHqYdc-FRfVKQqlJP8bsUXN7R9MqueuHQ0HGaQ=.ce7e8c50-c8d1-480e-83d7-c56a13d748a8@github.com>
 <M4Q8tx5azU88N1zScslx6oZjxQQPRFs0Ao2hfW41-iI=.9bdff767-e0ed-498c-8f6d-52b882649436@github.com>
Message-ID: <znGoIEeXlITggzpACZOks8seQsdEB_PhzrUMRQFzG3U=.f61c9073-9d3e-47f0-a3bd-13bb94e0fb41@github.com>

On Wed, 7 Jun 2023 09:20:17 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> we map the archive region at the end of the heap, therefore, if heap size changed between dump time and runtime, we will always have to relocate

Not always. For small heap sizes under 2G with compressedoops the heap is mapped such that top of the heap is at 4G boundary. So by keeping the archive regions towards the end, we can get same offset even if the heap size changes. If we map towards the bottom, then the offsets would change as the heap size changes.

For example, the default archive is created with 128m. So executing:

$ java -Xlog:cds -Xmx128m -version
[0.003s][info][cds] The current max heap size = 128M, HeapRegion::GrainBytes = 1048576
[0.003s][info][cds]     narrow_klass_base = 0x0000000800000000, narrow_klass_shift = 0
[0.003s][info][cds]     narrow_oop_mode = 0, narrow_oop_base = 0x0000000000000000, narrow_oop_shift = 0
[0.003s][info][cds]     heap range = [0x00000000f8000000 - 0x0000000100000000]
[0.003s][info][cds] Preferred address to map heap data (to avoid relocation) is 0x00000000ffe00000
[0.003s][info][cds] Heap data mapped at 0x00000000ffe00000, size =  1071752 bytes
[0.003s][info][cds] CDS heap data relocation delta = 0 bytes


Changing the heap size to 256m:

$ java -Xlog:cds -Xmx256m -version
[0.003s][info][cds] The current max heap size = 256M, HeapRegion::GrainBytes = 1048576
[0.003s][info][cds]     narrow_klass_base = 0x0000000800000000, narrow_klass_shift = 0
[0.003s][info][cds]     narrow_oop_mode = 0, narrow_oop_base = 0x0000000000000000, narrow_oop_shift = 0
[0.003s][info][cds]     heap range = [0x00000000f0000000 - 0x0000000100000000]
[0.003s][info][cds] Preferred address to map heap data (to avoid relocation) is 0x00000000ffe00000
[0.003s][info][cds] Heap data mapped at 0x00000000ffe00000, size =  1071752 bytes
[0.003s][info][cds] CDS heap data relocation delta = 0 bytes


Notice that relocation delta is 0 in both cases and the heap data is mapped at same address.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14208#discussion_r1221694835

From duke at openjdk.org  Wed Jun  7 14:33:03 2023
From: duke at openjdk.org (Ashutosh Mehra)
Date: Wed, 7 Jun 2023 14:33:03 GMT
Subject: RFR: 8309065: Move the logic to determine archive heap location
 from CDS to G1 GC [v3]
In-Reply-To: <M4Q8tx5azU88N1zScslx6oZjxQQPRFs0Ao2hfW41-iI=.9bdff767-e0ed-498c-8f6d-52b882649436@github.com>
References: <Jy8pV1WnLW6fMktk9Jmx5SF4JDWL8fl1zPNKOpV6FpA=.324de220-9ad8-4316-b871-c2b7dea5e6d2@github.com>
 <XATqoeHqYdc-FRfVKQqlJP8bsUXN7R9MqueuHQ0HGaQ=.ce7e8c50-c8d1-480e-83d7-c56a13d748a8@github.com>
 <M4Q8tx5azU88N1zScslx6oZjxQQPRFs0Ao2hfW41-iI=.9bdff767-e0ed-498c-8f6d-52b882649436@github.com>
Message-ID: <KhcpHRjgMs0a6x49K2WGG4GE4AUV-kcb8lljvbfk9I4=.112cd628-3a31-46bf-93e1-545ce5a448c9@github.com>

On Wed, 7 Jun 2023 09:05:24 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Ashutosh Mehra has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review comments - updates to alloc_archive_regions() api
>>   
>>   Signed-off-by: Ashutosh Mehra <asmehra at redhat.com>
>
> src/hotspot/share/cds/filemap.cpp line 2124:
> 
>> 2122: 
>> 2123:   size_t word_size = size / HeapWordSize;
>> 2124:   address requested_start = heap_region_requested_address();
> 
> Possibly for another RFE, if you intent to make this code move as verbatim as possible:
> 
> This feels like something that should use `r->mapping_offset()` directly - would make the code easier to understand.

Not sure I get this. Are you suggesting replacing `heap_region_requested_address` with `r->mapping_offset()`. But they are not the same, right?

> Could we add this limitation to the comment for the casual reader?

Yes, good point. I will update the comment to add this limitation.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14208#discussion_r1221704233
PR Review Comment: https://git.openjdk.org/jdk/pull/14208#discussion_r1221705900

From stuefe at openjdk.org  Wed Jun  7 14:33:05 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Wed, 7 Jun 2023 14:33:05 GMT
Subject: RFR: 8309065: Move the logic to determine archive heap location
 from CDS to G1 GC [v3]
In-Reply-To: <znGoIEeXlITggzpACZOks8seQsdEB_PhzrUMRQFzG3U=.f61c9073-9d3e-47f0-a3bd-13bb94e0fb41@github.com>
References: <Jy8pV1WnLW6fMktk9Jmx5SF4JDWL8fl1zPNKOpV6FpA=.324de220-9ad8-4316-b871-c2b7dea5e6d2@github.com>
 <XATqoeHqYdc-FRfVKQqlJP8bsUXN7R9MqueuHQ0HGaQ=.ce7e8c50-c8d1-480e-83d7-c56a13d748a8@github.com>
 <M4Q8tx5azU88N1zScslx6oZjxQQPRFs0Ao2hfW41-iI=.9bdff767-e0ed-498c-8f6d-52b882649436@github.com>
 <znGoIEeXlITggzpACZOks8seQsdEB_PhzrUMRQFzG3U=.f61c9073-9d3e-47f0-a3bd-13bb94e0fb41@github.com>
Message-ID: <G_rlFI8eUL1uwWszwBsvGMBTXjeO-WiJEBGngEIJacw=.f815a59f-ffe8-4762-9885-418890e5293a@github.com>

On Wed, 7 Jun 2023 14:23:20 GMT, Ashutosh Mehra <duke at openjdk.org> wrote:

>> src/hotspot/share/gc/g1/g1CollectedHeap.cpp line 551:
>> 
>>> 549:   HeapWord* start_addr = reserved.end() - align_up(word_size, HeapRegion::GrainWords);
>>> 550:   MemRegion range = MemRegion(start_addr, word_size);
>>> 551:   HeapWord* last_address = range.last();
>> 
>> Do I understand this - and the old code - correctly: we map the archive region at the end of the heap, therefore, if heap size changed between dump time and runtime, we will always have to relocate? I didn't look but I assume the dumptime heap size is the default heap size?
>> 
>> Another, possibly stupid, question: why don't we use the Heap bottom - we'd still avoid fragmentation but have a much higher chance of not relocating?
>
>> we map the archive region at the end of the heap, therefore, if heap size changed between dump time and runtime, we will always have to relocate
> 
> Not always. For small heap sizes under 2G with compressedoops the heap is mapped such that top of the heap is at 4G boundary. So by keeping the archive regions towards the end, we can get same offset even if the heap size changes. If we map towards the bottom, then the offsets would change as the heap size changes.
> 
> For example, the default archive is created with 128m. So executing:
> 
> $ java -Xlog:cds -Xmx128m -version
> [0.003s][info][cds] The current max heap size = 128M, HeapRegion::GrainBytes = 1048576
> [0.003s][info][cds]     narrow_klass_base = 0x0000000800000000, narrow_klass_shift = 0
> [0.003s][info][cds]     narrow_oop_mode = 0, narrow_oop_base = 0x0000000000000000, narrow_oop_shift = 0
> [0.003s][info][cds]     heap range = [0x00000000f8000000 - 0x0000000100000000]
> [0.003s][info][cds] Preferred address to map heap data (to avoid relocation) is 0x00000000ffe00000
> [0.003s][info][cds] Heap data mapped at 0x00000000ffe00000, size =  1071752 bytes
> [0.003s][info][cds] CDS heap data relocation delta = 0 bytes
> 
> 
> Changing the heap size to 256m:
> 
> $ java -Xlog:cds -Xmx256m -version
> [0.003s][info][cds] The current max heap size = 256M, HeapRegion::GrainBytes = 1048576
> [0.003s][info][cds]     narrow_klass_base = 0x0000000800000000, narrow_klass_shift = 0
> [0.003s][info][cds]     narrow_oop_mode = 0, narrow_oop_base = 0x0000000000000000, narrow_oop_shift = 0
> [0.003s][info][cds]     heap range = [0x00000000f0000000 - 0x0000000100000000]
> [0.003s][info][cds] Preferred address to map heap data (to avoid relocation) is 0x00000000ffe00000
> [0.003s][info][cds] Heap data mapped at 0x00000000ffe00000, size =  1071752 bytes
> [0.003s][info][cds] CDS heap data relocation delta = 0 bytes
> 
> 
> Notice that relocation delta is 0 in both cases and the heap data is mapped at same address.

@ashu-mehra Ah, thank you. I remembered this wrongly as the heap having a preferred fixed start address when the fix point was actually the end of the zero-based encoding range.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14208#discussion_r1221704559

From duke at openjdk.org  Wed Jun  7 14:33:06 2023
From: duke at openjdk.org (Ashutosh Mehra)
Date: Wed, 7 Jun 2023 14:33:06 GMT
Subject: RFR: 8309065: Move the logic to determine archive heap location
 from CDS to G1 GC [v3]
In-Reply-To: <G_rlFI8eUL1uwWszwBsvGMBTXjeO-WiJEBGngEIJacw=.f815a59f-ffe8-4762-9885-418890e5293a@github.com>
References: <Jy8pV1WnLW6fMktk9Jmx5SF4JDWL8fl1zPNKOpV6FpA=.324de220-9ad8-4316-b871-c2b7dea5e6d2@github.com>
 <XATqoeHqYdc-FRfVKQqlJP8bsUXN7R9MqueuHQ0HGaQ=.ce7e8c50-c8d1-480e-83d7-c56a13d748a8@github.com>
 <M4Q8tx5azU88N1zScslx6oZjxQQPRFs0Ao2hfW41-iI=.9bdff767-e0ed-498c-8f6d-52b882649436@github.com>
 <znGoIEeXlITggzpACZOks8seQsdEB_PhzrUMRQFzG3U=.f61c9073-9d3e-47f0-a3bd-13bb94e0fb41@github.com>
 <G_rlFI8eUL1uwWszwBsvGMBTXjeO-WiJEBGngEIJacw=.f815a59f-ffe8-4762-9885-418890e5293a@github.com>
Message-ID: <_8f8oqpdYT56hxKf3MfApsT658ARTF0jXIMnP3UQo7E=.4936b832-9b5f-4853-be3d-c21daa3720c6@github.com>

On Wed, 7 Jun 2023 14:29:07 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>>> we map the archive region at the end of the heap, therefore, if heap size changed between dump time and runtime, we will always have to relocate
>> 
>> Not always. For small heap sizes under 2G with compressedoops the heap is mapped such that top of the heap is at 4G boundary. So by keeping the archive regions towards the end, we can get same offset even if the heap size changes. If we map towards the bottom, then the offsets would change as the heap size changes.
>> 
>> For example, the default archive is created with 128m. So executing:
>> 
>> $ java -Xlog:cds -Xmx128m -version
>> [0.003s][info][cds] The current max heap size = 128M, HeapRegion::GrainBytes = 1048576
>> [0.003s][info][cds]     narrow_klass_base = 0x0000000800000000, narrow_klass_shift = 0
>> [0.003s][info][cds]     narrow_oop_mode = 0, narrow_oop_base = 0x0000000000000000, narrow_oop_shift = 0
>> [0.003s][info][cds]     heap range = [0x00000000f8000000 - 0x0000000100000000]
>> [0.003s][info][cds] Preferred address to map heap data (to avoid relocation) is 0x00000000ffe00000
>> [0.003s][info][cds] Heap data mapped at 0x00000000ffe00000, size =  1071752 bytes
>> [0.003s][info][cds] CDS heap data relocation delta = 0 bytes
>> 
>> 
>> Changing the heap size to 256m:
>> 
>> $ java -Xlog:cds -Xmx256m -version
>> [0.003s][info][cds] The current max heap size = 256M, HeapRegion::GrainBytes = 1048576
>> [0.003s][info][cds]     narrow_klass_base = 0x0000000800000000, narrow_klass_shift = 0
>> [0.003s][info][cds]     narrow_oop_mode = 0, narrow_oop_base = 0x0000000000000000, narrow_oop_shift = 0
>> [0.003s][info][cds]     heap range = [0x00000000f0000000 - 0x0000000100000000]
>> [0.003s][info][cds] Preferred address to map heap data (to avoid relocation) is 0x00000000ffe00000
>> [0.003s][info][cds] Heap data mapped at 0x00000000ffe00000, size =  1071752 bytes
>> [0.003s][info][cds] CDS heap data relocation delta = 0 bytes
>> 
>> 
>> Notice that relocation delta is 0 in both cases and the heap data is mapped at same address.
>
> @ashu-mehra Ah, thank you. I remembered this wrongly as the heap having a preferred fixed start address when the fix point was actually the end of the zero-based encoding range.

> I didn't look but I assume the dumptime heap size is the default heap size?

I am wondering why do you think dumptime heap size is the default heap size?  When creating an archive the heap size can be anything. For default archive it is 128m.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14208#discussion_r1221706723

From stuefe at openjdk.org  Wed Jun  7 14:45:06 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Wed, 7 Jun 2023 14:45:06 GMT
Subject: RFR: 8309065: Move the logic to determine archive heap location
 from CDS to G1 GC [v3]
In-Reply-To: <KhcpHRjgMs0a6x49K2WGG4GE4AUV-kcb8lljvbfk9I4=.112cd628-3a31-46bf-93e1-545ce5a448c9@github.com>
References: <Jy8pV1WnLW6fMktk9Jmx5SF4JDWL8fl1zPNKOpV6FpA=.324de220-9ad8-4316-b871-c2b7dea5e6d2@github.com>
 <XATqoeHqYdc-FRfVKQqlJP8bsUXN7R9MqueuHQ0HGaQ=.ce7e8c50-c8d1-480e-83d7-c56a13d748a8@github.com>
 <M4Q8tx5azU88N1zScslx6oZjxQQPRFs0Ao2hfW41-iI=.9bdff767-e0ed-498c-8f6d-52b882649436@github.com>
 <KhcpHRjgMs0a6x49K2WGG4GE4AUV-kcb8lljvbfk9I4=.112cd628-3a31-46bf-93e1-545ce5a448c9@github.com>
Message-ID: <dYKDh2EFErWWh4KxigmUxT67ZT4YKHGxDdAkDb8KvkQ=.fc71913a-2ed6-4be7-8d41-fa67d6f60383@github.com>

On Wed, 7 Jun 2023 14:28:54 GMT, Ashutosh Mehra <duke at openjdk.org> wrote:

>> src/hotspot/share/cds/filemap.cpp line 2124:
>> 
>>> 2122: 
>>> 2123:   size_t word_size = size / HeapWordSize;
>>> 2124:   address requested_start = heap_region_requested_address();
>> 
>> Possibly for another RFE, if you intent to make this code move as verbatim as possible:
>> 
>> This feels like something that should use `r->mapping_offset()` directly - would make the code easier to understand.
>
> Not sure I get this. Are you suggesting replacing `heap_region_requested_address` with `r->mapping_offset()`. But they are not the same, right?

Never mind, it is not important at all. 

What I originally meant was: The requested address is calculated from information baked into the archive we are loading (original heap base and region offset), and we already have the archive in hand (`r`) and use it for subsequent operations, so we could calculate the requested address right here; but I was missing that heap_region_requested_address is called from several sites, so it makes sense to have this functionality in a utility function.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14208#discussion_r1221724217

From gli at openjdk.org  Wed Jun  7 15:05:54 2023
From: gli at openjdk.org (Guoxiong Li)
Date: Wed, 7 Jun 2023 15:05:54 GMT
Subject: RFR: 8309403: Serial: Remove the useless adaptive size policy in
 GenCollectedHeap [v2]
In-Reply-To: <AgndfVJuqHKLBUtf3Q8srBUH_BnNnXmxnvTz1rNXuRU=.36ab3363-d8b4-4fe3-b7e5-83f92af37d06@github.com>
References: <AgndfVJuqHKLBUtf3Q8srBUH_BnNnXmxnvTz1rNXuRU=.36ab3363-d8b4-4fe3-b7e5-83f92af37d06@github.com>
Message-ID: <9h4WaHdIT8rpM6Q-55zp8dlUM0bieeZFnjyp4B8Fz88=.364f2b27-a1b2-430f-9d00-27968d0f9f5b@github.com>

> Hi all,
> 
> This patch removes the useless code related to the `AdaptiveSizePolicy` in `GenCollectedHeap`.
> As a result, the `SoftRefGenPolicy` is unnecessary too, use `SoftRefPolicy` instead.
> 
> Thanks for the review.
> 
> Best Regards,
> -- Guoxiong

Guoxiong Li 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:

 - Restore the _should_clear_all_soft_refs in WB_FullGC.
 - Merge branch 'master' into JDK-8309403
 - JDK-8309403

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14296/files
  - new: https://git.openjdk.org/jdk/pull/14296/files/ba3c1066..1922cdfe

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

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

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

From gli at openjdk.org  Wed Jun  7 15:05:56 2023
From: gli at openjdk.org (Guoxiong Li)
Date: Wed, 7 Jun 2023 15:05:56 GMT
Subject: RFR: 8309403: Serial: Remove the useless adaptive size policy in
 GenCollectedHeap [v2]
In-Reply-To: <J1qi51EZVAqw5RvK6N0gD9J2gG4cGGUoYb8HooU2Bjo=.541c8782-9005-4c29-8f6f-a8ba8245473f@github.com>
References: <AgndfVJuqHKLBUtf3Q8srBUH_BnNnXmxnvTz1rNXuRU=.36ab3363-d8b4-4fe3-b7e5-83f92af37d06@github.com>
 <th101U_7ZJ0PzJyxkX3r63Fz6ENOjPJXxysCYV7CBWE=.6a2e1dc4-69c7-4575-be92-5f24c7fb0e56@github.com>
 <Ti2vvexSpP3ykFTJLmjxLo_vKSCkP4dTcjlnz-BSW98=.b4ed2aee-66bf-486d-af6b-2312a1f11426@github.com>
 <KSB6PPU4LCJ9NxmcBFmHbSXIAzmrn4v1Lg23J9Xef5k=.394bc572-d477-4fa7-8176-249600809fb6@github.com>
 <wKX4XIMNXhFrnCaqyuYX2wKKf_r2U5f1T5E7gab3WEs=.224bd13f-6807-4186-b5d3-f4e60ca9871e@github.com>
 <ohSEjm03ZQXDl4grIKfntWdOxMkUk6nihsxebR3bSYc=.740ff53f-3228-4a52-9a53-f6314de402d3@github.com>
 <F4KPh3ceb_3xjtnSVO_SeQ5HpWmoZGqPgd0NdhIYvpE=.8d6bd26e-7671-4ee3-b868-f67dd887ed23@github.com>
 <J1qi51EZVAqw5RvK6N0gD9J2gG4cGGUoYb8HooU2Bjo=.541c8782-9005-4c29-8f6f-a8ba8245473f@github.com>
Message-ID: <gsYwjCO7JKGpUClkunGrxw9izks_INAxBDZ-OpKBPQI=.cebebb7a-866e-4b20-b410-78add57adb1d@github.com>

On Wed, 7 Jun 2023 13:41:04 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>>> > why do we set it to false again
>>> 
>>> `WB_FullGC` should restore the global env. Otherwise, the following non-whitebox-full-gc cycles can unnecessarily clear soft-refs.
>>>
>>> > If we have a reason to set it to false again, why do other GCs not set it
>>> 
>>> G1 does that inside `WB_FullGC`. ZGC doesn't rely on `SoftRefPolicy::should_clear_all_soft_refs`. Parallel doesn't clear the flag, which I believe is a bug.
>>> 
>>> This inconsistency is probably accidental; keeping the global env intact (essentially what ZGC does) seems the cleanest approach IMO. I wonder if other collectors can also adopt it; in another PR(s) ofc.
>> 
>> Thanks for your answers. I propose the following changes.
>> 
>> In this patch:
>> - Serial GC should use `SoftRefPolicy` instead of `SoftRefGenPolicy`, which is done in this patch now.
>> - Serial GC should restore the global env inside `WB_FullGC`, just like the G1. Because both of them don't implement overheap limit check now.
>> - Don't remove the class `SoftRefGenPolicy` because it will be used by Parallel GC in the future. 
>> 
>> In another patch:
>> - Rename `SoftRefGenPolicy` in order to avoid misunderstanding, such as `GCOverhearLimitSoftRefPolicy`.
>> - Use `SoftRefGenPolicy` (may be renamed at the first step) in Parallel GC.
>> 
>> What do you think?
>
>> Don't remove the class SoftRefGenPolicy because it will be used by Parallel GC in the future.
> 
> I am not sure that using `SoftRefGenPolicy` is the cleanest way to solve the issue in Parallel. Can we check gc-overhead (and other relevant metrics) at gc-pause-start to decide soft-ref-policy, instead of relying on the global bool? (IOW, can GC make the more active decidion, in contrast to letting others tell GC what to do regarding to soft-refs?)
> 
> The approach in `should_clear_soft_references` of `zDriver` seems less intrusive to the global env.

I updated the code just now. I also restore the global env when using Parallel GC, because the Parallel GC doesn't have any implementation like `SoftRefGenPolicy` now (You can think that it solves a bug of Parallel GC).

> Can we check gc-overhead (and other relevant metrics) at gc-pause-start to decide soft-ref-policy, instead of relying on the global bool? (IOW, can GC make the more active decidion, in contrast to letting others tell GC what to do regarding to soft-refs?)
>
> The approach in should_clear_soft_references of zDriver seems less intrusive to the global env.

Seems a good idea. I will file new tickets to follow up. And I think the method `zDriver.cpp::should_clear_soft_references` can be moved into a subclass of `SoftRefPolicy` in order to reuse the code and names, because the `ZCollectedHeap` has the field `SoftRefPolicy  _soft_ref_policy` which is never used. But the detail info should be discussed in its issue.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14296#discussion_r1221750812

From kbarrett at openjdk.org  Wed Jun  7 15:36:02 2023
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 7 Jun 2023 15:36:02 GMT
Subject: RFR: 8281455: Change JVM options with small ranges from 64 to 32
 bits, for gc_globals.hpp [v2]
In-Reply-To: <XMUVdBeWfiSjnXl3nWjC0Ew01rxKBb_dCV7f8EFtdwE=.4d42e4d6-ea04-46a2-9019-cf895c271290@github.com>
References: <PUZ-VNLsAs748dp0p0fknfkp6VxzSZRvBXp3cJvheko=.101c475e-a097-47ee-8ead-3464def85d7a@github.com>
 <XMUVdBeWfiSjnXl3nWjC0Ew01rxKBb_dCV7f8EFtdwE=.4d42e4d6-ea04-46a2-9019-cf895c271290@github.com>
Message-ID: <3a8VoARzDFgwD-natDR0B_iOvJcR8zYOEDqUKvaaxoU=.84724654-db08-4b49-957a-d562e94e5e44@github.com>

On Wed, 7 Jun 2023 11:29:06 GMT, Afshin Zafari <azafari at openjdk.org> wrote:

>> The `uintx/intx` options whose ranges are small enough are changed to `uint/int`, otherwise gcc complains 
>> when `-Wconversion` is used in build.
>> Their uses in printf formats are changed accordingly.
>> 
>> ### Tests
>> Locally hotspot:tier1 tested on linux-x64
>> mach5 tiers 1-4 on Linux and Windows 64bits platforms passed.
>
> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:
> 
>   some more intx to int conversions.

Changes requested by kbarrett (Reviewer).

src/hotspot/share/gc/g1/g1Arguments.cpp line 232:

> 230:   // By default do not let the target stack size to be more than 1/4 of the entries
> 231:   if (FLAG_IS_DEFAULT(GCDrainStackTargetSize)) {
> 232:     FLAG_SET_ERGO(GCDrainStackTargetSize, MIN2(GCDrainStackTargetSize, (uint)TASKQUEUE_SIZE / 4));

TASKQUEUE_SIZE should be a constant of type size_t rather than a macro.  GCDrainStackTargetSize should be of type size_t.  Then we don't need any casts here.  But some uses may need cleaning up, either to remove casts or to adjust surrounding types.  I suggest this be split out as a separate RFE to avoid cluttering the simplicity of this PR.

src/hotspot/share/gc/parallel/jvmFlagConstraintsParallel.cpp line 50:

> 48:       JVMFlag::printError(verbose,
> 49:                           "InitialTenuringThreshold (" UINTX_FORMAT ") must be "
> 50:                           "less than or equal to MaxTenuringThreshold (%u)\n",

(github UI won't let me attach comment to the function signature)
The type of the value parameter should be changed in conjunction with the type change for the option,
both here and in jvmFlagConstraintsParallel.hpp.  Similarly for MaxTenuringThresholdXXX below.

src/hotspot/share/gc/parallel/psScavenge.cpp line 556:

> 554:                                                            survivor_limit);
> 555: 
> 556:        log_debug(gc, age)("Desired survivor size " SIZE_FORMAT " bytes, new threshold %u (max threshold %u)",

Consider also, instead of SIZE_FORMAT we can use "%zu".

src/hotspot/share/gc/shared/ageTable.cpp line 102:

> 100: 
> 101: 
> 102:   log_debug(gc, age)("Desired survivor size " SIZE_FORMAT " bytes, new threshold " UINTX_FORMAT " (max threshold %u)",

Consider also, instead of SIZE_FORMAT we can use "%zu".

src/hotspot/share/utilities/globalDefinitions.hpp line 434:

> 432: const uintx max_uintx = (uintx)-1;
> 433: 
> 434: 

stray blank line insertion?

src/hotspot/share/utilities/globalDefinitions.hpp line 441:

> 439: // max_uintx            0xFFFFFFFF      0xFFFFFFFFFFFFFFFF
> 440: 
> 441: typedef unsigned int uint;   NEEDS_CLEANUP

Unrelated, but I wonder why this "NEEDS_CLEANUP"?

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

PR Review: https://git.openjdk.org/jdk/pull/14259#pullrequestreview-1467936042
PR Review Comment: https://git.openjdk.org/jdk/pull/14259#discussion_r1221761557
PR Review Comment: https://git.openjdk.org/jdk/pull/14259#discussion_r1221770271
PR Review Comment: https://git.openjdk.org/jdk/pull/14259#discussion_r1221773761
PR Review Comment: https://git.openjdk.org/jdk/pull/14259#discussion_r1221774494
PR Review Comment: https://git.openjdk.org/jdk/pull/14259#discussion_r1221778201
PR Review Comment: https://git.openjdk.org/jdk/pull/14259#discussion_r1221779001

From kbarrett at openjdk.org  Wed Jun  7 15:38:56 2023
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 7 Jun 2023 15:38:56 GMT
Subject: RFR: 8281455: Change JVM options with small ranges from 64 to 32
 bits, for gc_globals.hpp [v2]
In-Reply-To: <XMUVdBeWfiSjnXl3nWjC0Ew01rxKBb_dCV7f8EFtdwE=.4d42e4d6-ea04-46a2-9019-cf895c271290@github.com>
References: <PUZ-VNLsAs748dp0p0fknfkp6VxzSZRvBXp3cJvheko=.101c475e-a097-47ee-8ead-3464def85d7a@github.com>
 <XMUVdBeWfiSjnXl3nWjC0Ew01rxKBb_dCV7f8EFtdwE=.4d42e4d6-ea04-46a2-9019-cf895c271290@github.com>
Message-ID: <lqB8iLQvOz8mpMo2103eL3NNQ_5jSfVg4Aq-Y-YicyU=.c9d3b7e4-bfc0-4e3d-a5ab-7f41ebfee510@github.com>

On Wed, 7 Jun 2023 11:29:06 GMT, Afshin Zafari <azafari at openjdk.org> wrote:

>> The `uintx/intx` options whose ranges are small enough are changed to `uint/int`, otherwise gcc complains 
>> when `-Wconversion` is used in build.
>> Their uses in printf formats are changed accordingly.
>> 
>> ### Tests
>> Locally hotspot:tier1 tested on linux-x64
>> mach5 tiers 1-4 on Linux and Windows 64bits platforms passed.
>
> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:
> 
>   some more intx to int conversions.

There are a lot of uses of the options that have casts, many of which ought to be removable with this change.
Some of those might pull more tangled strings, but it would be nice if there was a plan to look at those too.

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

PR Comment: https://git.openjdk.org/jdk/pull/14259#issuecomment-1581077477

From gli at openjdk.org  Wed Jun  7 15:43:08 2023
From: gli at openjdk.org (Guoxiong Li)
Date: Wed, 7 Jun 2023 15:43:08 GMT
Subject: RFR: 8272147: Consolidate preserved marks handling with other STW
 collectors [v4]
In-Reply-To: <jXZiOVJDgymUKJne7d-LXCpIx7xcPoFPGATHIGSw_HE=.cb5e5aa0-001c-4842-9c16-7cb70e41b8a2@github.com>
References: <jXZiOVJDgymUKJne7d-LXCpIx7xcPoFPGATHIGSw_HE=.cb5e5aa0-001c-4842-9c16-7cb70e41b8a2@github.com>
Message-ID: <O23DJGo0RPU69rbtmJmNnuDYm56hyrY1PjZBdhyDJmo=.27948db6-4eb3-40f8-aa8c-2465b6aff1d4@github.com>

> Hi all,
> 
> This patch removes the class `markSweep.hpp::PreservedMark` and uses the shared `PreservedMarksSet` instead.
> 
> In order to keep the meaning of the field `_preserved_marks` in `markSweep`,
> I need to use `OopAndMarkWord` explicitly. So I move `OopAndMarkWord` out of `PreservedMarks`.
> 
> Tests:
> `hotspot:tier1` passed locally (x86 & linux).
> 
> Thanks for the review.
> 
> Best Regards,
> -- Guoxiong

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

  Add and use 'adjust_preserved_mark'

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14274/files
  - new: https://git.openjdk.org/jdk/pull/14274/files/db8976fa..196b09b7

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

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

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

From gli at openjdk.org  Wed Jun  7 15:43:10 2023
From: gli at openjdk.org (Guoxiong Li)
Date: Wed, 7 Jun 2023 15:43:10 GMT
Subject: RFR: 8272147: Consolidate preserved marks handling with other STW
 collectors [v2]
In-Reply-To: <qF6V2xxKj8JCEvZJXr0_PiazfqDbTyo5FZwTPGKOUTU=.f8fb8e00-c7a6-422d-995b-26d2da78ebbf@github.com>
References: <jXZiOVJDgymUKJne7d-LXCpIx7xcPoFPGATHIGSw_HE=.cb5e5aa0-001c-4842-9c16-7cb70e41b8a2@github.com>
 <S1Tl2UbKhmi1ijfWk28_a51CL3C5NIlIVVJng-iuopw=.72e339b0-4796-46fb-92a0-3e5e7ab44e17@github.com>
 <qSmf6lKQXi73Qv12B-OV6u9gPnKWdzj7j8vlIOIcH2U=.d7609778-ea7a-438b-a7af-18c6a48fe37e@github.com>
 <2t85WpaaXY3vNlDC31vRu7zwpvz8vYpqM5rdeXDsGvc=.5d06d4d7-b346-49aa-a0bd-56c2f6e26983@github.com>
 <qF6V2xxKj8JCEvZJXr0_PiazfqDbTyo5FZwTPGKOUTU=.f8fb8e00-c7a6-422d-995b-26d2da78ebbf@github.com>
Message-ID: <0EZukAo0E4Bce2KcirNaGd_SneUxuUsnSRJ13xQbXCQ=.d36a8cb3-607c-49a4-926a-2e19986054ec@github.com>

On Wed, 7 Jun 2023 13:40:06 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>>> I wonder if one can add new API in PreservedMarks to adjust oops.
>> 
>> Should I add it in this patch? And, if such method is added, the method `PreservedMarks::adjust_during_full_gc` can use it too.
>
> Yes, please.

I updated the code just now. Added and used the method `PreservedMarks::adjust_preserved_mark`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14274#discussion_r1221811450

From gli at openjdk.org  Wed Jun  7 16:10:03 2023
From: gli at openjdk.org (Guoxiong Li)
Date: Wed, 7 Jun 2023 16:10:03 GMT
Subject: RFR: 8309403: Serial: Remove the useless adaptive size policy in
 GenCollectedHeap [v2]
In-Reply-To: <gsYwjCO7JKGpUClkunGrxw9izks_INAxBDZ-OpKBPQI=.cebebb7a-866e-4b20-b410-78add57adb1d@github.com>
References: <AgndfVJuqHKLBUtf3Q8srBUH_BnNnXmxnvTz1rNXuRU=.36ab3363-d8b4-4fe3-b7e5-83f92af37d06@github.com>
 <th101U_7ZJ0PzJyxkX3r63Fz6ENOjPJXxysCYV7CBWE=.6a2e1dc4-69c7-4575-be92-5f24c7fb0e56@github.com>
 <Ti2vvexSpP3ykFTJLmjxLo_vKSCkP4dTcjlnz-BSW98=.b4ed2aee-66bf-486d-af6b-2312a1f11426@github.com>
 <KSB6PPU4LCJ9NxmcBFmHbSXIAzmrn4v1Lg23J9Xef5k=.394bc572-d477-4fa7-8176-249600809fb6@github.com>
 <wKX4XIMNXhFrnCaqyuYX2wKKf_r2U5f1T5E7gab3WEs=.224bd13f-6807-4186-b5d3-f4e60ca9871e@github.com>
 <ohSEjm03ZQXDl4grIKfntWdOxMkUk6nihsxebR3bSYc=.740ff53f-3228-4a52-9a53-f6314de402d3@github.com>
 <F4KPh3ceb_3xjtnSVO_SeQ5HpWmoZGqPgd0NdhIYvpE=.8d6bd26e-7671-4ee3-b868-f67dd887ed23@github.com>
 <J1qi51EZVAqw5RvK6N0gD9J2gG4cGGUoYb8HooU2Bjo=.541c8782-9005-4c29-8f6f-a8ba8245473f@github.com>
 <gsYwjCO7JKGpUClkunGrxw9izks_INAxBDZ-OpKBPQI=.cebebb7a-866e-4b20-b410-78add57adb1d@github.com>
Message-ID: <R6_0iR3zCFMrfh9xTshZ4HjlzX1LLxAgchbw7IzgIj0=.e1f95064-1978-4ac5-885c-d37c1237d6c0@github.com>

On Wed, 7 Jun 2023 15:00:06 GMT, Guoxiong Li <gli at openjdk.org> wrote:

>  I will file new tickets to follow up.

Filed https://bugs.openjdk.org/browse/JDK-8309616 and https://bugs.openjdk.org/browse/JDK-8309619 to follow up.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14296#discussion_r1221855346

From kbarrett at openjdk.org  Wed Jun  7 18:11:24 2023
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 7 Jun 2023 18:11:24 GMT
Subject: RFR: 8309627: Incorrect sorting of DirtyCardQueue buffers
Message-ID: <9qwPHb6DFbJHv3DI4Oabrzu7yB5N0ErFNkk0vI1l_oc=.63378661-5d2c-43e4-a3b0-f4e88c817286@github.com>

Please review this simple fix to the sorting of dirty card buffers.  The
comparison function is using the difference between the card pointer to
compute the order, but is discarding all but the low 32 bits.

While I was at it, adjusted the name of the sort function.

Testing:
mach5 tier1

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

Commit messages:
 - fix

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

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

From ayang at openjdk.org  Wed Jun  7 19:33:48 2023
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Wed, 7 Jun 2023 19:33:48 GMT
Subject: RFR: 8309627: Incorrect sorting of DirtyCardQueue buffers
In-Reply-To: <9qwPHb6DFbJHv3DI4Oabrzu7yB5N0ErFNkk0vI1l_oc=.63378661-5d2c-43e4-a3b0-f4e88c817286@github.com>
References: <9qwPHb6DFbJHv3DI4Oabrzu7yB5N0ErFNkk0vI1l_oc=.63378661-5d2c-43e4-a3b0-f4e88c817286@github.com>
Message-ID: <cFf1-dPe1lJ15M5KdWcFOLT3xIGZTd4A8e8mqgktquM=.2fa30495-a3af-42c2-8359-54070b9595f3@github.com>

On Wed, 7 Jun 2023 18:02:37 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this simple fix to the sorting of dirty card buffers.  The
> comparison function is using the difference between the card pointer to
> compute the order, but is discarding all but the low 32 bits.
> 
> While I was at it, adjusted the name of the sort function.
> 
> Testing:
> mach5 tier1

Marked as reviewed by ayang (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/14365#pullrequestreview-1468417587

From ayang at openjdk.org  Wed Jun  7 20:21:52 2023
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Wed, 7 Jun 2023 20:21:52 GMT
Subject: RFR: 8272147: Consolidate preserved marks handling with other STW
 collectors [v4]
In-Reply-To: <O23DJGo0RPU69rbtmJmNnuDYm56hyrY1PjZBdhyDJmo=.27948db6-4eb3-40f8-aa8c-2465b6aff1d4@github.com>
References: <jXZiOVJDgymUKJne7d-LXCpIx7xcPoFPGATHIGSw_HE=.cb5e5aa0-001c-4842-9c16-7cb70e41b8a2@github.com>
 <O23DJGo0RPU69rbtmJmNnuDYm56hyrY1PjZBdhyDJmo=.27948db6-4eb3-40f8-aa8c-2465b6aff1d4@github.com>
Message-ID: <tLL7ETljbAqaenK_DlSuXS6bql95_MVzAfMwHPLl5jA=.cf10908c-2aab-42ae-a767-bc80ae95a74d@github.com>

On Wed, 7 Jun 2023 15:43:08 GMT, Guoxiong Li <gli at openjdk.org> wrote:

>> Hi all,
>> 
>> This patch removes the class `markSweep.hpp::PreservedMark` and uses the shared `PreservedMarksSet` instead.
>> 
>> In order to keep the meaning of the field `_preserved_marks` in `markSweep`,
>> I need to use `OopAndMarkWord` explicitly. So I move `OopAndMarkWord` out of `PreservedMarks`.
>> 
>> Tests:
>> `hotspot:tier1` passed locally (x86 & linux).
>> 
>> Thanks for the review.
>> 
>> Best Regards,
>> -- Guoxiong
>
> Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add and use 'adjust_preserved_mark'

Marked as reviewed by ayang (Reviewer).

src/hotspot/share/gc/shared/preservedMarks.hpp line 37:

> 35: class WorkerThreads;
> 36: 
> 37: class OopAndMarkWord {

Now that this class is in public domain, I tend to think it should be renamed to `PreservedMark` to be consistent with other classes in this file. (Ofc, this is quite subjective.)

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

PR Review: https://git.openjdk.org/jdk/pull/14274#pullrequestreview-1468494515
PR Review Comment: https://git.openjdk.org/jdk/pull/14274#discussion_r1222112692

From ayang at openjdk.org  Wed Jun  7 20:30:59 2023
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Wed, 7 Jun 2023 20:30:59 GMT
Subject: RFR: 8309403: Serial: Remove the useless adaptive size policy in
 GenCollectedHeap [v2]
In-Reply-To: <9h4WaHdIT8rpM6Q-55zp8dlUM0bieeZFnjyp4B8Fz88=.364f2b27-a1b2-430f-9d00-27968d0f9f5b@github.com>
References: <AgndfVJuqHKLBUtf3Q8srBUH_BnNnXmxnvTz1rNXuRU=.36ab3363-d8b4-4fe3-b7e5-83f92af37d06@github.com>
 <9h4WaHdIT8rpM6Q-55zp8dlUM0bieeZFnjyp4B8Fz88=.364f2b27-a1b2-430f-9d00-27968d0f9f5b@github.com>
Message-ID: <Mtbozm-ajhZwbRLvhaiuRF3p7hn1j49DcVhefKo5nvk=.23ab5527-2cf5-4274-a990-07bf1193611b@github.com>

On Wed, 7 Jun 2023 15:05:54 GMT, Guoxiong Li <gli at openjdk.org> wrote:

>> Hi all,
>> 
>> This patch removes the useless code related to the `AdaptiveSizePolicy` in `GenCollectedHeap`.
>> As a result, the `SoftRefGenPolicy` is unnecessary too, use `SoftRefPolicy` instead.
>> 
>> Thanks for the review.
>> 
>> Best Regards,
>> -- Guoxiong
>
> Guoxiong Li 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:
> 
>  - Restore the _should_clear_all_soft_refs in WB_FullGC.
>  - Merge branch 'master' into JDK-8309403
>  - JDK-8309403

src/hotspot/share/prims/whitebox.cpp line 1449:

> 1447:   Universe::heap()->collect(GCCause::_wb_full_gc);
> 1448: #if defined(INCLUDE_G1GC) || defined(INCLUDE_PARALLELGC) || defined(INCLUDE_SERIALGC)
> 1449:   if (UseG1GC || UseParallelGC || UseSerialGC) {

I don't think you can do the same for Parallel due to the presence of `GCOverheadChecker`, which also updates the global var.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14296#discussion_r1222121791

From iklam at openjdk.org  Thu Jun  8 05:08:53 2023
From: iklam at openjdk.org (Ioi Lam)
Date: Thu, 8 Jun 2023 05:08:53 GMT
Subject: RFR: 8309065: Move the logic to determine archive heap location
 from CDS to G1 GC [v3]
In-Reply-To: <_8f8oqpdYT56hxKf3MfApsT658ARTF0jXIMnP3UQo7E=.4936b832-9b5f-4853-be3d-c21daa3720c6@github.com>
References: <Jy8pV1WnLW6fMktk9Jmx5SF4JDWL8fl1zPNKOpV6FpA=.324de220-9ad8-4316-b871-c2b7dea5e6d2@github.com>
 <XATqoeHqYdc-FRfVKQqlJP8bsUXN7R9MqueuHQ0HGaQ=.ce7e8c50-c8d1-480e-83d7-c56a13d748a8@github.com>
 <M4Q8tx5azU88N1zScslx6oZjxQQPRFs0Ao2hfW41-iI=.9bdff767-e0ed-498c-8f6d-52b882649436@github.com>
 <znGoIEeXlITggzpACZOks8seQsdEB_PhzrUMRQFzG3U=.f61c9073-9d3e-47f0-a3bd-13bb94e0fb41@github.com>
 <G_rlFI8eUL1uwWszwBsvGMBTXjeO-WiJEBGngEIJacw=.f815a59f-ffe8-4762-9885-418890e5293a@github.com>
 <_8f8oqpdYT56hxKf3MfApsT658ARTF0jXIMnP3UQo7E=.4936b832-9b5f-4853-be3d-c21daa3720c6@github.com>
Message-ID: <8pwA_2qyJgwWaeeCNihqyrFI8vPPd7_Y2CMsxw32YrI=.fd4e81e9-0387-4e2e-affb-8cc279fe66c3@github.com>

On Wed, 7 Jun 2023 14:30:32 GMT, Ashutosh Mehra <duke at openjdk.org> wrote:

> > I didn't look but I assume the dumptime heap size is the default heap size?
> 
> 
> 
> I am wondering why do you think dumptime heap size is the default heap size?  When creating an archive the heap size can be anything. For default archive it is 128m.

The dump time heap size is set to 128mb for the default archive so that it can be mapped without relocation for small workloads with heaps that can fit under the 4gb boundary.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14208#discussion_r1222455270

From shade at openjdk.org  Thu Jun  8 05:46:49 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 8 Jun 2023 05:46:49 GMT
Subject: RFR: 8309627: Incorrect sorting of DirtyCardQueue buffers
In-Reply-To: <9qwPHb6DFbJHv3DI4Oabrzu7yB5N0ErFNkk0vI1l_oc=.63378661-5d2c-43e4-a3b0-f4e88c817286@github.com>
References: <9qwPHb6DFbJHv3DI4Oabrzu7yB5N0ErFNkk0vI1l_oc=.63378661-5d2c-43e4-a3b0-f4e88c817286@github.com>
Message-ID: <JW4AQKHt_2B7hPoLim5Fgf8-OebsId0dgpBnygTJPEk=.ff3a6a80-2320-409c-8545-00767ef10802@github.com>

On Wed, 7 Jun 2023 18:02:37 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this simple fix to the sorting of dirty card buffers.  The
> comparison function is using the difference between the card pointer to
> compute the order, but is discarding all but the low 32 bits.
> 
> While I was at it, adjusted the name of the sort function.
> 
> Testing:
> mach5 tier1

Looks good!

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

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14365#pullrequestreview-1469037835

From gli at openjdk.org  Thu Jun  8 07:01:11 2023
From: gli at openjdk.org (Guoxiong Li)
Date: Thu, 8 Jun 2023 07:01:11 GMT
Subject: RFR: 8309403: Serial: Remove the useless adaptive size policy in
 GenCollectedHeap [v3]
In-Reply-To: <AgndfVJuqHKLBUtf3Q8srBUH_BnNnXmxnvTz1rNXuRU=.36ab3363-d8b4-4fe3-b7e5-83f92af37d06@github.com>
References: <AgndfVJuqHKLBUtf3Q8srBUH_BnNnXmxnvTz1rNXuRU=.36ab3363-d8b4-4fe3-b7e5-83f92af37d06@github.com>
Message-ID: <812_XKkG--eaJggAh0e3WAcTqWdxc9rUkk2dAL1-yMo=.dec5b815-dbb2-4926-b402-0d92b577f452@github.com>

> Hi all,
> 
> This patch removes the useless code related to the `AdaptiveSizePolicy` in `GenCollectedHeap`.
> As a result, the `SoftRefGenPolicy` is unnecessary too, use `SoftRefPolicy` instead.
> 
> Thanks for the review.
> 
> Best Regards,
> -- Guoxiong

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

  Remove Parallel GC in 'WB_FullGC'

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14296/files
  - new: https://git.openjdk.org/jdk/pull/14296/files/1922cdfe..6d233e90

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

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

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

From gli at openjdk.org  Thu Jun  8 07:12:57 2023
From: gli at openjdk.org (Guoxiong Li)
Date: Thu, 8 Jun 2023 07:12:57 GMT
Subject: RFR: 8309403: Serial: Remove the useless adaptive size policy in
 GenCollectedHeap [v2]
In-Reply-To: <Mtbozm-ajhZwbRLvhaiuRF3p7hn1j49DcVhefKo5nvk=.23ab5527-2cf5-4274-a990-07bf1193611b@github.com>
References: <AgndfVJuqHKLBUtf3Q8srBUH_BnNnXmxnvTz1rNXuRU=.36ab3363-d8b4-4fe3-b7e5-83f92af37d06@github.com>
 <9h4WaHdIT8rpM6Q-55zp8dlUM0bieeZFnjyp4B8Fz88=.364f2b27-a1b2-430f-9d00-27968d0f9f5b@github.com>
 <Mtbozm-ajhZwbRLvhaiuRF3p7hn1j49DcVhefKo5nvk=.23ab5527-2cf5-4274-a990-07bf1193611b@github.com>
Message-ID: <cN10Uo_kMHpmQr8_TylYZmViZEh5TmLRuFOfHTK-nhs=.3b725208-10c0-479a-9e85-cf0453a716b1@github.com>

On Wed, 7 Jun 2023 20:28:12 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Guoxiong Li 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:
>> 
>>  - Restore the _should_clear_all_soft_refs in WB_FullGC.
>>  - Merge branch 'master' into JDK-8309403
>>  - JDK-8309403
>
> src/hotspot/share/prims/whitebox.cpp line 1449:
> 
>> 1447:   Universe::heap()->collect(GCCause::_wb_full_gc);
>> 1448: #if defined(INCLUDE_G1GC) || defined(INCLUDE_PARALLELGC) || defined(INCLUDE_SERIALGC)
>> 1449:   if (UseG1GC || UseParallelGC || UseSerialGC) {
> 
> I don't think you can do the same for Parallel due to the presence of `GCOverheadChecker`, which also updates the global var.

Fixed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14296#discussion_r1222554127

From azafari at openjdk.org  Thu Jun  8 09:44:54 2023
From: azafari at openjdk.org (Afshin Zafari)
Date: Thu, 8 Jun 2023 09:44:54 GMT
Subject: RFR: 8281455: Change JVM options with small ranges from 64 to 32
 bits, for gc_globals.hpp [v2]
In-Reply-To: <3a8VoARzDFgwD-natDR0B_iOvJcR8zYOEDqUKvaaxoU=.84724654-db08-4b49-957a-d562e94e5e44@github.com>
References: <PUZ-VNLsAs748dp0p0fknfkp6VxzSZRvBXp3cJvheko=.101c475e-a097-47ee-8ead-3464def85d7a@github.com>
 <XMUVdBeWfiSjnXl3nWjC0Ew01rxKBb_dCV7f8EFtdwE=.4d42e4d6-ea04-46a2-9019-cf895c271290@github.com>
 <3a8VoARzDFgwD-natDR0B_iOvJcR8zYOEDqUKvaaxoU=.84724654-db08-4b49-957a-d562e94e5e44@github.com>
Message-ID: <AeLlaTcBwUx1aPnITbsbNOUT7QRfo2ZGOLi358DlMQ8=.19380fc5-6903-4fd1-a588-b8ccb2869266@github.com>

On Wed, 7 Jun 2023 15:06:54 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   some more intx to int conversions.
>
> src/hotspot/share/gc/g1/g1Arguments.cpp line 232:
> 
>> 230:   // By default do not let the target stack size to be more than 1/4 of the entries
>> 231:   if (FLAG_IS_DEFAULT(GCDrainStackTargetSize)) {
>> 232:     FLAG_SET_ERGO(GCDrainStackTargetSize, MIN2(GCDrainStackTargetSize, (uint)TASKQUEUE_SIZE / 4));
> 
> TASKQUEUE_SIZE should be a constant of type size_t rather than a macro.  GCDrainStackTargetSize should be of type size_t.  Then we don't need any casts here.  But some uses may need cleaning up, either to remove casts or to adjust surrounding types.  I suggest this be split out as a separate RFE to avoid cluttering the simplicity of this PR.

The change is applied and some cleanup made. Maybe no need to a new RFE, if you agree.

> src/hotspot/share/gc/parallel/jvmFlagConstraintsParallel.cpp line 50:
> 
>> 48:       JVMFlag::printError(verbose,
>> 49:                           "InitialTenuringThreshold (" UINTX_FORMAT ") must be "
>> 50:                           "less than or equal to MaxTenuringThreshold (%u)\n",
> 
> (github UI won't let me attach comment to the function signature)
> The type of the value parameter should be changed in conjunction with the type change for the option,
> both here and in jvmFlagConstraintsParallel.hpp.  Similarly for MaxTenuringThresholdXXX below.

Fixed.

> src/hotspot/share/gc/parallel/psScavenge.cpp line 556:
> 
>> 554:                                                            survivor_limit);
>> 555: 
>> 556:        log_debug(gc, age)("Desired survivor size " SIZE_FORMAT " bytes, new threshold %u (max threshold %u)",
> 
> Consider also, instead of SIZE_FORMAT we can use "%zu".

`%zu` is used instead.

> src/hotspot/share/gc/shared/ageTable.cpp line 102:
> 
>> 100: 
>> 101: 
>> 102:   log_debug(gc, age)("Desired survivor size " SIZE_FORMAT " bytes, new threshold " UINTX_FORMAT " (max threshold %u)",
> 
> Consider also, instead of SIZE_FORMAT we can use "%zu".

`%zu` is used.

> src/hotspot/share/utilities/globalDefinitions.hpp line 434:
> 
>> 432: const uintx max_uintx = (uintx)-1;
>> 433: 
>> 434: 
> 
> stray blank line insertion?

Fixed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14259#discussion_r1222726600
PR Review Comment: https://git.openjdk.org/jdk/pull/14259#discussion_r1222726943
PR Review Comment: https://git.openjdk.org/jdk/pull/14259#discussion_r1222727513
PR Review Comment: https://git.openjdk.org/jdk/pull/14259#discussion_r1222727820
PR Review Comment: https://git.openjdk.org/jdk/pull/14259#discussion_r1222728790

From azafari at openjdk.org  Thu Jun  8 09:55:44 2023
From: azafari at openjdk.org (Afshin Zafari)
Date: Thu, 8 Jun 2023 09:55:44 GMT
Subject: RFR: 8281455: Change JVM options with small ranges from 64 to 32
 bits, for gc_globals.hpp [v3]
In-Reply-To: <PUZ-VNLsAs748dp0p0fknfkp6VxzSZRvBXp3cJvheko=.101c475e-a097-47ee-8ead-3464def85d7a@github.com>
References: <PUZ-VNLsAs748dp0p0fknfkp6VxzSZRvBXp3cJvheko=.101c475e-a097-47ee-8ead-3464def85d7a@github.com>
Message-ID: <Oq3b-RXjrUQa3je7gtFx5yp03T9Pqqsofb5c4Mmz4Pg=.53e4b5ec-d377-415f-95e4-27d8210ee8e9@github.com>

> The `uintx/intx` options whose ranges are small enough are changed to `uint/int`, otherwise gcc complains 
> when `-Wconversion` is used in build.
> Their uses in printf formats are changed accordingly.
> 
> ### Tests
> Locally hotspot:tier1 tested on linux-x64
> mach5 tiers 1-4 on Linux and Windows 64bits platforms passed.

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

  review comments applied

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14259/files
  - new: https://git.openjdk.org/jdk/pull/14259/files/b0b1501c..97577d9d

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

  Stats: 14 lines in 8 files changed: 0 ins; 1 del; 13 mod
  Patch: https://git.openjdk.org/jdk/pull/14259.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14259/head:pull/14259

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

From azafari at openjdk.org  Thu Jun  8 09:55:48 2023
From: azafari at openjdk.org (Afshin Zafari)
Date: Thu, 8 Jun 2023 09:55:48 GMT
Subject: RFR: 8281455: Change JVM options with small ranges from 64 to 32
 bits, for gc_globals.hpp [v2]
In-Reply-To: <3a8VoARzDFgwD-natDR0B_iOvJcR8zYOEDqUKvaaxoU=.84724654-db08-4b49-957a-d562e94e5e44@github.com>
References: <PUZ-VNLsAs748dp0p0fknfkp6VxzSZRvBXp3cJvheko=.101c475e-a097-47ee-8ead-3464def85d7a@github.com>
 <XMUVdBeWfiSjnXl3nWjC0Ew01rxKBb_dCV7f8EFtdwE=.4d42e4d6-ea04-46a2-9019-cf895c271290@github.com>
 <3a8VoARzDFgwD-natDR0B_iOvJcR8zYOEDqUKvaaxoU=.84724654-db08-4b49-957a-d562e94e5e44@github.com>
Message-ID: <DkCg-IVCJurVV3EIVgWoC6Ur8KZaWfNMNzn1TRiUwWE=.2a9ff367-7929-4b8a-8fe5-614de99c586c@github.com>

On Wed, 7 Jun 2023 15:18:53 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   some more intx to int conversions.
>
> src/hotspot/share/utilities/globalDefinitions.hpp line 441:
> 
>> 439: // max_uintx            0xFFFFFFFF      0xFFFFFFFFFFFFFFFF
>> 440: 
>> 441: typedef unsigned int uint;   NEEDS_CLEANUP
> 
> Unrelated, but I wonder why this "NEEDS_CLEANUP"?

Maybe, it is because the `uint` is already defined within the guarded lines 149-154: 
```C++
#ifdef __USE_MISC
/* Old compatibility names for C types.  */
typedef unsigned long int ulong;
typedef unsigned short int ushort;
typedef unsigned int uint;
#endif

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14259#discussion_r1222736817

From ayang at openjdk.org  Thu Jun  8 11:05:56 2023
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Thu, 8 Jun 2023 11:05:56 GMT
Subject: RFR: 8309403: Serial: Remove the useless adaptive size policy in
 GenCollectedHeap [v3]
In-Reply-To: <812_XKkG--eaJggAh0e3WAcTqWdxc9rUkk2dAL1-yMo=.dec5b815-dbb2-4926-b402-0d92b577f452@github.com>
References: <AgndfVJuqHKLBUtf3Q8srBUH_BnNnXmxnvTz1rNXuRU=.36ab3363-d8b4-4fe3-b7e5-83f92af37d06@github.com>
 <812_XKkG--eaJggAh0e3WAcTqWdxc9rUkk2dAL1-yMo=.dec5b815-dbb2-4926-b402-0d92b577f452@github.com>
Message-ID: <WsQ13HqNWnUEfpfxIalBr_lWYwREQpbzDvk3-DkNBK8=.2c8110d9-d3e4-445b-a327-387c742412b6@github.com>

On Thu, 8 Jun 2023 07:01:11 GMT, Guoxiong Li <gli at openjdk.org> wrote:

>> Hi all,
>> 
>> This patch removes the useless code related to the `AdaptiveSizePolicy` in `GenCollectedHeap`.
>> As a result, the `SoftRefGenPolicy` is unnecessary too, use `SoftRefPolicy` instead.
>> 
>> Thanks for the review.
>> 
>> Best Regards,
>> -- Guoxiong
>
> Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove Parallel GC in 'WB_FullGC'

Marked as reviewed by ayang (Reviewer).

src/hotspot/share/prims/whitebox.cpp line 1448:

> 1446:   Universe::heap()->soft_ref_policy()->set_should_clear_all_soft_refs(true);
> 1447:   Universe::heap()->collect(GCCause::_wb_full_gc);
> 1448: #if defined(INCLUDE_G1GC) || defined(INCLUDE_SERIALGC)

`INCLUDE_G1GC` can be defined as zero; it's best to treat them as bool vars. The rest look good.

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

PR Review: https://git.openjdk.org/jdk/pull/14296#pullrequestreview-1469660583
PR Review Comment: https://git.openjdk.org/jdk/pull/14296#discussion_r1222879646

From azafari at openjdk.org  Thu Jun  8 12:17:55 2023
From: azafari at openjdk.org (Afshin Zafari)
Date: Thu, 8 Jun 2023 12:17:55 GMT
Subject: RFR: 8281455: Change JVM options with small ranges from 64 to 32
 bits, for gc_globals.hpp [v2]
In-Reply-To: <lqB8iLQvOz8mpMo2103eL3NNQ_5jSfVg4Aq-Y-YicyU=.c9d3b7e4-bfc0-4e3d-a5ab-7f41ebfee510@github.com>
References: <PUZ-VNLsAs748dp0p0fknfkp6VxzSZRvBXp3cJvheko=.101c475e-a097-47ee-8ead-3464def85d7a@github.com>
 <XMUVdBeWfiSjnXl3nWjC0Ew01rxKBb_dCV7f8EFtdwE=.4d42e4d6-ea04-46a2-9019-cf895c271290@github.com>
 <lqB8iLQvOz8mpMo2103eL3NNQ_5jSfVg4Aq-Y-YicyU=.c9d3b7e4-bfc0-4e3d-a5ab-7f41ebfee510@github.com>
Message-ID: <_ZMPXReZSPE3pSM3xX0DEFb9e-LrJejAz1Q_aJ8-uJA=.26fd29f8-9199-43ef-80cc-7af62bd2612b@github.com>

On Wed, 7 Jun 2023 15:36:10 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> There are a lot of uses of the options that have casts, many of which ought to be removable with this change. Some of those might pull more tangled strings, but it would be nice if there was a plan to look at those too.

During this change, I changed all the cases that I found them to be changed. Would you please, give some examples or some 'search criteria' that I can use to find the cases. Then, I will do them here in this PR or create a new RFE for them. Thanks.

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

PR Comment: https://git.openjdk.org/jdk/pull/14259#issuecomment-1582477155

From azafari at openjdk.org  Thu Jun  8 12:24:51 2023
From: azafari at openjdk.org (Afshin Zafari)
Date: Thu, 8 Jun 2023 12:24:51 GMT
Subject: RFR: 8281455: Change JVM options with small ranges from 64 to 32
 bits, for gc_globals.hpp [v3]
In-Reply-To: <Oq3b-RXjrUQa3je7gtFx5yp03T9Pqqsofb5c4Mmz4Pg=.53e4b5ec-d377-415f-95e4-27d8210ee8e9@github.com>
References: <PUZ-VNLsAs748dp0p0fknfkp6VxzSZRvBXp3cJvheko=.101c475e-a097-47ee-8ead-3464def85d7a@github.com>
 <Oq3b-RXjrUQa3je7gtFx5yp03T9Pqqsofb5c4Mmz4Pg=.53e4b5ec-d377-415f-95e4-27d8210ee8e9@github.com>
Message-ID: <XheMWerq99zT7MvZi0SLrL4mhXt4vqaNZtJxobZsJkU=.39544a94-7ac7-4cd0-bd3d-3f578de33f16@github.com>

On Thu, 8 Jun 2023 09:55:44 GMT, Afshin Zafari <azafari at openjdk.org> wrote:

>> The `uintx/intx` options whose ranges are small enough are changed to `uint/int`, otherwise gcc complains 
>> when `-Wconversion` is used in build.
>> Their uses in printf formats are changed accordingly.
>> 
>> ### Tests
>> Locally hotspot:tier1 tested on linux-x64
>> mach5 tiers 1-4 on Linux and Windows 64bits platforms passed.
>
> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review comments applied

The review comments are applied as stated.
The type of `GCDrainStackTargetSize` is changed and corresponding casts are also modified. Not so many changes were they. They can be excluded from this PR if needed.

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

PR Review: https://git.openjdk.org/jdk/pull/14259#pullrequestreview-1469789004

From coleenp at openjdk.org  Thu Jun  8 12:28:52 2023
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 8 Jun 2023 12:28:52 GMT
Subject: RFR: 8281455: Change JVM options with small ranges from 64 to 32
 bits, for gc_globals.hpp [v3]
In-Reply-To: <Oq3b-RXjrUQa3je7gtFx5yp03T9Pqqsofb5c4Mmz4Pg=.53e4b5ec-d377-415f-95e4-27d8210ee8e9@github.com>
References: <PUZ-VNLsAs748dp0p0fknfkp6VxzSZRvBXp3cJvheko=.101c475e-a097-47ee-8ead-3464def85d7a@github.com>
 <Oq3b-RXjrUQa3je7gtFx5yp03T9Pqqsofb5c4Mmz4Pg=.53e4b5ec-d377-415f-95e4-27d8210ee8e9@github.com>
Message-ID: <TZy3ACp0vJlrz_DlP1UN5vNOyjBzwfEF7_AhZ-uE_9w=.195c6a7d-6113-416b-8cf7-f7cfdf0fd646@github.com>

On Thu, 8 Jun 2023 09:55:44 GMT, Afshin Zafari <azafari at openjdk.org> wrote:

>> The `uintx/intx` options whose ranges are small enough are changed to `uint/int`, otherwise gcc complains 
>> when `-Wconversion` is used in build.
>> Their uses in printf formats are changed accordingly.
>> 
>> ### Tests
>> Locally hotspot:tier1 tested on linux-x64
>> mach5 tiers 1-4 on Linux and Windows 64bits platforms passed.
>
> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review comments applied

This looks like a good change to me to avoid Wconversion warnings for mis-sized argument values but I'll leave it up to the GC experts.

src/hotspot/share/gc/parallel/psAdaptiveSizePolicy.cpp line 529:

> 527:           "PSAdaptiveSizePolicy::compute_old_gen_free_space: gc time limit"
> 528:           " gc_cost: %f "
> 529:           " GCTimeLimit: " UINT32_FORMAT,

Should this be %u also?

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

PR Review: https://git.openjdk.org/jdk/pull/14259#pullrequestreview-1469792200
PR Review Comment: https://git.openjdk.org/jdk/pull/14259#discussion_r1222965879

From gli at openjdk.org  Thu Jun  8 13:21:34 2023
From: gli at openjdk.org (Guoxiong Li)
Date: Thu, 8 Jun 2023 13:21:34 GMT
Subject: RFR: 8309403: Serial: Remove the useless adaptive size policy in
 GenCollectedHeap [v4]
In-Reply-To: <AgndfVJuqHKLBUtf3Q8srBUH_BnNnXmxnvTz1rNXuRU=.36ab3363-d8b4-4fe3-b7e5-83f92af37d06@github.com>
References: <AgndfVJuqHKLBUtf3Q8srBUH_BnNnXmxnvTz1rNXuRU=.36ab3363-d8b4-4fe3-b7e5-83f92af37d06@github.com>
Message-ID: <MZhLt2ktfE3bDeJLNLasJVrDyWF_K0eL6Fv6mLYjvnc=.0f5c2974-d078-4794-9882-e578acf9ffda@github.com>

> Hi all,
> 
> This patch removes the useless code related to the `AdaptiveSizePolicy` in `GenCollectedHeap`.
> As a result, the `SoftRefGenPolicy` is unnecessary too, use `SoftRefPolicy` instead.
> 
> Thanks for the review.
> 
> Best Regards,
> -- Guoxiong

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

  Treat INCLUDE_G1GC and INCLUDE_SERIALGC as variables.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14296/files
  - new: https://git.openjdk.org/jdk/pull/14296/files/6d233e90..beaa29ff

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

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

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

From gli at openjdk.org  Thu Jun  8 13:28:59 2023
From: gli at openjdk.org (Guoxiong Li)
Date: Thu, 8 Jun 2023 13:28:59 GMT
Subject: RFR: 8309403: Serial: Remove the useless adaptive size policy in
 GenCollectedHeap [v3]
In-Reply-To: <WsQ13HqNWnUEfpfxIalBr_lWYwREQpbzDvk3-DkNBK8=.2c8110d9-d3e4-445b-a327-387c742412b6@github.com>
References: <AgndfVJuqHKLBUtf3Q8srBUH_BnNnXmxnvTz1rNXuRU=.36ab3363-d8b4-4fe3-b7e5-83f92af37d06@github.com>
 <812_XKkG--eaJggAh0e3WAcTqWdxc9rUkk2dAL1-yMo=.dec5b815-dbb2-4926-b402-0d92b577f452@github.com>
 <WsQ13HqNWnUEfpfxIalBr_lWYwREQpbzDvk3-DkNBK8=.2c8110d9-d3e4-445b-a327-387c742412b6@github.com>
Message-ID: <sSCc2oHn3jsKlDVCW7nZLMIcRuQNtCaOOB6pqGV7aIM=.8c5257f3-a436-4325-9b87-4aba43771b61@github.com>

On Thu, 8 Jun 2023 11:02:27 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove Parallel GC in 'WB_FullGC'
>
> src/hotspot/share/prims/whitebox.cpp line 1448:
> 
>> 1446:   Universe::heap()->soft_ref_policy()->set_should_clear_all_soft_refs(true);
>> 1447:   Universe::heap()->collect(GCCause::_wb_full_gc);
>> 1448: #if defined(INCLUDE_G1GC) || defined(INCLUDE_SERIALGC)
> 
> `INCLUDE_G1GC` can be defined as zero; it's best to treat them as bool vars. The rest look good.

Fixed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14296#discussion_r1223042096

From gli at openjdk.org  Thu Jun  8 14:09:08 2023
From: gli at openjdk.org (Guoxiong Li)
Date: Thu, 8 Jun 2023 14:09:08 GMT
Subject: RFR: 8272147: Consolidate preserved marks handling with other STW
 collectors [v5]
In-Reply-To: <jXZiOVJDgymUKJne7d-LXCpIx7xcPoFPGATHIGSw_HE=.cb5e5aa0-001c-4842-9c16-7cb70e41b8a2@github.com>
References: <jXZiOVJDgymUKJne7d-LXCpIx7xcPoFPGATHIGSw_HE=.cb5e5aa0-001c-4842-9c16-7cb70e41b8a2@github.com>
Message-ID: <6ltfOUwy0V-4cgwFaMlXyiUHsIyB_TktZi1kRtRzgqI=.c45d3747-9610-4d84-ba71-85034dca6004@github.com>

> Hi all,
> 
> This patch removes the class `markSweep.hpp::PreservedMark` and uses the shared `PreservedMarksSet` instead.
> 
> In order to keep the meaning of the field `_preserved_marks` in `markSweep`,
> I need to use `OopAndMarkWord` explicitly. So I move `OopAndMarkWord` out of `PreservedMarks`.
> 
> Tests:
> `hotspot:tier1` passed locally (x86 & linux).
> 
> Thanks for the review.
> 
> Best Regards,
> -- Guoxiong

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

  Rename OopAndMarkWork to PreservedMark.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14274/files
  - new: https://git.openjdk.org/jdk/pull/14274/files/196b09b7..9225c7d0

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

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

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

From gli at openjdk.org  Thu Jun  8 14:09:12 2023
From: gli at openjdk.org (Guoxiong Li)
Date: Thu, 8 Jun 2023 14:09:12 GMT
Subject: RFR: 8272147: Consolidate preserved marks handling with other STW
 collectors [v4]
In-Reply-To: <tLL7ETljbAqaenK_DlSuXS6bql95_MVzAfMwHPLl5jA=.cf10908c-2aab-42ae-a767-bc80ae95a74d@github.com>
References: <jXZiOVJDgymUKJne7d-LXCpIx7xcPoFPGATHIGSw_HE=.cb5e5aa0-001c-4842-9c16-7cb70e41b8a2@github.com>
 <O23DJGo0RPU69rbtmJmNnuDYm56hyrY1PjZBdhyDJmo=.27948db6-4eb3-40f8-aa8c-2465b6aff1d4@github.com>
 <tLL7ETljbAqaenK_DlSuXS6bql95_MVzAfMwHPLl5jA=.cf10908c-2aab-42ae-a767-bc80ae95a74d@github.com>
Message-ID: <zalugPAMRsyU9chTFr_Va8m2v0zm5SbWHBoMrXzPcLM=.6c0130a3-38d2-4f68-acdc-3853557882ff@github.com>

On Wed, 7 Jun 2023 20:18:35 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add and use 'adjust_preserved_mark'
>
> src/hotspot/share/gc/shared/preservedMarks.hpp line 37:
> 
>> 35: class WorkerThreads;
>> 36: 
>> 37: class OopAndMarkWord {
> 
> Now that this class is in public domain, I tend to think it should be renamed to `PreservedMark` to be consistent with other classes in this file. (Ofc, this is quite subjective.)

Renamed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14274#discussion_r1223092687

From stefank at openjdk.org  Thu Jun  8 18:13:34 2023
From: stefank at openjdk.org (Stefan Karlsson)
Date: Thu, 8 Jun 2023 18:13:34 GMT
Subject: RFR: 8309675: Generational ZGC:
 compiler/gcbarriers/UnsafeIntrinsicsTest.java fails in nmt_commit
Message-ID: <YLPoGI63AfKjJP5QQx4lom73OSDCSXpvDFsRxjhNIN4=.329418d5-10df-4522-9c76-23891f430402@github.com>

The failure happens because we have extra verification code that is incorrect to use when calling the NMT tracking code. 

The fix is to simply inline the address calculation code *without* the verification code.

This fixes a tier3 failure. I'm going to run this through more extensive testing but it would be good to get this reviewed.

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

Commit messages:
 - 8309675: Generational ZGC: compiler/gcbarriers/UnsafeIntrinsicsTest.java fails in nmt_commit

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

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

From stefank at openjdk.org  Thu Jun  8 18:19:41 2023
From: stefank at openjdk.org (Stefan Karlsson)
Date: Thu, 8 Jun 2023 18:19:41 GMT
Subject: RFR: 8309675: Generational ZGC:
 compiler/gcbarriers/UnsafeIntrinsicsTest.java fails in nmt_commit
In-Reply-To: <YLPoGI63AfKjJP5QQx4lom73OSDCSXpvDFsRxjhNIN4=.329418d5-10df-4522-9c76-23891f430402@github.com>
References: <YLPoGI63AfKjJP5QQx4lom73OSDCSXpvDFsRxjhNIN4=.329418d5-10df-4522-9c76-23891f430402@github.com>
Message-ID: <1-pVa1ISjtiB3R8BVC72Tg6JARKFL0WS4h4ZKsYE9X0=.0d192140-fd65-4987-8b65-5508f6ab5391@github.com>

On Thu, 8 Jun 2023 18:05:46 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> The failure happens because we have extra verification code that is incorrect to use when calling the NMT tracking code. 
> 
> The fix is to simply inline the address calculation code *without* the verification code.
> 
> This fixes a tier3 failure. I'm going to run this through more extensive testing but it would be good to get this reviewed.

The reason why this only happens on this test is that -XX:+ZVerifyOops is only turned on in this test.

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

PR Comment: https://git.openjdk.org/jdk/pull/14382#issuecomment-1583124429

From stefank at openjdk.org  Thu Jun  8 18:24:40 2023
From: stefank at openjdk.org (Stefan Karlsson)
Date: Thu, 8 Jun 2023 18:24:40 GMT
Subject: RFR: 8309675: Generational ZGC:
 compiler/gcbarriers/UnsafeIntrinsicsTest.java fails in nmt_commit
In-Reply-To: <YLPoGI63AfKjJP5QQx4lom73OSDCSXpvDFsRxjhNIN4=.329418d5-10df-4522-9c76-23891f430402@github.com>
References: <YLPoGI63AfKjJP5QQx4lom73OSDCSXpvDFsRxjhNIN4=.329418d5-10df-4522-9c76-23891f430402@github.com>
Message-ID: <bEz9Dr3ZTDdeQxyOLEfBhcH-nm76id1ZbkxOJScJxEo=.3740819b-178d-4761-a2b1-731dd64c10eb@github.com>

On Thu, 8 Jun 2023 18:05:46 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> The failure happens because we have extra verification code that is incorrect to use when calling the NMT tracking code. 
> 
> The fix is to simply inline the address calculation code *without* the verification code.
> 
> This fixes a tier3 failure. I'm going to run this through more extensive testing but it would be good to get this reviewed.

To understand the fix see the function I'm replacing:

inline zaddress ZOffset::address(zoffset offset) {
  return to_zaddress(untype(offset) | ZAddressHeapBase);
}


and the verification code in this function:

inline zaddress to_zaddress(uintptr_t value) {
  const zaddress addr = zaddress(value);
  assert_is_valid(addr);
  DEBUG_ONLY(dereferenceable_test(addr));
  return addr;
}


The crash happens because of the dereferenceable_test, which checks that the memory have been committed and is accessible. As described in nmt_commit, we fake the address we report to NMT, so we can't try to dereference the contents of that address.

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

PR Comment: https://git.openjdk.org/jdk/pull/14382#issuecomment-1583130866

From aboldtch at openjdk.org  Thu Jun  8 18:28:41 2023
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Thu, 8 Jun 2023 18:28:41 GMT
Subject: RFR: 8309675: Generational ZGC:
 compiler/gcbarriers/UnsafeIntrinsicsTest.java fails in nmt_commit
In-Reply-To: <YLPoGI63AfKjJP5QQx4lom73OSDCSXpvDFsRxjhNIN4=.329418d5-10df-4522-9c76-23891f430402@github.com>
References: <YLPoGI63AfKjJP5QQx4lom73OSDCSXpvDFsRxjhNIN4=.329418d5-10df-4522-9c76-23891f430402@github.com>
Message-ID: <bf7_NmzkulyJDTd8vS2uFAPH4m8A0N-Kfd3KsE5b1zE=.bba56c9a-6f7b-4d00-b490-f0d7ef86fe03@github.com>

On Thu, 8 Jun 2023 18:05:46 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> The failure happens because we have extra verification code that is incorrect to use when calling the NMT tracking code. 
> 
> The fix is to simply inline the address calculation code *without* the verification code.
> 
> This fixes a tier3 failure. I'm going to run this through more extensive testing but it would be good to get this reviewed.

Guess this hit the dereference test. 
Could probably use `zaddress_unsafe` as well?
Either solution works.

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

Marked as reviewed by aboldtch (Committer).

PR Review: https://git.openjdk.org/jdk/pull/14382#pullrequestreview-1470542059

From stefank at openjdk.org  Thu Jun  8 18:53:55 2023
From: stefank at openjdk.org (Stefan Karlsson)
Date: Thu, 8 Jun 2023 18:53:55 GMT
Subject: RFR: 8309675: Generational ZGC:
 compiler/gcbarriers/UnsafeIntrinsicsTest.java fails in nmt_commit
In-Reply-To: <YLPoGI63AfKjJP5QQx4lom73OSDCSXpvDFsRxjhNIN4=.329418d5-10df-4522-9c76-23891f430402@github.com>
References: <YLPoGI63AfKjJP5QQx4lom73OSDCSXpvDFsRxjhNIN4=.329418d5-10df-4522-9c76-23891f430402@github.com>
Message-ID: <V9Ht0YiZpUfcqHoT8g9hmwe4JjT6h00zhrr5Hr43g54=.f906754c-5d4a-4083-a0ac-2f4629fa031d@github.com>

On Thu, 8 Jun 2023 18:05:46 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> The failure happens because we have extra verification code that is incorrect to use when calling the NMT tracking code. 
> 
> The fix is to simply inline the address calculation code *without* the verification code.
> 
> This fixes a tier3 failure. I'm going to run this through more extensive testing but it would be good to get this reviewed.

Yes, that's a good suggestion, though I think I'd prefer to stick with the current solution because then it is more clear that the code matches the comment in nmt_commit.

Thanks for reviewing!

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

PR Comment: https://git.openjdk.org/jdk/pull/14382#issuecomment-1583164038

From dcubed at openjdk.org  Thu Jun  8 19:21:42 2023
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Thu, 8 Jun 2023 19:21:42 GMT
Subject: RFR: 8309675: Generational ZGC:
 compiler/gcbarriers/UnsafeIntrinsicsTest.java fails in nmt_commit
In-Reply-To: <YLPoGI63AfKjJP5QQx4lom73OSDCSXpvDFsRxjhNIN4=.329418d5-10df-4522-9c76-23891f430402@github.com>
References: <YLPoGI63AfKjJP5QQx4lom73OSDCSXpvDFsRxjhNIN4=.329418d5-10df-4522-9c76-23891f430402@github.com>
Message-ID: <maDt5Un90ykkJqIvTtz8IjcZlzx1M8yaMrzltiO6g8k=.cf2b46e2-bda0-4b63-b9ad-d726d9a38255@github.com>

On Thu, 8 Jun 2023 18:05:46 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> The failure happens because we have extra verification code that is incorrect to use when calling the NMT tracking code. 
> 
> The fix is to simply inline the address calculation code *without* the verification code.
> 
> This fixes a tier3 failure. I'm going to run this through more extensive testing but it would be good to get this reviewed.

Thumbs up. Yet another disconnect between NMT virtual memory
modeling versus Z virtual memory modeling?

Did you run the revised test on all Tier3 platforms?

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

Marked as reviewed by dcubed (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14382#pullrequestreview-1470611732
PR Comment: https://git.openjdk.org/jdk/pull/14382#issuecomment-1583202172

From stefank at openjdk.org  Thu Jun  8 19:36:41 2023
From: stefank at openjdk.org (Stefan Karlsson)
Date: Thu, 8 Jun 2023 19:36:41 GMT
Subject: RFR: 8309675: Generational ZGC:
 compiler/gcbarriers/UnsafeIntrinsicsTest.java fails in nmt_commit
In-Reply-To: <maDt5Un90ykkJqIvTtz8IjcZlzx1M8yaMrzltiO6g8k=.cf2b46e2-bda0-4b63-b9ad-d726d9a38255@github.com>
References: <YLPoGI63AfKjJP5QQx4lom73OSDCSXpvDFsRxjhNIN4=.329418d5-10df-4522-9c76-23891f430402@github.com>
 <maDt5Un90ykkJqIvTtz8IjcZlzx1M8yaMrzltiO6g8k=.cf2b46e2-bda0-4b63-b9ad-d726d9a38255@github.com>
Message-ID: <NdwdmQnOhPagmBbkgAjKWzgkSjE7R2O35WzdxEMKY30=.a2c368ab-1eba-41d8-bc63-46fd3388e0be@github.com>

On Thu, 8 Jun 2023 19:18:36 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> Thumbs up. Yet another disconnect between NMT virtual memory modeling versus Z virtual memory modeling?

Thanks for reviewing. Yes, in away. It's the workaround for this disconnect that triggered our verification code, which in turn found our workaround with the fake addresses. :)

> Did you run the revised test on all Tier3 platforms?

I'm running tier1-7 with Generational ZGC. There's just a few more tests running, so I'm on the verge of integrating this.

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

PR Comment: https://git.openjdk.org/jdk/pull/14382#issuecomment-1583216368
PR Comment: https://git.openjdk.org/jdk/pull/14382#issuecomment-1583218183

From stefank at openjdk.org  Thu Jun  8 19:44:48 2023
From: stefank at openjdk.org (Stefan Karlsson)
Date: Thu, 8 Jun 2023 19:44:48 GMT
Subject: Integrated: 8309675: Generational ZGC:
 compiler/gcbarriers/UnsafeIntrinsicsTest.java fails in nmt_commit
In-Reply-To: <YLPoGI63AfKjJP5QQx4lom73OSDCSXpvDFsRxjhNIN4=.329418d5-10df-4522-9c76-23891f430402@github.com>
References: <YLPoGI63AfKjJP5QQx4lom73OSDCSXpvDFsRxjhNIN4=.329418d5-10df-4522-9c76-23891f430402@github.com>
Message-ID: <9xw_VwKzhg7j5GdpVQJrosyaGH0Ny18hvdqhsU7YVCg=.bc001a61-1d39-4b64-b3f6-da1719194d2b@github.com>

On Thu, 8 Jun 2023 18:05:46 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> The failure happens because we have extra verification code that is incorrect to use when calling the NMT tracking code. 
> 
> The fix is to simply inline the address calculation code *without* the verification code.
> 
> This fixes a tier3 failure. I'm going to run this through more extensive testing but it would be good to get this reviewed.

This pull request has now been integrated.

Changeset: c4e65425
Author:    Stefan Karlsson <stefank at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c4e6542514be19cebb41a0c390645db0a191504f
Stats:     4 lines in 1 file changed: 0 ins; 0 del; 4 mod

8309675: Generational ZGC: compiler/gcbarriers/UnsafeIntrinsicsTest.java fails in nmt_commit

Reviewed-by: aboldtch, dcubed

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

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

From stefank at openjdk.org  Thu Jun  8 20:00:42 2023
From: stefank at openjdk.org (Stefan Karlsson)
Date: Thu, 8 Jun 2023 20:00:42 GMT
Subject: RFR: 8309675: Generational ZGC:
 compiler/gcbarriers/UnsafeIntrinsicsTest.java fails in nmt_commit
Message-ID: <OvEF0STypnIDs3b1r9uk33vYrxbOMsSZLnmuHzSm3as=.1040451a-dd4c-46c5-984e-cc8840e9315c@github.com>

8309675: Generational ZGC: compiler/gcbarriers/UnsafeIntrinsicsTest.java fails in nmt_commit

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

Commit messages:
 - Backport c4e6542514be19cebb41a0c390645db0a191504f

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

PR: https://git.openjdk.org/jdk21/pull/2

From dcubed at openjdk.org  Thu Jun  8 20:06:03 2023
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Thu, 8 Jun 2023 20:06:03 GMT
Subject: RFR: 8309675: Generational ZGC:
 compiler/gcbarriers/UnsafeIntrinsicsTest.java fails in nmt_commit
In-Reply-To: <OvEF0STypnIDs3b1r9uk33vYrxbOMsSZLnmuHzSm3as=.1040451a-dd4c-46c5-984e-cc8840e9315c@github.com>
References: <OvEF0STypnIDs3b1r9uk33vYrxbOMsSZLnmuHzSm3as=.1040451a-dd4c-46c5-984e-cc8840e9315c@github.com>
Message-ID: <hCm8iQhLP6V7Gza-E6iYuSXUX53oVVCTykUA0RjeZuM=.34bfeb2a-c5b7-44a4-8d8f-6c28bbca2492@github.com>

On Thu, 8 Jun 2023 19:51:56 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> 8309675: Generational ZGC: compiler/gcbarriers/UnsafeIntrinsicsTest.java fails in nmt_commit

Thumbs up. This is a clean backport.

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

Marked as reviewed by dcubed (Reviewer).

PR Review: https://git.openjdk.org/jdk21/pull/2#pullrequestreview-1470669808

From stefank at openjdk.org  Thu Jun  8 20:06:03 2023
From: stefank at openjdk.org (Stefan Karlsson)
Date: Thu, 8 Jun 2023 20:06:03 GMT
Subject: RFR: 8309675: Generational ZGC:
 compiler/gcbarriers/UnsafeIntrinsicsTest.java fails in nmt_commit
In-Reply-To: <OvEF0STypnIDs3b1r9uk33vYrxbOMsSZLnmuHzSm3as=.1040451a-dd4c-46c5-984e-cc8840e9315c@github.com>
References: <OvEF0STypnIDs3b1r9uk33vYrxbOMsSZLnmuHzSm3as=.1040451a-dd4c-46c5-984e-cc8840e9315c@github.com>
Message-ID: <hoS-Y_po6XmVADQaVV843VPWI_r8EaoaE3TEOlFZy2A=.733b8052-5fca-48b5-a864-53cafdc9d92a@github.com>

On Thu, 8 Jun 2023 19:51:56 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> 8309675: Generational ZGC: compiler/gcbarriers/UnsafeIntrinsicsTest.java fails in nmt_commit

Thanks for reviewing!

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

PR Comment: https://git.openjdk.org/jdk21/pull/2#issuecomment-1583261890

From stefank at openjdk.org  Thu Jun  8 20:06:04 2023
From: stefank at openjdk.org (Stefan Karlsson)
Date: Thu, 8 Jun 2023 20:06:04 GMT
Subject: Integrated: 8309675: Generational ZGC:
 compiler/gcbarriers/UnsafeIntrinsicsTest.java fails in nmt_commit
In-Reply-To: <OvEF0STypnIDs3b1r9uk33vYrxbOMsSZLnmuHzSm3as=.1040451a-dd4c-46c5-984e-cc8840e9315c@github.com>
References: <OvEF0STypnIDs3b1r9uk33vYrxbOMsSZLnmuHzSm3as=.1040451a-dd4c-46c5-984e-cc8840e9315c@github.com>
Message-ID: <mLZgIN235HP9L24dV6biRXkUYnsv3p-6W9UcsDApPA4=.8e5886b9-68d9-4670-9ac3-cbf172beba66@github.com>

On Thu, 8 Jun 2023 19:51:56 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> 8309675: Generational ZGC: compiler/gcbarriers/UnsafeIntrinsicsTest.java fails in nmt_commit

This pull request has now been integrated.

Changeset: 430ffe7a
Author:    Stefan Karlsson <stefank at openjdk.org>
URL:       https://git.openjdk.org/jdk21/commit/430ffe7ae691d097de2818391531522f2538431d
Stats:     4 lines in 1 file changed: 0 ins; 0 del; 4 mod

8309675: Generational ZGC: compiler/gcbarriers/UnsafeIntrinsicsTest.java fails in nmt_commit

Reviewed-by: dcubed
Backport-of: c4e6542514be19cebb41a0c390645db0a191504f

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

PR: https://git.openjdk.org/jdk21/pull/2

From matsaave at openjdk.org  Thu Jun  8 22:01:11 2023
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Thu, 8 Jun 2023 22:01:11 GMT
Subject: RFR: 8309673: Refactor ref_at methods in Serviceability ConstantPool
Message-ID: <hRsZfM8S0Lm5YNnE-rONBi_ikCFCfsEAK0WLl3j-9co=.59c8f460-58ee-4d97-bdca-24d539de95ca@github.com>

The accessor methods in constantpool.cpp were previously cleaned up to allow for different types of indices to be used, distinguishing them by the bytecode. This patch adds the same changes to the hotspot serviceability code. Verified with tier 1-5 tests.

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

Commit messages:
 - 8309673: Refactor ref_at methods in Serviceability ConstantPool

Changes: https://git.openjdk.org/jdk/pull/14385/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14385&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8309673
  Stats: 95 lines in 4 files changed: 32 ins; 25 del; 38 mod
  Patch: https://git.openjdk.org/jdk/pull/14385.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14385/head:pull/14385

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

From kbarrett at openjdk.org  Fri Jun  9 09:08:48 2023
From: kbarrett at openjdk.org (Kim Barrett)
Date: Fri, 9 Jun 2023 09:08:48 GMT
Subject: RFR: 8281455: Change JVM options with small ranges from 64 to 32
 bits, for gc_globals.hpp [v3]
In-Reply-To: <Oq3b-RXjrUQa3je7gtFx5yp03T9Pqqsofb5c4Mmz4Pg=.53e4b5ec-d377-415f-95e4-27d8210ee8e9@github.com>
References: <PUZ-VNLsAs748dp0p0fknfkp6VxzSZRvBXp3cJvheko=.101c475e-a097-47ee-8ead-3464def85d7a@github.com>
 <Oq3b-RXjrUQa3je7gtFx5yp03T9Pqqsofb5c4Mmz4Pg=.53e4b5ec-d377-415f-95e4-27d8210ee8e9@github.com>
Message-ID: <cr1iWZjlPNM3NP67c0HF4kZNYZ5qoaChx5BpC_frh90=.e390b436-4aa2-484c-81fc-364557839f06@github.com>

On Thu, 8 Jun 2023 09:55:44 GMT, Afshin Zafari <azafari at openjdk.org> wrote:

>> The `uintx/intx` options whose ranges are small enough are changed to `uint/int`, otherwise gcc complains 
>> when `-Wconversion` is used in build.
>> Their uses in printf formats are changed accordingly.
>> 
>> ### Tests
>> Locally hotspot:tier1 tested on linux-x64
>> mach5 tiers 1-4 on Linux and Windows 64bits platforms passed.
>
> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review comments applied

Changes requested by kbarrett (Reviewer).

src/hotspot/share/gc/g1/g1ConcurrentMark.cpp line 2311:

> 2309:   size_t target_size;
> 2310:   if (partially) {
> 2311:     target_size = MIN2((size_t)_task_queue->max_elems()/3, GCDrainStackTargetSize);

I was hoping max_elems() wouldn't need a cast.  Fixing that seems like it might be one of those long
and more complicated threads I was referring to earlier.

src/hotspot/share/gc/shared/gcOverheadChecker.cpp line 98:

> 96:     } else if (print_gc_overhead_limit_would_be_exceeded) {
> 97:       assert(_gc_overhead_limit_count > 0, "Should not be printing");
> 98:       log_trace(gc, ergo)("GC would exceed overhead limit of %u %% %d consecutive time(s)",

An extra space has been added before "%%"; please remove.

src/hotspot/share/gc/shared/gc_globals.hpp line 215:

> 213:   product(size_t, MarkStackSizeMax, NOT_LP64(4*M) LP64_ONLY(512*M),         \
> 214:           "Maximum size of marking stack")                                  \
> 215:           range(1, (SIZE_MAX - 1))                                          \

This is a large increase in the max size.  Not at all sure it's appropriate.  Similarly for MarkStackSize below.

src/hotspot/share/gc/shared/gc_globals.hpp line 688:

> 686:           "Number of entries we will try to leave on the stack "            \
> 687:           "during parallel gc")                                             \
> 688:           range(0, SIZE_MAX)                                                \

This is a large increase in the max on 64bit platforms.

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

PR Review: https://git.openjdk.org/jdk/pull/14259#pullrequestreview-1471493655
PR Review Comment: https://git.openjdk.org/jdk/pull/14259#discussion_r1224034883
PR Review Comment: https://git.openjdk.org/jdk/pull/14259#discussion_r1224008892
PR Review Comment: https://git.openjdk.org/jdk/pull/14259#discussion_r1224041800
PR Review Comment: https://git.openjdk.org/jdk/pull/14259#discussion_r1224043615

From kbarrett at openjdk.org  Fri Jun  9 09:08:51 2023
From: kbarrett at openjdk.org (Kim Barrett)
Date: Fri, 9 Jun 2023 09:08:51 GMT
Subject: RFR: 8281455: Change JVM options with small ranges from 64 to 32
 bits, for gc_globals.hpp [v2]
In-Reply-To: <_ZMPXReZSPE3pSM3xX0DEFb9e-LrJejAz1Q_aJ8-uJA=.26fd29f8-9199-43ef-80cc-7af62bd2612b@github.com>
References: <PUZ-VNLsAs748dp0p0fknfkp6VxzSZRvBXp3cJvheko=.101c475e-a097-47ee-8ead-3464def85d7a@github.com>
 <XMUVdBeWfiSjnXl3nWjC0Ew01rxKBb_dCV7f8EFtdwE=.4d42e4d6-ea04-46a2-9019-cf895c271290@github.com>
 <lqB8iLQvOz8mpMo2103eL3NNQ_5jSfVg4Aq-Y-YicyU=.c9d3b7e4-bfc0-4e3d-a5ab-7f41ebfee510@github.com>
 <_ZMPXReZSPE3pSM3xX0DEFb9e-LrJejAz1Q_aJ8-uJA=.26fd29f8-9199-43ef-80cc-7af62bd2612b@github.com>
Message-ID: <WO9m9pV9iW-THVCIYBOA_oUM-cgptz_JBTO_8XN-j_U=.69f0b579-6b5e-4180-ab2c-223c7cb2b8f1@github.com>

On Thu, 8 Jun 2023 12:14:55 GMT, Afshin Zafari <azafari at openjdk.org> wrote:

> > There are a lot of uses of the options that have casts, many of which ought to be removable with this change. Some of those might pull more tangled strings, but it would be nice if there was a plan to look at those too.
> 
> During this change, I changed all the cases that I found them to be changed. Would you please, give some examples or some 'search criteria' that I can use to find the cases. Then, I will do them here in this PR or create a new RFE for them. 

I spotted some when looking earlier, but haven't re-found any of them.

>> src/hotspot/share/utilities/globalDefinitions.hpp line 441:
>> 
>>> 439: // max_uintx            0xFFFFFFFF      0xFFFFFFFFFFFFFFFF
>>> 440: 
>>> 441: typedef unsigned int uint;   NEEDS_CLEANUP
>> 
>> Unrelated, but I wonder why this "NEEDS_CLEANUP"?
>
> Maybe, it is because the `uint` is already defined within the guarded lines 149-154: 
> ```C++
> #ifdef __USE_MISC
> /* Old compatibility names for C types.  */
> typedef unsigned long int ulong;
> typedef unsigned short int ushort;
> typedef unsigned int uint;
> #endif

I'm not seeing such a block?  Neither in the current version nor in several recent versions.  And I didn't
find `__USE_MISC` anywhere in the JDK.  I did find what it's for and where it's supposed to come from:
https://stackoverflow.com/questions/10231885/what-is-use-misc-macro-used-for

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

PR Comment: https://git.openjdk.org/jdk/pull/14259#issuecomment-1584231384
PR Review Comment: https://git.openjdk.org/jdk/pull/14259#discussion_r1224023784

From ayang at openjdk.org  Fri Jun  9 13:59:48 2023
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Fri, 9 Jun 2023 13:59:48 GMT
Subject: RFR: 8140326: G1: Consider putting regions where evacuation failed
 into next collection set [v4]
In-Reply-To: <siD6FS-fypLat5u9YQDYdzP6z2-8PiCzsn2xqMRXJc4=.55fa90c6-72c3-4442-a228-fef52bab717c@github.com>
References: <mmq6sEkAicO7Mc5FKkk5tcRVJDU6qtjYoyySho56F80=.aea5db50-0ec5-4e27-944e-2750af3d0bd7@github.com>
 <siD6FS-fypLat5u9YQDYdzP6z2-8PiCzsn2xqMRXJc4=.55fa90c6-72c3-4442-a228-fef52bab717c@github.com>
Message-ID: <6B_KdGAaJUpyWL-h452IY0QLUWgjJhR_-6UvtiTdAL0=.7c5acee1-562d-4657-995c-11b3574b9819@github.com>

On Tue, 6 Jun 2023 08:13:42 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> This change adds management of retained regions, i.e. trying to evacuate evacuation failed regions asap.
>> 
>> The advantage is that evacuation failed regions do not need to wait until the next marking to be cleaned out; as they are often very sparsely occupied (often being eden regions), this occupies a lot of space, potentially causing additional evacuation failures later on.
>> Another use of this change will be region pinning, which are basically evacuation failed regions that can not be reclaimed as long as they are pinned - however as soon as they are unpinned, they should be reclaimed for the same reasons as well.
>> 
>> It consists of several behavioral changes:
>> 
>> During garbage collection:
>> 
>> ... in the Evacuation phase:
>> * always collect dirty cards into evacuation failed regions proactively. In tests, the amount of cards/live objects per evacuation failed region is typically very small. Dirty cards are always put into the global refinement buffer immediately, assuming that we will keep most if not all evacuation failed regions.
>> 
>> ... during Post Evacuation 2/Free Collection Set phase:
>> * determine whether the region will be retained (kept for "immediate" evacuation) or not. Highly occupied regions are assumed to stay (mostly) live at least until the next marking, so do not bother with them.
>> 
>> These "retained" regions are collected in a new "from retained" set in the collection set candidates and managed separately from "from marking" regions. Having the "from retained" and "from marking" sets separate in the collection set candidates is easier to manage than to use a single list and the picking stuff from it. Particularly wrt to making sure that mixed gcs preferentially pick from the "from marking" list first, then second from the "from retained" list.
>> 
>> ... determining the collection set during the pause:
>>   * during gc, the collection set is preferentially (first) populated with regions from the "from marking" candidates (these are the important regions to get cleaned out), second from the "from retained" list.
>>   * g1 reserves up to 20% of max gc pause time for retained regions as optional candidates (this is a random number) to make sure that these are cleared out asap to free memory. There is also a minimum number of regions to take from the retained regions list.
>> 
>> During marking
>> 
>> ... changes to marking proper
>> * retained regions will not be marked through during concurrent mark, i.e. they are considered outside of ...
>
> Thomas Schatzl has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - More debug option removal
>  - Remove debug options for tests

src/hotspot/share/gc/g1/g1CollectionSetCandidates.hpp line 138:

> 136: 
> 137: // Iterator for G1CollectionSetCandidates. Multiplexes across the marking/retained
> 138: // region lists based on gc efficiency.

Why does the iteration require ordering? Going through its use sites, I find they just need to perform SIMD like op on each element regardless of the order.

src/hotspot/share/gc/g1/g1Policy.cpp line 516:

> 514: }
> 515: 
> 516: double G1Policy::predict_retained_regions_evac_time() const {

Seems that the result is only for log-print in its sole caller, `predict_base_time_ms`. However, it's also odd that this method is called there at all.

src/hotspot/share/gc/g1/g1Policy.cpp line 655:

> 653: 
> 654:   size_t threshold = G1MixedGCLiveThresholdPercent * HeapRegion::GrainBytes / 100;
> 655:   return live_bytes < threshold;

If the region was Old at gc-start, it would have passed through the same criteria to be in cset; if the region was Young at gc-start, using a threshold meant only for Old-region is questionable, IMO.

Could retaining be performed unconditionally for now based on the assumption that evac-fail regions are sparse?

src/hotspot/share/gc/g1/g1YoungGCPostEvacuateTasks.cpp line 357:

> 355:         g1h->clear_bitmap_for_region(r);
> 356:         r->reset_top_at_mark_start();
> 357:         cm->clear_statistics(r);

I don't get why tams and CM-related data-structure need to be cleared here; shouldn't they be handled inside `G1ClearBitmapClosure` already? (On a higher reasoning, evac-fail processing shouldn't interact with CM; I am assuming the bitmap is not related to CM.)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14220#discussion_r1224289903
PR Review Comment: https://git.openjdk.org/jdk/pull/14220#discussion_r1224342203
PR Review Comment: https://git.openjdk.org/jdk/pull/14220#discussion_r1224188917
PR Review Comment: https://git.openjdk.org/jdk/pull/14220#discussion_r1224198102

From iwalulya at openjdk.org  Fri Jun  9 14:32:23 2023
From: iwalulya at openjdk.org (Ivan Walulya)
Date: Fri, 9 Jun 2023 14:32:23 GMT
Subject: RFR: 8308507: G1: GClocker induced GCs can starve threads
 requiring memory leading to OOME [v8]
In-Reply-To: <OA_NUok57_CwYFRa6FjYHfQpxEIQrxO7tHQ-1VM3Cus=.1621f0a2-7766-41a0-a45b-94c2703ff4bf@github.com>
References: <OA_NUok57_CwYFRa6FjYHfQpxEIQrxO7tHQ-1VM3Cus=.1621f0a2-7766-41a0-a45b-94c2703ff4bf@github.com>
Message-ID: <Ubn3DObVSnZxdHqkBR4AkMk8qo3bqFuRfRDZAkNjS90=.b264905d-a7f2-4f5a-976f-debac6386c70@github.com>

> Please review this change which fixes the thread starvation problem during allocation for G1.
> 
> The starvation problem is not limited to GCLocker, however, currently, it manifests as an OOME only when GCLocker is active. In other cases, the starvation only affects the "starved" thread as it may loop indefinitely. 
> 
> Starvation with an active GCLocker happens as below:
> 
> 1. Thread A tries to allocate memory as normal, and tries to start a GC; the GCLocker is active and so the thread gets stalled waiting for the GC.
> 2. GCLocker induced GC executes and frees some memory.
> 3. Thread A does not get any of that memory, but other threads also waiting for memory.
> 4. Goto 1 until the gclocker retry count has been reached.
> 
> In this change, we take the general approach to solving starvation problems with announcement tables (request queues). On slow allocation, a thread that wishes to complete an Allocation GC and then attempt an allocation, announces its allocation request before proceeding to participate in a race to execute a GC safepoint. Whichever thread succeeds in executing the Allocation GC safepoint will be tasked with completing all allocation requests that were announced before the safepoint. This guarantees that all announced allocation requests are either satisfied during the safepoint, or failed in case there is not enough memory to complete all requests. This effectively deals with the starvation issue and reduces the number of allocation GCs triggered.
> 
> Note: The change also adopts ZList from ZGC and makes it available under utilities as DoublyLinkedList with slight modifications. 
> 
> Testing: Tier 1-7

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

  possible starvation

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14077/files
  - new: https://git.openjdk.org/jdk/pull/14077/files/06687557..cad274ff

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

  Stats: 104 lines in 3 files changed: 55 ins; 31 del; 18 mod
  Patch: https://git.openjdk.org/jdk/pull/14077.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14077/head:pull/14077

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

From coleenp at openjdk.org  Fri Jun  9 14:48:46 2023
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 9 Jun 2023 14:48:46 GMT
Subject: RFR: 8281455: Change JVM options with small ranges from 64 to 32
 bits, for gc_globals.hpp [v3]
In-Reply-To: <Oq3b-RXjrUQa3je7gtFx5yp03T9Pqqsofb5c4Mmz4Pg=.53e4b5ec-d377-415f-95e4-27d8210ee8e9@github.com>
References: <PUZ-VNLsAs748dp0p0fknfkp6VxzSZRvBXp3cJvheko=.101c475e-a097-47ee-8ead-3464def85d7a@github.com>
 <Oq3b-RXjrUQa3je7gtFx5yp03T9Pqqsofb5c4Mmz4Pg=.53e4b5ec-d377-415f-95e4-27d8210ee8e9@github.com>
Message-ID: <AKv90iCj3QtL-Z12XioSlEWOUKLFrK6urUFL916LZKI=.2e6b3888-2c90-43e4-9191-70622676e13e@github.com>

On Thu, 8 Jun 2023 09:55:44 GMT, Afshin Zafari <azafari at openjdk.org> wrote:

>> The `uintx/intx` options whose ranges are small enough are changed to `uint/int`, otherwise gcc complains 
>> when `-Wconversion` is used in build.
>> Their uses in printf formats are changed accordingly.
>> 
>> ### Tests
>> Locally hotspot:tier1 tested on linux-x64
>> mach5 tiers 1-4 on Linux and Windows 64bits platforms passed.
>
> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review comments applied

I have a few comments.  Narrowing the types of these arguments was to prevent Wconversion warnings where they're used and then later narrowed to 32 bit ints.  From my sampling of some of the arguments changed, there were no casts, which was the problem.  Some of these (sample GCTimeLimit) are promoted back up to uintx but having the field be the narrowest representation allows the code to use it without an implicit conversion to a narrower int type.  So I think this is a good step for cleaning up the int types.

src/hotspot/share/gc/shared/gc_globals.hpp line 395:

> 393:   product(uint, PausePadding, 1,                                            \
> 394:           "How much buffer to keep for pause time")                         \
> 395:           range(0, UINT_MAX)                                                \

Why did you change from max_juint -> UINT_MAX ?  max_juint should have compile without integer size mismatch.

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

PR Review: https://git.openjdk.org/jdk/pull/14259#pullrequestreview-1472203649
PR Review Comment: https://git.openjdk.org/jdk/pull/14259#discussion_r1224361701

From coleenp at openjdk.org  Fri Jun  9 14:48:48 2023
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 9 Jun 2023 14:48:48 GMT
Subject: RFR: 8281455: Change JVM options with small ranges from 64 to 32
 bits, for gc_globals.hpp [v3]
In-Reply-To: <AKv90iCj3QtL-Z12XioSlEWOUKLFrK6urUFL916LZKI=.2e6b3888-2c90-43e4-9191-70622676e13e@github.com>
References: <PUZ-VNLsAs748dp0p0fknfkp6VxzSZRvBXp3cJvheko=.101c475e-a097-47ee-8ead-3464def85d7a@github.com>
 <Oq3b-RXjrUQa3je7gtFx5yp03T9Pqqsofb5c4Mmz4Pg=.53e4b5ec-d377-415f-95e4-27d8210ee8e9@github.com>
 <AKv90iCj3QtL-Z12XioSlEWOUKLFrK6urUFL916LZKI=.2e6b3888-2c90-43e4-9191-70622676e13e@github.com>
Message-ID: <gRRWI5-ES8beW87gd_1JuSALxUz6ke71nXGGtIgv7nI=.52c2726c-0f45-44c4-a818-e0d84093de55@github.com>

On Fri, 9 Jun 2023 14:11:49 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   review comments applied
>
> src/hotspot/share/gc/shared/gc_globals.hpp line 395:
> 
>> 393:   product(uint, PausePadding, 1,                                            \
>> 394:           "How much buffer to keep for pause time")                         \
>> 395:           range(0, UINT_MAX)                                                \
> 
> Why did you change from max_juint -> UINT_MAX ?  max_juint should have compile without integer size mismatch.

Or, not in this change, but should we prefer UINT_MAX (found in /usr/include/limits.h) to our globalDefinitions.hpp definitions?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14259#discussion_r1224393681

From coleenp at openjdk.org  Fri Jun  9 14:48:50 2023
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 9 Jun 2023 14:48:50 GMT
Subject: RFR: 8281455: Change JVM options with small ranges from 64 to 32
 bits, for gc_globals.hpp [v3]
In-Reply-To: <cr1iWZjlPNM3NP67c0HF4kZNYZ5qoaChx5BpC_frh90=.e390b436-4aa2-484c-81fc-364557839f06@github.com>
References: <PUZ-VNLsAs748dp0p0fknfkp6VxzSZRvBXp3cJvheko=.101c475e-a097-47ee-8ead-3464def85d7a@github.com>
 <Oq3b-RXjrUQa3je7gtFx5yp03T9Pqqsofb5c4Mmz4Pg=.53e4b5ec-d377-415f-95e4-27d8210ee8e9@github.com>
 <cr1iWZjlPNM3NP67c0HF4kZNYZ5qoaChx5BpC_frh90=.e390b436-4aa2-484c-81fc-364557839f06@github.com>
Message-ID: <9qzT9Lt7ecfEB269kxrMEJe55tgNk5ZrE3mqLUCLQ1o=.79188521-ba30-4c80-954f-f989b955510e@github.com>

On Fri, 9 Jun 2023 09:02:56 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   review comments applied
>
> src/hotspot/share/gc/shared/gc_globals.hpp line 688:
> 
>> 686:           "Number of entries we will try to leave on the stack "            \
>> 687:           "during parallel gc")                                             \
>> 688:           range(0, SIZE_MAX)                                                \
> 
> This is a large increase in the max on 64bit platforms.

Yes, you should revert the change from max_juint to SIZE_MAX.  Is the change to size_t a cleanup to remove a cast?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14259#discussion_r1224363510

From coleenp at openjdk.org  Fri Jun  9 14:48:52 2023
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 9 Jun 2023 14:48:52 GMT
Subject: RFR: 8281455: Change JVM options with small ranges from 64 to 32
 bits, for gc_globals.hpp [v2]
In-Reply-To: <WO9m9pV9iW-THVCIYBOA_oUM-cgptz_JBTO_8XN-j_U=.69f0b579-6b5e-4180-ab2c-223c7cb2b8f1@github.com>
References: <PUZ-VNLsAs748dp0p0fknfkp6VxzSZRvBXp3cJvheko=.101c475e-a097-47ee-8ead-3464def85d7a@github.com>
 <XMUVdBeWfiSjnXl3nWjC0Ew01rxKBb_dCV7f8EFtdwE=.4d42e4d6-ea04-46a2-9019-cf895c271290@github.com>
 <lqB8iLQvOz8mpMo2103eL3NNQ_5jSfVg4Aq-Y-YicyU=.c9d3b7e4-bfc0-4e3d-a5ab-7f41ebfee510@github.com>
 <_ZMPXReZSPE3pSM3xX0DEFb9e-LrJejAz1Q_aJ8-uJA=.26fd29f8-9199-43ef-80cc-7af62bd2612b@github.com>
 <WO9m9pV9iW-THVCIYBOA_oUM-cgptz_JBTO_8XN-j_U=.69f0b579-6b5e-4180-ab2c-223c7cb2b8f1@github.com>
Message-ID: <u779K6r5ZiaojL_5nNXp8op9iL4sgkBj72iY0mw550I=.70e615dc-8b83-4ae5-9b09-d501565907bc@github.com>

On Fri, 9 Jun 2023 08:44:38 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Maybe, it is because the `uint` is already defined within the guarded lines 149-154: 
>> ```C++
>> #ifdef __USE_MISC
>> /* Old compatibility names for C types.  */
>> typedef unsigned long int ulong;
>> typedef unsigned short int ushort;
>> typedef unsigned int uint;
>> #endif
>
> I'm not seeing such a block?  Neither in the current version nor in several recent versions.  And I didn't
> find `__USE_MISC` anywhere in the JDK.  I did find what it's for and where it's supposed to come from:
> https://stackoverflow.com/questions/10231885/what-is-use-misc-macro-used-for

I was curious and found it in /usr/include/x86_64-linux-gnu/sys/types.h on ubuntu. I guess it needs cleanup because it might not be defined with USE_MISC?  There are too many int type names to choose from for int.  Why does it say "Old compatibility names for C types."? Should we even be using uint ? I don't see it in https://en.cppreference.com/w/cpp/language/types - should we prefer "unsigned"?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14259#discussion_r1224382277

From coleenp at openjdk.org  Fri Jun  9 17:41:47 2023
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 9 Jun 2023 17:41:47 GMT
Subject: RFR: 8281455: Change JVM options with small ranges from 64 to 32
 bits, for gc_globals.hpp [v3]
In-Reply-To: <gRRWI5-ES8beW87gd_1JuSALxUz6ke71nXGGtIgv7nI=.52c2726c-0f45-44c4-a818-e0d84093de55@github.com>
References: <PUZ-VNLsAs748dp0p0fknfkp6VxzSZRvBXp3cJvheko=.101c475e-a097-47ee-8ead-3464def85d7a@github.com>
 <Oq3b-RXjrUQa3je7gtFx5yp03T9Pqqsofb5c4Mmz4Pg=.53e4b5ec-d377-415f-95e4-27d8210ee8e9@github.com>
 <AKv90iCj3QtL-Z12XioSlEWOUKLFrK6urUFL916LZKI=.2e6b3888-2c90-43e4-9191-70622676e13e@github.com>
 <gRRWI5-ES8beW87gd_1JuSALxUz6ke71nXGGtIgv7nI=.52c2726c-0f45-44c4-a818-e0d84093de55@github.com>
Message-ID: <ZeL8bUHU6UHL_l_N_tfIixeptaE7Qc6QrMqJjjIlMi0=.75339b56-9b58-473d-ba07-992718ab7e5d@github.com>

On Fri, 9 Jun 2023 14:36:29 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> src/hotspot/share/gc/shared/gc_globals.hpp line 395:
>> 
>>> 393:   product(uint, PausePadding, 1,                                            \
>>> 394:           "How much buffer to keep for pause time")                         \
>>> 395:           range(0, UINT_MAX)                                                \
>> 
>> Why did you change from max_juint -> UINT_MAX ?  max_juint should have compile without integer size mismatch.
>
> Or, not in this change, but should we prefer UINT_MAX (found in /usr/include/limits.h) to our globalDefinitions.hpp definitions?

Now I see Thomas's comments about this.  I guess changing a couple at a time would be ok.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14259#discussion_r1224583583

From duke at openjdk.org  Fri Jun  9 23:06:12 2023
From: duke at openjdk.org (Ashutosh Mehra)
Date: Fri, 9 Jun 2023 23:06:12 GMT
Subject: RFR: 8309065: Move the logic to determine archive heap location
 from CDS to G1 GC [v4]
In-Reply-To: <Jy8pV1WnLW6fMktk9Jmx5SF4JDWL8fl1zPNKOpV6FpA=.324de220-9ad8-4316-b871-c2b7dea5e6d2@github.com>
References: <Jy8pV1WnLW6fMktk9Jmx5SF4JDWL8fl1zPNKOpV6FpA=.324de220-9ad8-4316-b871-c2b7dea5e6d2@github.com>
Message-ID: <j-x_2LhZ442Vm8iPVuOXBvclzwfWxuOxwr9fUDpbmTY=.e52d7a70-7e88-4f17-80b3-408c1a877c0a@github.com>

> This patch is the first step towards having a single set of GC APIs for allocating heap space for the archived objects (See https://bugs.openjdk.org/browse/JDK-8296263).
> It moves some of the G1 specific logic from CDS to G1 gc without changing the functionality.
> 
> Changes that add/update GC APIs for handling archive heap would be introduced in upcoming patches.

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

  Add comment to alloc_archive_region()
  
  Signed-off-by: Ashutosh Mehra <asmehra at redhat.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14208/files
  - new: https://git.openjdk.org/jdk/pull/14208/files/82ddb97c..a414c779

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

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

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

From naoto at openjdk.org  Fri Jun  9 23:34:44 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 9 Jun 2023 23:34:44 GMT
Subject: RFR: 8309622: Re-examine the cache mechanism in BaseLocale
Message-ID: <5MqmN4P1TLKDCfXPhKWrH1b2FTgOXmjtKgd1bVXDd_M=.2000f20d-365d-48dc-bc37-45d8bcb9447f@github.com>

This is stemming from the PR: https://github.com/openjdk/jdk/pull/14211 where aggressive GC can cause NPE in `BaseLocale$Key` class. I refactored the in-house cache with WeakHashMap, and removed the Key class as it is no longer needed (thus the original NPE will no longer be possible). Also with the new JMH test case, it gains some performance improvement:

(w/o fix)

Benchmark                       Mode  Cnt      Score     Error  Units
LocaleCache.testForLanguageTag  avgt   20   5781.275 ? 569.580  ns/op
LocaleCache.testLocaleOf        avgt   20  62564.079 ? 406.697  ns/op

(w/ fix)
Benchmark                       Mode  Cnt      Score     Error  Units
LocaleCache.testForLanguageTag  avgt   20   4801.175 ? 371.830  ns/op
LocaleCache.testLocaleOf        avgt   20  60394.652 ? 352.471  ns/op

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

Commit messages:
 - minor comment fix
 - equals/hash fix, constructor simplification
 - Removed Key
 - minor fixup
 - Use WeakHashMap
 - Modified JMH test
 - Added a test variation for the issue
 - added microbenchmark
 - 8309622: Re-examine the cache mechanism in BaseLocale

Changes: https://git.openjdk.org/jdk/pull/14404/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14404&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8309622
  Stats: 244 lines in 3 files changed: 104 ins; 117 del; 23 mod
  Patch: https://git.openjdk.org/jdk/pull/14404.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14404/head:pull/14404

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

From dcubed at openjdk.org  Sat Jun 10 01:48:24 2023
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Sat, 10 Jun 2023 01:48:24 GMT
Subject: RFR: 8309760: ProblemList
 serviceability/jvmti/vthread/FollowReferences/VThreadStackRefTest.java#default
 with ZGC
Message-ID: <SDcAodkSY37z6uyTK97I9jN0691fO6cFYKIlYyRffWY=.2f42d277-2913-45e0-ae93-d28df696a2a3@github.com>

A trivial fix to ProblemList serviceability/jvmti/vthread/FollowReferences/VThreadStackRefTest.java#default with ZGC

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

Commit messages:
 - 8309760: ProblemList serviceability/jvmti/vthread/FollowReferences/VThreadStackRefTest.java#default with ZGC

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

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

From amenkov at openjdk.org  Sat Jun 10 01:58:53 2023
From: amenkov at openjdk.org (Alex Menkov)
Date: Sat, 10 Jun 2023 01:58:53 GMT
Subject: RFR: 8309760: ProblemList
 serviceability/jvmti/vthread/FollowReferences/VThreadStackRefTest.java#default
 with ZGC
In-Reply-To: <SDcAodkSY37z6uyTK97I9jN0691fO6cFYKIlYyRffWY=.2f42d277-2913-45e0-ae93-d28df696a2a3@github.com>
References: <SDcAodkSY37z6uyTK97I9jN0691fO6cFYKIlYyRffWY=.2f42d277-2913-45e0-ae93-d28df696a2a3@github.com>
Message-ID: <mJiISwaEzlTcIqhs-fwZFJ90UpSCPxdDpndTjmYg-nE=.74a9ba7f-2086-450e-923b-7d413c9dcc0a@github.com>

On Sat, 10 Jun 2023 01:42:17 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList serviceability/jvmti/vthread/FollowReferences/VThreadStackRefTest.java#default with ZGC

Marked as reviewed by amenkov (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/14406#pullrequestreview-1473266693

From dcubed at openjdk.org  Sat Jun 10 02:06:04 2023
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Sat, 10 Jun 2023 02:06:04 GMT
Subject: Integrated: 8309760: ProblemList
 serviceability/jvmti/vthread/FollowReferences/VThreadStackRefTest.java#default
 with ZGC
In-Reply-To: <SDcAodkSY37z6uyTK97I9jN0691fO6cFYKIlYyRffWY=.2f42d277-2913-45e0-ae93-d28df696a2a3@github.com>
References: <SDcAodkSY37z6uyTK97I9jN0691fO6cFYKIlYyRffWY=.2f42d277-2913-45e0-ae93-d28df696a2a3@github.com>
Message-ID: <6RX4a7jcsn-oN1K4anLDvK4Rihx58vMULQ6cyFe1spA=.7258f4ae-6ee0-4aab-8636-94e140cc460c@github.com>

On Sat, 10 Jun 2023 01:42:17 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList serviceability/jvmti/vthread/FollowReferences/VThreadStackRefTest.java#default with ZGC

This pull request has now been integrated.

Changeset: aace3dc2
Author:    Daniel D. Daugherty <dcubed at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/aace3dc28c577bae67a6a1d376a514740d752928
Stats:     1 line in 1 file changed: 1 ins; 0 del; 0 mod

8309760: ProblemList serviceability/jvmti/vthread/FollowReferences/VThreadStackRefTest.java#default with ZGC

Reviewed-by: amenkov

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

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

From dcubed at openjdk.org  Sat Jun 10 02:06:04 2023
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Sat, 10 Jun 2023 02:06:04 GMT
Subject: RFR: 8309760: ProblemList
 serviceability/jvmti/vthread/FollowReferences/VThreadStackRefTest.java#default
 with ZGC
In-Reply-To: <mJiISwaEzlTcIqhs-fwZFJ90UpSCPxdDpndTjmYg-nE=.74a9ba7f-2086-450e-923b-7d413c9dcc0a@github.com>
References: <SDcAodkSY37z6uyTK97I9jN0691fO6cFYKIlYyRffWY=.2f42d277-2913-45e0-ae93-d28df696a2a3@github.com>
 <mJiISwaEzlTcIqhs-fwZFJ90UpSCPxdDpndTjmYg-nE=.74a9ba7f-2086-450e-923b-7d413c9dcc0a@github.com>
Message-ID: <qUxlb3Ck_hHXYw_ygPBjcT0cZIEb513i1fQE8NyHu-A=.19ce48f9-84ac-44bb-be08-972059a6cbed@github.com>

On Sat, 10 Jun 2023 01:55:44 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> A trivial fix to ProblemList serviceability/jvmti/vthread/FollowReferences/VThreadStackRefTest.java#default with ZGC
>
> Marked as reviewed by amenkov (Reviewer).

@alexmenkov - Thanks for the Friday night review!

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

PR Comment: https://git.openjdk.org/jdk/pull/14406#issuecomment-1585423592

From iwalulya at openjdk.org  Sat Jun 10 11:00:30 2023
From: iwalulya at openjdk.org (Ivan Walulya)
Date: Sat, 10 Jun 2023 11:00:30 GMT
Subject: RFR: 8308507: G1: GClocker induced GCs can starve threads
 requiring memory leading to OOME [v9]
In-Reply-To: <OA_NUok57_CwYFRa6FjYHfQpxEIQrxO7tHQ-1VM3Cus=.1621f0a2-7766-41a0-a45b-94c2703ff4bf@github.com>
References: <OA_NUok57_CwYFRa6FjYHfQpxEIQrxO7tHQ-1VM3Cus=.1621f0a2-7766-41a0-a45b-94c2703ff4bf@github.com>
Message-ID: <KwOa1q0DYhfikS_WDMyBngEd6DOF6gr3MN32AKuHvNg=.9fd875d6-162e-4e06-aeea-39c3b2b89044@github.com>

> Please review this change which fixes the thread starvation problem during allocation for G1.
> 
> The starvation problem is not limited to GCLocker, however, currently, it manifests as an OOME only when GCLocker is active. In other cases, the starvation only affects the "starved" thread as it may loop indefinitely. 
> 
> Starvation with an active GCLocker happens as below:
> 
> 1. Thread A tries to allocate memory as normal, and tries to start a GC; the GCLocker is active and so the thread gets stalled waiting for the GC.
> 2. GCLocker induced GC executes and frees some memory.
> 3. Thread A does not get any of that memory, but other threads also waiting for memory.
> 4. Goto 1 until the gclocker retry count has been reached.
> 
> In this change, we take the general approach to solving starvation problems with announcement tables (request queues). On slow allocation, a thread that wishes to complete an Allocation GC and then attempt an allocation, announces its allocation request before proceeding to participate in a race to execute a GC safepoint. Whichever thread succeeds in executing the Allocation GC safepoint will be tasked with completing all allocation requests that were announced before the safepoint. This guarantees that all announced allocation requests are either satisfied during the safepoint, or failed in case there is not enough memory to complete all requests. This effectively deals with the starvation issue and reduces the number of allocation GCs triggered.
> 
> Note: The change also adopts ZList from ZGC and makes it available under utilities as DoublyLinkedList with slight modifications. 
> 
> Testing: Tier 1-7

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

  reset attempt_allocation_after_gc to word_size parameter

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14077/files
  - new: https://git.openjdk.org/jdk/pull/14077/files/cad274ff..966cab92

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

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

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

From dcubed at openjdk.org  Sat Jun 10 14:40:54 2023
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Sat, 10 Jun 2023 14:40:54 GMT
Subject: RFR: 8309760: ProblemList
 serviceability/jvmti/vthread/FollowReferences/VThreadStackRefTest.java#default
 with ZGC
Message-ID: <jVEeoj36rEaiVVUIVs5SroIu4d--YLtsWRgfLlP9_tE=.f0aa8eb3-73f5-46bf-8cec-6942002f7fdd@github.com>

8309760: ProblemList serviceability/jvmti/vthread/FollowReferences/VThreadStackRefTest.java#default with ZGC

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

Commit messages:
 - Backport aace3dc28c577bae67a6a1d376a514740d752928

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

PR: https://git.openjdk.org/jdk21/pull/5

From darcy at openjdk.org  Sat Jun 10 16:39:46 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Sat, 10 Jun 2023 16:39:46 GMT
Subject: RFR: 8309760: ProblemList
 serviceability/jvmti/vthread/FollowReferences/VThreadStackRefTest.java#default
 with ZGC
In-Reply-To: <jVEeoj36rEaiVVUIVs5SroIu4d--YLtsWRgfLlP9_tE=.f0aa8eb3-73f5-46bf-8cec-6942002f7fdd@github.com>
References: <jVEeoj36rEaiVVUIVs5SroIu4d--YLtsWRgfLlP9_tE=.f0aa8eb3-73f5-46bf-8cec-6942002f7fdd@github.com>
Message-ID: <GTMRFmg0jkmOUCfQ-_IKZCT2tJdhyGkFbYxT4Lsh12I=.d4f5bf9f-f85d-40e7-9f63-fe90f7cdbff3@github.com>

On Sat, 10 Jun 2023 14:27:06 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> 8309760: ProblemList serviceability/jvmti/vthread/FollowReferences/VThreadStackRefTest.java#default with ZGC

Marked as reviewed by darcy (Reviewer).

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

PR Review: https://git.openjdk.org/jdk21/pull/5#pullrequestreview-1473453626

From dcubed at openjdk.org  Sat Jun 10 16:39:47 2023
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Sat, 10 Jun 2023 16:39:47 GMT
Subject: Integrated: 8309760: ProblemList
 serviceability/jvmti/vthread/FollowReferences/VThreadStackRefTest.java#default
 with ZGC
In-Reply-To: <jVEeoj36rEaiVVUIVs5SroIu4d--YLtsWRgfLlP9_tE=.f0aa8eb3-73f5-46bf-8cec-6942002f7fdd@github.com>
References: <jVEeoj36rEaiVVUIVs5SroIu4d--YLtsWRgfLlP9_tE=.f0aa8eb3-73f5-46bf-8cec-6942002f7fdd@github.com>
Message-ID: <KMIMAAhUHTDqsBrjYoPwKuTixLjvv2T6NHx4K4weruI=.c2bb9a13-b420-4032-896c-0a72442d80a2@github.com>

On Sat, 10 Jun 2023 14:27:06 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> 8309760: ProblemList serviceability/jvmti/vthread/FollowReferences/VThreadStackRefTest.java#default with ZGC

This pull request has now been integrated.

Changeset: 4bf6babd
Author:    Daniel D. Daugherty <dcubed at openjdk.org>
URL:       https://git.openjdk.org/jdk21/commit/4bf6babda5e20a7d0948100125b9a1705a659402
Stats:     1 line in 1 file changed: 1 ins; 0 del; 0 mod

8309760: ProblemList serviceability/jvmti/vthread/FollowReferences/VThreadStackRefTest.java#default with ZGC

Reviewed-by: darcy
Backport-of: aace3dc28c577bae67a6a1d376a514740d752928

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

PR: https://git.openjdk.org/jdk21/pull/5

From kbarrett at openjdk.org  Sat Jun 10 17:14:28 2023
From: kbarrett at openjdk.org (Kim Barrett)
Date: Sat, 10 Jun 2023 17:14:28 GMT
Subject: RFR: 8309627: Incorrect sorting of DirtyCardQueue buffers [v2]
In-Reply-To: <9qwPHb6DFbJHv3DI4Oabrzu7yB5N0ErFNkk0vI1l_oc=.63378661-5d2c-43e4-a3b0-f4e88c817286@github.com>
References: <9qwPHb6DFbJHv3DI4Oabrzu7yB5N0ErFNkk0vI1l_oc=.63378661-5d2c-43e4-a3b0-f4e88c817286@github.com>
Message-ID: <W4T0Jkll4ePWSb1IZG81a5_xS3MF0EzUEsh8f5NXKNw=.5fe151e4-3c22-4ea2-b23a-174824d0c91e@github.com>

> Please review this simple fix to the sorting of dirty card buffers.  The
> comparison function is using the difference between the card pointer to
> compute the order, but is discarding all but the low 32 bits.
> 
> While I was at it, adjusted the name of the sort function.
> 
> Testing:
> mach5 tier1

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

 - Merge branch 'master' into dcq-sort
 - fix

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14365/files
  - new: https://git.openjdk.org/jdk/pull/14365/files/dadf783d..fbffac70

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

  Stats: 9606 lines in 208 files changed: 8501 ins; 457 del; 648 mod
  Patch: https://git.openjdk.org/jdk/pull/14365.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14365/head:pull/14365

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

From kbarrett at openjdk.org  Sat Jun 10 17:14:30 2023
From: kbarrett at openjdk.org (Kim Barrett)
Date: Sat, 10 Jun 2023 17:14:30 GMT
Subject: RFR: 8309627: Incorrect sorting of DirtyCardQueue buffers [v2]
In-Reply-To: <cFf1-dPe1lJ15M5KdWcFOLT3xIGZTd4A8e8mqgktquM=.2fa30495-a3af-42c2-8359-54070b9595f3@github.com>
References: <9qwPHb6DFbJHv3DI4Oabrzu7yB5N0ErFNkk0vI1l_oc=.63378661-5d2c-43e4-a3b0-f4e88c817286@github.com>
 <cFf1-dPe1lJ15M5KdWcFOLT3xIGZTd4A8e8mqgktquM=.2fa30495-a3af-42c2-8359-54070b9595f3@github.com>
Message-ID: <lW70fs7y5QI-JucSSTMsql3k70jgokd3hiMF5-GSFRU=.4db05800-0bfa-47df-bb62-12de719ac495@github.com>

On Wed, 7 Jun 2023 19:30:39 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Kim Barrett has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
>> 
>>  - Merge branch 'master' into dcq-sort
>>  - fix
>
> Marked as reviewed by ayang (Reviewer).

Thanks for reviews @albertnetymk and @shipilev

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

PR Comment: https://git.openjdk.org/jdk/pull/14365#issuecomment-1585739387

From kbarrett at openjdk.org  Sat Jun 10 17:14:31 2023
From: kbarrett at openjdk.org (Kim Barrett)
Date: Sat, 10 Jun 2023 17:14:31 GMT
Subject: Integrated: 8309627: Incorrect sorting of DirtyCardQueue buffers
In-Reply-To: <9qwPHb6DFbJHv3DI4Oabrzu7yB5N0ErFNkk0vI1l_oc=.63378661-5d2c-43e4-a3b0-f4e88c817286@github.com>
References: <9qwPHb6DFbJHv3DI4Oabrzu7yB5N0ErFNkk0vI1l_oc=.63378661-5d2c-43e4-a3b0-f4e88c817286@github.com>
Message-ID: <8VoJU1mkt3FpCRcKalk3J96JmbxecvfrBS99k1XBqhs=.eed2053f-0a41-45d6-92e8-bad834619116@github.com>

On Wed, 7 Jun 2023 18:02:37 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this simple fix to the sorting of dirty card buffers.  The
> comparison function is using the difference between the card pointer to
> compute the order, but is discarding all but the low 32 bits.
> 
> While I was at it, adjusted the name of the sort function.
> 
> Testing:
> mach5 tier1

This pull request has now been integrated.

Changeset: b94b679e
Author:    Kim Barrett <kbarrett at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b94b679e9a82ff2ee6daee9631ce707e9b9eaf6b
Stats:     3 lines in 1 file changed: 0 ins; 0 del; 3 mod

8309627: Incorrect sorting of DirtyCardQueue buffers

Reviewed-by: ayang, shade

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

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

From dcubed at openjdk.org  Sun Jun 11 01:19:05 2023
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Sun, 11 Jun 2023 01:19:05 GMT
Subject: RFR: 8309760: ProblemList
 serviceability/jvmti/vthread/FollowReferences/VThreadStackRefTest.java#default
 with ZGC
In-Reply-To: <GTMRFmg0jkmOUCfQ-_IKZCT2tJdhyGkFbYxT4Lsh12I=.d4f5bf9f-f85d-40e7-9f63-fe90f7cdbff3@github.com>
References: <jVEeoj36rEaiVVUIVs5SroIu4d--YLtsWRgfLlP9_tE=.f0aa8eb3-73f5-46bf-8cec-6942002f7fdd@github.com>
 <GTMRFmg0jkmOUCfQ-_IKZCT2tJdhyGkFbYxT4Lsh12I=.d4f5bf9f-f85d-40e7-9f63-fe90f7cdbff3@github.com>
Message-ID: <j4YlQ9sfJpDJpWx6Vn-fDAS49IjQpouCRM64LvfjI74=.0dbc988f-a188-4cf2-8473-bf3f9dfce89c@github.com>

On Sat, 10 Jun 2023 16:34:31 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> 8309760: ProblemList serviceability/jvmti/vthread/FollowReferences/VThreadStackRefTest.java#default with ZGC
>
> Marked as reviewed by darcy (Reviewer).

@jddarcy - Thanks for the review.

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

PR Comment: https://git.openjdk.org/jdk21/pull/5#issuecomment-1585930024

From gli at openjdk.org  Sun Jun 11 08:00:05 2023
From: gli at openjdk.org (Guoxiong Li)
Date: Sun, 11 Jun 2023 08:00:05 GMT
Subject: RFR: 8047998: Abort the vm if MaxNewSize is not the same as
 NewSize when MaxHeapSize is the same as InitialHeapSize
In-Reply-To: <72Ws56U5CQtUvtu54vhJGMRbfO87GRq5yNgIAUkhsYo=.eab80189-566f-4625-a6b6-2216f801c44e@github.com>
References: <x0XiQ_v_hgW3zTJeni10F93buDr224ALn-oqzJeH0j8=.48b829a2-dd45-48d1-bbdd-3cfb3037ebea@github.com>
 <WDxLZeT7k2Etw31d_BTVnG8HXfiHxrrWtavbKX5X51c=.69ea4c1d-ea2a-48a5-9362-6d887d05b4b6@github.com>
 <72Ws56U5CQtUvtu54vhJGMRbfO87GRq5yNgIAUkhsYo=.eab80189-566f-4625-a6b6-2216f801c44e@github.com>
Message-ID: <8_SgxgkFwp1aLE3vSYWZgUZDEUP46s2388Iprrd3YZo=.96913f43-9388-475d-935c-3ac54ed58ba2@github.com>

On Mon, 29 May 2023 11:43:08 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>>> OK, maybe sth along these lines:
>>> 
>>> ```c++
>>> if (MaxHeapSize == InitialHeapSize) {
>>>   if (FLAG_IS_CMDLINE(NewSize) && FLAG_IS_CMDLINE(MaxNewSize) && NewSize != MaxNewSize) {
>>>     vm_exit_during_initialization(...);
>>>   }
>>>   ...
>>> }
>>> ```
>>> 
>>> I think exiting here is fine because this is an impossible constraint to satisfy, variable young-gen size in constant whole-heap setup. What do you think?
>> 
>> The condition `MaxHeapSize == InitialHeapSize` is often meet, I don't think it is good to abort the vm. I do worry that such exiting may break some current online systems, which is unacceptable for us (Do nothing is better to break the online systems). Considering the JDK21 is a LTS version, I don't want to do such breaking change.
>
>> The condition MaxHeapSize == InitialHeapSize is often meet
> 
> True, but additionally specifying both `NewSize` and `MaxNewSize` is uncommon, IMO.
> 
>> I do worry that such exiting may break some current online systems
> 
> Actually, I think it's desirable to fail loudly if the JVM cmd flags contain errors. Hard to say whether this is an error or not, but debugging suboptimal performance (from incorrect heap/generation-size) is much harder. Therefore, notifying developers at jvm-startup when cmd flags can't be satisfied might be appreciated. Again, this setup should be rare.
> 
> (I agree this is subjective.)

@albertnetymk Thanks for creating the CSR. It may be good to mark it as `PROPOSED` now.

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

PR Comment: https://git.openjdk.org/jdk/pull/13876#issuecomment-1586062649

From gli at openjdk.org  Mon Jun 12 07:00:54 2023
From: gli at openjdk.org (Guoxiong Li)
Date: Mon, 12 Jun 2023 07:00:54 GMT
Subject: RFR: 8272147: Consolidate preserved marks handling with other STW
 collectors [v5]
In-Reply-To: <6ltfOUwy0V-4cgwFaMlXyiUHsIyB_TktZi1kRtRzgqI=.c45d3747-9610-4d84-ba71-85034dca6004@github.com>
References: <jXZiOVJDgymUKJne7d-LXCpIx7xcPoFPGATHIGSw_HE=.cb5e5aa0-001c-4842-9c16-7cb70e41b8a2@github.com>
 <6ltfOUwy0V-4cgwFaMlXyiUHsIyB_TktZi1kRtRzgqI=.c45d3747-9610-4d84-ba71-85034dca6004@github.com>
Message-ID: <uQCFTyNAoTK3OW7OID6NBgRu-i4CvlvG_ziZgBnRRUg=.91d847d3-1096-4f32-9bf1-882d958b1a5f@github.com>

On Thu, 8 Jun 2023 14:09:08 GMT, Guoxiong Li <gli at openjdk.org> wrote:

>> Hi all,
>> 
>> This patch removes the class `markSweep.hpp::PreservedMark` and uses the shared `PreservedMarksSet` instead.
>> 
>> In order to keep the meaning of the field `_preserved_marks` in `markSweep`,
>> I need to use `OopAndMarkWord` explicitly. So I move `OopAndMarkWord` out of `PreservedMarks`.
>> 
>> Tests:
>> `hotspot:tier1` passed locally (x86 & linux).
>> 
>> Thanks for the review.
>> 
>> Best Regards,
>> -- Guoxiong
>
> Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename OopAndMarkWork to PreservedMark.

Waiting for another review.

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

PR Comment: https://git.openjdk.org/jdk/pull/14274#issuecomment-1586700499

From gli at openjdk.org  Mon Jun 12 07:01:11 2023
From: gli at openjdk.org (Guoxiong Li)
Date: Mon, 12 Jun 2023 07:01:11 GMT
Subject: RFR: 8309403: Serial: Remove the useless adaptive size policy in
 GenCollectedHeap [v4]
In-Reply-To: <MZhLt2ktfE3bDeJLNLasJVrDyWF_K0eL6Fv6mLYjvnc=.0f5c2974-d078-4794-9882-e578acf9ffda@github.com>
References: <AgndfVJuqHKLBUtf3Q8srBUH_BnNnXmxnvTz1rNXuRU=.36ab3363-d8b4-4fe3-b7e5-83f92af37d06@github.com>
 <MZhLt2ktfE3bDeJLNLasJVrDyWF_K0eL6Fv6mLYjvnc=.0f5c2974-d078-4794-9882-e578acf9ffda@github.com>
Message-ID: <GnSGdy8M_ufD8yE06dZ3zSE8YGqRiGwCfwdSg7TmOyQ=.072d5b18-1e24-4d30-956a-6b7c6b0ad6f7@github.com>

On Thu, 8 Jun 2023 13:21:34 GMT, Guoxiong Li <gli at openjdk.org> wrote:

>> Hi all,
>> 
>> This patch removes the useless code related to the `AdaptiveSizePolicy` in `GenCollectedHeap`.
>> As a result, the `SoftRefGenPolicy` is unnecessary too, use `SoftRefPolicy` instead.
>> 
>> Thanks for the review.
>> 
>> Best Regards,
>> -- Guoxiong
>
> Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Treat INCLUDE_G1GC and INCLUDE_SERIALGC as variables.

Waiting for another review.

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

PR Comment: https://git.openjdk.org/jdk/pull/14296#issuecomment-1586700430

From rkennke at openjdk.org  Mon Jun 12 09:35:52 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Mon, 12 Jun 2023 09:35:52 GMT
Subject: RFR: 8272147: Consolidate preserved marks handling with other STW
 collectors [v5]
In-Reply-To: <6ltfOUwy0V-4cgwFaMlXyiUHsIyB_TktZi1kRtRzgqI=.c45d3747-9610-4d84-ba71-85034dca6004@github.com>
References: <jXZiOVJDgymUKJne7d-LXCpIx7xcPoFPGATHIGSw_HE=.cb5e5aa0-001c-4842-9c16-7cb70e41b8a2@github.com>
 <6ltfOUwy0V-4cgwFaMlXyiUHsIyB_TktZi1kRtRzgqI=.c45d3747-9610-4d84-ba71-85034dca6004@github.com>
Message-ID: <tRv0p2WE4_aHlAczQPF_jpGal6pbV9WSQkLa_OTfrxM=.249600fe-5490-45ee-b0ac-3f4abecfc96f@github.com>

On Thu, 8 Jun 2023 14:09:08 GMT, Guoxiong Li <gli at openjdk.org> wrote:

>> Hi all,
>> 
>> This patch removes the class `markSweep.hpp::PreservedMark` and uses the shared `PreservedMarksSet` instead.
>> 
>> In order to keep the meaning of the field `_preserved_marks` in `markSweep`,
>> I need to use `OopAndMarkWord` explicitly. So I move `OopAndMarkWord` out of `PreservedMarks`.
>> 
>> Tests:
>> `hotspot:tier1` passed locally (x86 & linux).
>> 
>> Thanks for the review.
>> 
>> Best Regards,
>> -- Guoxiong
>
> Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename OopAndMarkWork to PreservedMark.

This is a nice improvement! All looks good to me, I only have a relatively minor naming question, I leave it up to you to change it or not.

src/hotspot/share/gc/shared/preservedMarks.hpp line 52:

> 50: class PreservedMarks {
> 51: private:
> 52:   typedef Stack<PreservedMark, mtGC> OopAndMarkWordStack;

You renamed OopAndMarkWord to PreservedMark, which I like. Maybe you also want to rename OopAndMarkWordStack to PreservedMarkStack? Otherwise it looks confusing I think.

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

Marked as reviewed by rkennke (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14274#pullrequestreview-1474471871
PR Review Comment: https://git.openjdk.org/jdk/pull/14274#discussion_r1226366710

From tschatzl at openjdk.org  Mon Jun 12 10:35:53 2023
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Mon, 12 Jun 2023 10:35:53 GMT
Subject: RFR: 8309065: Move the logic to determine archive heap location
 from CDS to G1 GC [v4]
In-Reply-To: <j-x_2LhZ442Vm8iPVuOXBvclzwfWxuOxwr9fUDpbmTY=.e52d7a70-7e88-4f17-80b3-408c1a877c0a@github.com>
References: <Jy8pV1WnLW6fMktk9Jmx5SF4JDWL8fl1zPNKOpV6FpA=.324de220-9ad8-4316-b871-c2b7dea5e6d2@github.com>
 <j-x_2LhZ442Vm8iPVuOXBvclzwfWxuOxwr9fUDpbmTY=.e52d7a70-7e88-4f17-80b3-408c1a877c0a@github.com>
Message-ID: <QgPaFmX6YhzOhUKvB39E_ARlmRzgqhiaRvoOIdft3sg=.017dbd82-984a-435a-81c9-0bdd9194fccf@github.com>

On Fri, 9 Jun 2023 23:06:12 GMT, Ashutosh Mehra <duke at openjdk.org> wrote:

>> This patch is the first step towards having a single set of GC APIs for allocating heap space for the archived objects (See https://bugs.openjdk.org/browse/JDK-8296263).
>> It moves some of the G1 specific logic from CDS to G1 gc without changing the functionality.
>> 
>> Changes that add/update GC APIs for handling archive heap would be introduced in upcoming patches.
>
> Ashutosh Mehra has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add comment to alloc_archive_region()
>   
>   Signed-off-by: Ashutosh Mehra <asmehra at redhat.com>

Marked as reviewed by tschatzl (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/14208#pullrequestreview-1474589622

From ayang at openjdk.org  Mon Jun 12 10:40:00 2023
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Mon, 12 Jun 2023 10:40:00 GMT
Subject: RFR: 8308507: G1: GClocker induced GCs can starve threads
 requiring memory leading to OOME [v9]
In-Reply-To: <KwOa1q0DYhfikS_WDMyBngEd6DOF6gr3MN32AKuHvNg=.9fd875d6-162e-4e06-aeea-39c3b2b89044@github.com>
References: <OA_NUok57_CwYFRa6FjYHfQpxEIQrxO7tHQ-1VM3Cus=.1621f0a2-7766-41a0-a45b-94c2703ff4bf@github.com>
 <KwOa1q0DYhfikS_WDMyBngEd6DOF6gr3MN32AKuHvNg=.9fd875d6-162e-4e06-aeea-39c3b2b89044@github.com>
Message-ID: <RunXW5enpZKPZyzb7HgH9C7O8Ku9PtjkmeNLla3UpRo=.39094197-b305-4d7e-ad82-92d982fb65a2@github.com>

On Sat, 10 Jun 2023 11:00:30 GMT, Ivan Walulya <iwalulya at openjdk.org> wrote:

>> Please review this change which fixes the thread starvation problem during allocation for G1.
>> 
>> The starvation problem is not limited to GCLocker, however, currently, it manifests as an OOME only when GCLocker is active. In other cases, the starvation only affects the "starved" thread as it may loop indefinitely. 
>> 
>> Starvation with an active GCLocker happens as below:
>> 
>> 1. Thread A tries to allocate memory as normal, and tries to start a GC; the GCLocker is active and so the thread gets stalled waiting for the GC.
>> 2. GCLocker induced GC executes and frees some memory.
>> 3. Thread A does not get any of that memory, but other threads also waiting for memory.
>> 4. Goto 1 until the gclocker retry count has been reached.
>> 
>> In this change, we take the general approach to solving starvation problems with announcement tables (request queues). On slow allocation, a thread that wishes to complete an Allocation GC and then attempt an allocation, announces its allocation request before proceeding to participate in a race to execute a GC safepoint. Whichever thread succeeds in executing the Allocation GC safepoint will be tasked with completing all allocation requests that were announced before the safepoint. This guarantees that all announced allocation requests are either satisfied during the safepoint, or failed in case there is not enough memory to complete all requests. This effectively deals with the starvation issue and reduces the number of allocation GCs triggered.
>> 
>> Note: The change also adopts ZList from ZGC and makes it available under utilities as DoublyLinkedList with slight modifications. 
>> 
>> Testing: Tier 1-7
>
> Ivan Walulya has updated the pull request incrementally with one additional commit since the last revision:
> 
>   reset attempt_allocation_after_gc to word_size parameter

src/hotspot/share/gc/g1/g1CollectedHeap.cpp line 486:

> 484:       // VM successfully scheduled a collection which failed to allocate. No
> 485:       // point in trying to allocate further. We'll just return null.
> 486:       log_debug(gc, alloc)("%s: Failed to allocate %zu words", Thread::current()->name(), request.size());

I think non-pending requests logic can be moved outside the while-loop. Combined with `if (!request.pending()){ break; }` inside the heap-lock-critical-region, one can get consistent msg for alloc-failure.

src/hotspot/share/gc/g1/g1CollectedHeap.hpp line 220:

> 218:     void set_state(AllocationState state, HeapWord* result = nullptr) {
> 219:       _state = state;
> 220:       _result = result;

These two fields are accessed by diff threads. I wonder if they should be marked as `volatile`.

src/hotspot/share/gc/g1/g1VMOperations.cpp line 136:

> 134: 
> 135:   // Only if operation was really triggered by an allocation.
> 136:   if (_word_size) {

Better not leave out `> 0`.

src/hotspot/share/utilities/doublyLinkedList.hpp line 71:

> 69: class DoublyLinkedList {
> 70:   static_assert(std::is_default_constructible<T>::value,
> 71:                 "DoublyLinkedList requires default-constructible elements");

It seems a strange requirement on the elem type. Can this be relaxed if `_head` take `DoublyLinkedListNode` type instead (and maybe some other small fixes needed)?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14077#discussion_r1225580834
PR Review Comment: https://git.openjdk.org/jdk/pull/14077#discussion_r1225581811
PR Review Comment: https://git.openjdk.org/jdk/pull/14077#discussion_r1225582646
PR Review Comment: https://git.openjdk.org/jdk/pull/14077#discussion_r1225578291

From iwalulya at openjdk.org  Mon Jun 12 10:50:40 2023
From: iwalulya at openjdk.org (Ivan Walulya)
Date: Mon, 12 Jun 2023 10:50:40 GMT
Subject: RFR: 8309306: G1: Move is_obj_dead from HeapRegion to
 G1CollectedHeap
In-Reply-To: <MYgx_BYquNBhL8TK0_MTTMq5I5gj6Er7bK-ArTwAKaw=.c65bc5fe-25e3-4e4f-896b-b32db18f5d94@github.com>
References: <MYgx_BYquNBhL8TK0_MTTMq5I5gj6Er7bK-ArTwAKaw=.c65bc5fe-25e3-4e4f-896b-b32db18f5d94@github.com>
Message-ID: <Af41yjri1pIgFn9gq119OADKOifBjvP2SKGc-jHZKwI=.3a2c977c-7aff-4cff-8828-07ffeec07047@github.com>

On Thu, 1 Jun 2023 15:05:41 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple refactoring around `HeapRegion::is_obj_dead`.
> 
> Test: hotspot_gc

Minor nit!

src/hotspot/share/gc/g1/heapRegion.hpp line 524:

> 522: 
> 523:   // Determine if an address is in the parsable or the to-be-scrubbed area.
> 524:   inline        bool is_in_parsable_area(const void* const addr) const;

spacing to align method names seems new to me.

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

Marked as reviewed by iwalulya (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14265#pullrequestreview-1474620001
PR Review Comment: https://git.openjdk.org/jdk/pull/14265#discussion_r1226464552

From ayang at openjdk.org  Mon Jun 12 11:16:04 2023
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Mon, 12 Jun 2023 11:16:04 GMT
Subject: RFR: 8309306: G1: Move is_obj_dead from HeapRegion to
 G1CollectedHeap
In-Reply-To: <MYgx_BYquNBhL8TK0_MTTMq5I5gj6Er7bK-ArTwAKaw=.c65bc5fe-25e3-4e4f-896b-b32db18f5d94@github.com>
References: <MYgx_BYquNBhL8TK0_MTTMq5I5gj6Er7bK-ArTwAKaw=.c65bc5fe-25e3-4e4f-896b-b32db18f5d94@github.com>
Message-ID: <6EHgLTCHVqF9S-06X96xQBlqcSU9OTYdCmYGdwnf1ZE=.97b691d6-0f96-4314-b2d7-ccbc59514513@github.com>

On Thu, 1 Jun 2023 15:05:41 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple refactoring around `HeapRegion::is_obj_dead`.
> 
> Test: hotspot_gc

Thanks for the review.

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

PR Comment: https://git.openjdk.org/jdk/pull/14265#issuecomment-1587113712

From ayang at openjdk.org  Mon Jun 12 11:16:09 2023
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Mon, 12 Jun 2023 11:16:09 GMT
Subject: Integrated: 8309306: G1: Move is_obj_dead from HeapRegion to
 G1CollectedHeap
In-Reply-To: <MYgx_BYquNBhL8TK0_MTTMq5I5gj6Er7bK-ArTwAKaw=.c65bc5fe-25e3-4e4f-896b-b32db18f5d94@github.com>
References: <MYgx_BYquNBhL8TK0_MTTMq5I5gj6Er7bK-ArTwAKaw=.c65bc5fe-25e3-4e4f-896b-b32db18f5d94@github.com>
Message-ID: <K97hnmYPsEOyde7Xnd-HElvtVfG7csxjpMQtcD3qsqE=.4bbde496-89bc-4bec-873b-6acb5c0b6f7f@github.com>

On Thu, 1 Jun 2023 15:05:41 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple refactoring around `HeapRegion::is_obj_dead`.
> 
> Test: hotspot_gc

This pull request has now been integrated.

Changeset: fdaa2c40
Author:    Albert Mingkun Yang <ayang at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/fdaa2c40835344a336696656285d8a9705f4a166
Stats:     37 lines in 4 files changed: 7 ins; 18 del; 12 mod

8309306: G1: Move is_obj_dead from HeapRegion to G1CollectedHeap

Reviewed-by: tschatzl, iwalulya

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

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

From ayang at openjdk.org  Mon Jun 12 11:16:07 2023
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Mon, 12 Jun 2023 11:16:07 GMT
Subject: RFR: 8309306: G1: Move is_obj_dead from HeapRegion to
 G1CollectedHeap
In-Reply-To: <Af41yjri1pIgFn9gq119OADKOifBjvP2SKGc-jHZKwI=.3a2c977c-7aff-4cff-8828-07ffeec07047@github.com>
References: <MYgx_BYquNBhL8TK0_MTTMq5I5gj6Er7bK-ArTwAKaw=.c65bc5fe-25e3-4e4f-896b-b32db18f5d94@github.com>
 <Af41yjri1pIgFn9gq119OADKOifBjvP2SKGc-jHZKwI=.3a2c977c-7aff-4cff-8828-07ffeec07047@github.com>
Message-ID: <qlcIlzljw2BQPrrMTdKjtPWvC7cKxMUrUAkOToMbIIk=.108ae940-653f-467c-921c-9aefc9c1b7fb@github.com>

On Mon, 12 Jun 2023 10:47:35 GMT, Ivan Walulya <iwalulya at openjdk.org> wrote:

>> Simple refactoring around `HeapRegion::is_obj_dead`.
>> 
>> Test: hotspot_gc
>
> src/hotspot/share/gc/g1/heapRegion.hpp line 524:
> 
>> 522: 
>> 523:   // Determine if an address is in the parsable or the to-be-scrubbed area.
>> 524:   inline        bool is_in_parsable_area(const void* const addr) const;
> 
> spacing to align method names seems new to me.

There are some in `g1FullCollector.hpp`. I think this alignment groups the identical part while highlights the diff.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14265#discussion_r1226488524

From tschatzl at openjdk.org  Mon Jun 12 11:25:16 2023
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Mon, 12 Jun 2023 11:25:16 GMT
Subject: RFR: 8305896: Alternative full GC forwarding [v47]
In-Reply-To: <E_XzJo4WT0-eCPHr2ceZODvZyum04Oo5yR-ktobo8M0=.38e5aa02-d396-49c4-aff0-55d96bc9e2c3@github.com>
References: <yFs73BPFgB89xCPY4k63X4VTz13N8ELJf1lGQlE6UpA=.85ee4f25-a4ee-41d0-b4c2-ed9ff2cb1bb1@github.com>
 <E_XzJo4WT0-eCPHr2ceZODvZyum04Oo5yR-ktobo8M0=.38e5aa02-d396-49c4-aff0-55d96bc9e2c3@github.com>
Message-ID: <YbCiD5ltZ-vgDYVD1K6oIk1UygtI7pg23gbr46XqtAU=.4abc622d-c156-4be0-89f1-417e6c37ff42@github.com>

On Mon, 22 May 2023 14:37:18 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> Currently, the full-GC modes of Serial, Shenandoah and G1 GCs are forwarding objects by over-writing the object header with the new object location. Unfortunately, for compact object headers ([JDK-8294992](https://bugs.openjdk.org/browse/JDK-8294992)) this would not work, because the crucial class information is also stored in the header, and we could no longer iterate over objects until the headers would be restored. Also, the preserved-headers tables would grow quite large.
>> 
>> I propose to use an alternative algorithm for full-GC (sliding-GC) forwarding that uses a special encoding so that the forwarding information fits into the lowest 32 bits of the header.
>> 
>> It exploits the insight that, with sliding GCs, objects from one region will only ever be forwarded to one of two possible target regions. For this to work, we need to divide the heap into equal-sized regions. This is already the case for Shenandoah and G1, and can easily be overlaid for Serial GC, by assuming either the whole heap as a single region (if it fits) or by using SpaceAlignment-sized virtual regions.
>> 
>> We also build and maintain a table that has N elements, where N is the number of regions. Each entry is two addresses, which are the start-address of the possible target regions for each source region.
>> 
>> With this, forwarding information would be encoded like this:
>>  - Bits 0 and 1: same as before, we put in '11' to indicate that the object is forwarded.
>>  - Bit 2: Used for 'fallback'-forwarding (see below)
>>  - Bit 3: Selects the target region 0 or 1. Look up the base address in the table (see above)
>>  - Bits 4..31 The number of heap words from the target base address
>> 
>> This works well for all sliding GCs in Serial, G1 and Shenandoah. The exception is in G1, there is a special mode called 'serial compaction' which acts as a last-last-ditch effort to squeeze more space out of the heap by re-forwarding the tails of the compaction chains. Unfortunately, this breaks the assumption of the sliding-forwarding-table. When that happens, we initialize a fallback table, which is a simple open hash-table, and set the Bit 2 in the forwarding to indicate that we shall look up the forwardee in the fallback-table.
>> 
>> All the table accesses can be done unsynchronized because:
>> - Serial GC is single-threaded anyway
>> - In G1 and Shenandoah, GC worker threads divide up the work such that each worker does disjoint sets of regions.
>> - G1 serial compaction is single-threaded
>> 
>> The c...
>
> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Specialize full-GC loops to get UseAltGCForwarding flag check out of hot paths

Fwiw, I started picking this (and the follow-ups) up again, but progress may still be a bit spotty due to some recent influx of JDK 21 bugs.

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

PR Review: https://git.openjdk.org/jdk/pull/13582#pullrequestreview-1474677447

From tschatzl at openjdk.org  Mon Jun 12 12:22:42 2023
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Mon, 12 Jun 2023 12:22:42 GMT
Subject: RFR: 8272147: Consolidate preserved marks handling with other STW
 collectors [v5]
In-Reply-To: <6ltfOUwy0V-4cgwFaMlXyiUHsIyB_TktZi1kRtRzgqI=.c45d3747-9610-4d84-ba71-85034dca6004@github.com>
References: <jXZiOVJDgymUKJne7d-LXCpIx7xcPoFPGATHIGSw_HE=.cb5e5aa0-001c-4842-9c16-7cb70e41b8a2@github.com>
 <6ltfOUwy0V-4cgwFaMlXyiUHsIyB_TktZi1kRtRzgqI=.c45d3747-9610-4d84-ba71-85034dca6004@github.com>
Message-ID: <dQcwDYzp_Y43Bv9t69yN-Ervhs1Wtb_-0Ch26fot9gc=.90517691-d9ea-4019-990d-0ac27334b041@github.com>

On Thu, 8 Jun 2023 14:09:08 GMT, Guoxiong Li <gli at openjdk.org> wrote:

>> Hi all,
>> 
>> This patch removes the class `markSweep.hpp::PreservedMark` and uses the shared `PreservedMarksSet` instead.
>> 
>> In order to keep the meaning of the field `_preserved_marks` in `markSweep`,
>> I need to use `OopAndMarkWord` explicitly. So I move `OopAndMarkWord` out of `PreservedMarks`.
>> 
>> Tests:
>> `hotspot:tier1` passed locally (x86 & linux).
>> 
>> Thanks for the review.
>> 
>> Best Regards,
>> -- Guoxiong
>
> Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename OopAndMarkWork to PreservedMark.

Lgtm.
Please fix the naming suggested by @rkennke though before pushing.

src/hotspot/share/gc/shared/preservedMarks.cpp line 45:

> 43: void PreservedMarks::adjust_preserved_mark(PreservedMark* elem) {
> 44:   oop obj = elem->get_oop();
> 45:   if (obj->is_forwarded()) {

Pre-existing: we probably only need to check this because G1 full gc preserves marks during marking, unlike the other collectors which (attempt to) preserve marks for actually forwarded objects.
I'll file an RFE for this.

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

Marked as reviewed by tschatzl (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14274#pullrequestreview-1474790550
PR Review Comment: https://git.openjdk.org/jdk/pull/14274#discussion_r1226577332

From gli at openjdk.org  Mon Jun 12 12:39:24 2023
From: gli at openjdk.org (Guoxiong Li)
Date: Mon, 12 Jun 2023 12:39:24 GMT
Subject: RFR: 8272147: Consolidate preserved marks handling with other STW
 collectors [v6]
In-Reply-To: <jXZiOVJDgymUKJne7d-LXCpIx7xcPoFPGATHIGSw_HE=.cb5e5aa0-001c-4842-9c16-7cb70e41b8a2@github.com>
References: <jXZiOVJDgymUKJne7d-LXCpIx7xcPoFPGATHIGSw_HE=.cb5e5aa0-001c-4842-9c16-7cb70e41b8a2@github.com>
Message-ID: <pRbPx-1XPG7dUlnKboQJdisRGjz60zAdpI0z_BFtP1Y=.dff64f19-e68b-4971-9ba1-b835bca7cb3a@github.com>

> Hi all,
> 
> This patch removes the class `markSweep.hpp::PreservedMark` and uses the shared `PreservedMarksSet` instead.
> 
> In order to keep the meaning of the field `_preserved_marks` in `markSweep`,
> I need to use `OopAndMarkWord` explicitly. So I move `OopAndMarkWord` out of `PreservedMarks`.
> 
> Tests:
> `hotspot:tier1` passed locally (x86 & linux).
> 
> Thanks for the review.
> 
> Best Regards,
> -- Guoxiong

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

  Rename 'OopAndMarkWordStack' to 'PreservedMarkStack'

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14274/files
  - new: https://git.openjdk.org/jdk/pull/14274/files/9225c7d0..ffb7e9f1

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

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

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

From gli at openjdk.org  Mon Jun 12 12:39:29 2023
From: gli at openjdk.org (Guoxiong Li)
Date: Mon, 12 Jun 2023 12:39:29 GMT
Subject: RFR: 8272147: Consolidate preserved marks handling with other STW
 collectors [v5]
In-Reply-To: <tRv0p2WE4_aHlAczQPF_jpGal6pbV9WSQkLa_OTfrxM=.249600fe-5490-45ee-b0ac-3f4abecfc96f@github.com>
References: <jXZiOVJDgymUKJne7d-LXCpIx7xcPoFPGATHIGSw_HE=.cb5e5aa0-001c-4842-9c16-7cb70e41b8a2@github.com>
 <6ltfOUwy0V-4cgwFaMlXyiUHsIyB_TktZi1kRtRzgqI=.c45d3747-9610-4d84-ba71-85034dca6004@github.com>
 <tRv0p2WE4_aHlAczQPF_jpGal6pbV9WSQkLa_OTfrxM=.249600fe-5490-45ee-b0ac-3f4abecfc96f@github.com>
Message-ID: <mA5vxuUkkmy91q6C4-bM9dgKb8_sD-VYvuwVevwMHj0=.83221504-aa4c-43e6-9dda-dedf1521e1a8@github.com>

On Mon, 12 Jun 2023 09:30:58 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Rename OopAndMarkWork to PreservedMark.
>
> src/hotspot/share/gc/shared/preservedMarks.hpp line 52:
> 
>> 50: class PreservedMarks {
>> 51: private:
>> 52:   typedef Stack<PreservedMark, mtGC> OopAndMarkWordStack;
> 
> You renamed OopAndMarkWord to PreservedMark, which I like. Maybe you also want to rename OopAndMarkWordStack to PreservedMarkStack? Otherwise it looks confusing I think.

Fixed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14274#discussion_r1226597663

From duke at openjdk.org  Mon Jun 12 12:46:48 2023
From: duke at openjdk.org (Ashutosh Mehra)
Date: Mon, 12 Jun 2023 12:46:48 GMT
Subject: RFR: 8309065: Move the logic to determine archive heap location
 from CDS to G1 GC [v3]
In-Reply-To: <M4Q8tx5azU88N1zScslx6oZjxQQPRFs0Ao2hfW41-iI=.9bdff767-e0ed-498c-8f6d-52b882649436@github.com>
References: <Jy8pV1WnLW6fMktk9Jmx5SF4JDWL8fl1zPNKOpV6FpA=.324de220-9ad8-4316-b871-c2b7dea5e6d2@github.com>
 <XATqoeHqYdc-FRfVKQqlJP8bsUXN7R9MqueuHQ0HGaQ=.ce7e8c50-c8d1-480e-83d7-c56a13d748a8@github.com>
 <M4Q8tx5azU88N1zScslx6oZjxQQPRFs0Ao2hfW41-iI=.9bdff767-e0ed-498c-8f6d-52b882649436@github.com>
Message-ID: <d28CNpFJ_2THAO0_SK0_U3PlUuiDUucJo2vBCpwTBBA=.40a1077f-06f6-4cc7-a6ae-9c8df27bf46c@github.com>

On Wed, 7 Jun 2023 09:31:55 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> One note, I don't see a clear usage of INCLUDE_CDS and INCLUDE_G1GC, and it predates this patch. Don't we do this anymore? We still want to be buildable without CDS but with G1, and vice versa, right?

Yes, that should be possible. There is already an issue for adding missing INCLUDE_CDS: [JDK-8302989](https://bugs.openjdk.org/browse/JDK-8302989)

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

PR Comment: https://git.openjdk.org/jdk/pull/14208#issuecomment-1587267398

From duke at openjdk.org  Mon Jun 12 12:46:50 2023
From: duke at openjdk.org (Ashutosh Mehra)
Date: Mon, 12 Jun 2023 12:46:50 GMT
Subject: RFR: 8309065: Move the logic to determine archive heap location
 from CDS to G1 GC [v2]
In-Reply-To: <mCyG1aPdMuVyaw7VBwJUzTG-g6IDm_NVJ8zk17B6Qas=.5a4953e1-1576-43b7-b6b1-c4af59d68a93@github.com>
References: <Jy8pV1WnLW6fMktk9Jmx5SF4JDWL8fl1zPNKOpV6FpA=.324de220-9ad8-4316-b871-c2b7dea5e6d2@github.com>
 <ey6eW1-ONjMObQp1jtbC-2jIg1x2CQaRlYaL1GpGyR4=.07039560-65e1-48d0-a6a9-1d5f5e3c13c4@github.com>
 <jBHVW4u8FaDWBW36hKDpaU4tPloYdLnktXP0_ZuCjTI=.576feedf-1983-47be-bd0d-ff1bb849e919@github.com>
 <_wIgfWGtjNLtTm6s9_WsLWWEbLlBsW-xEr1CwBBoM0M=.3ce944c1-23ed-4376-8896-e3a437de17b0@github.com>
 <TnWhtiQtK8m2lQdWjGrGGLiT1n5bpRPss_GL7jIDPhQ=.96375783-23be-40de-8ad8-a9b1d2fc35b1@github.com>
 <GM3W_5oOHDAYGz8KQZSHZUKuhjxfkGDdSchXy2IibX0=.d34f29b5-bde5-4673-b9c0-fee9e6db27db@github.com>
 <qljEa8qPqUSb1EtFqniANmMfYj9BCzMplGFcA3sBsTo=.1d71413a-92de-4da0-9f32-a51aad83f6c2@github.com>
 <mCyG1aPdMuVyaw7VBwJUzTG-g6IDm_NVJ8zk17B6Qas=.5a4953e1-1576-43b7-b6b1-c4af59d68a93@github.com>
Message-ID: <bVQh7f66L-o0-1ITU_MsIjYenqUN8DgAihtR7KbQ90w=.75905eda-f76e-4b56-aeaa-862b62d03663@github.com>

On Fri, 2 Jun 2023 18:59:03 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>>> I think Thomas's point is, the requested range should be passed to the alloc_archive_regions() API, even though the collector may simply ignore it.
>> 
>> @tschatzl @iklam Other collectors may ignore the requested addr, but G1 can just allocate the regions at the requested addr, right? Do we also need the fallback to allocating at the top of heap if for some reason allocation at requested addr fails?
>
>> > I think Thomas's point is, the requested range should be passed to the alloc_archive_regions() API, even though the collector may simply ignore it.
>> 
>> @tschatzl @iklam Other collectors may ignore the requested addr, but G1 can just allocate the regions at the requested addr, right? Do we also need the fallback to allocating at the top of heap if for some reason allocation at requested addr fails?
> 
> Yes, I think we need the fallback. However, I think we can keep the behavior exactly the same in this PR (only allocate at the heap end), and implement the more optimal allocation in a subsequent PR.

Thanks @iklam @tschatzl @tstuefe for reviewing the changes.

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

PR Comment: https://git.openjdk.org/jdk/pull/14208#issuecomment-1587269013

From ayang at openjdk.org  Mon Jun 12 12:51:52 2023
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Mon, 12 Jun 2023 12:51:52 GMT
Subject: RFR: 8309622: Re-examine the cache mechanism in BaseLocale
In-Reply-To: <5MqmN4P1TLKDCfXPhKWrH1b2FTgOXmjtKgd1bVXDd_M=.2000f20d-365d-48dc-bc37-45d8bcb9447f@github.com>
References: <5MqmN4P1TLKDCfXPhKWrH1b2FTgOXmjtKgd1bVXDd_M=.2000f20d-365d-48dc-bc37-45d8bcb9447f@github.com>
Message-ID: <kY1A9vDf0wGk8SfYMgmE6en_3IICLsUpeNHuZUdOyRg=.74f0261d-ab5f-4624-8815-b6f770bb6f99@github.com>

On Fri, 9 Jun 2023 22:17:39 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> This is stemming from the PR: https://github.com/openjdk/jdk/pull/14211 where aggressive GC can cause NPE in `BaseLocale$Key` class. I refactored the in-house cache with WeakHashMap, and removed the Key class as it is no longer needed (thus the original NPE will no longer be possible). Also with the new JMH test case, it gains some performance improvement:
> 
> (w/o fix)
> 
> Benchmark                       Mode  Cnt      Score     Error  Units
> LocaleCache.testForLanguageTag  avgt   20   5781.275 ? 569.580  ns/op
> LocaleCache.testLocaleOf        avgt   20  62564.079 ? 406.697  ns/op
> 
> (w/ fix)
> Benchmark                       Mode  Cnt      Score     Error  Units
> LocaleCache.testForLanguageTag  avgt   20   4801.175 ? 371.830  ns/op
> LocaleCache.testLocaleOf        avgt   20  60394.652 ? 352.471  ns/op

test/hotspot/jtreg/gc/TestAllocHumongousFragment.java line 180:

> 178:  */
> 179: 
> 180: /*

Could you move this block a few lines above (e.g. next to the block of `id=iu-aggressive`) so that similar tests are grouped together?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14404#discussion_r1226617033

From gli at openjdk.org  Mon Jun 12 12:52:51 2023
From: gli at openjdk.org (Guoxiong Li)
Date: Mon, 12 Jun 2023 12:52:51 GMT
Subject: RFR: 8272147: Consolidate preserved marks handling with other STW
 collectors [v4]
In-Reply-To: <tLL7ETljbAqaenK_DlSuXS6bql95_MVzAfMwHPLl5jA=.cf10908c-2aab-42ae-a767-bc80ae95a74d@github.com>
References: <jXZiOVJDgymUKJne7d-LXCpIx7xcPoFPGATHIGSw_HE=.cb5e5aa0-001c-4842-9c16-7cb70e41b8a2@github.com>
 <O23DJGo0RPU69rbtmJmNnuDYm56hyrY1PjZBdhyDJmo=.27948db6-4eb3-40f8-aa8c-2465b6aff1d4@github.com>
 <tLL7ETljbAqaenK_DlSuXS6bql95_MVzAfMwHPLl5jA=.cf10908c-2aab-42ae-a767-bc80ae95a74d@github.com>
Message-ID: <bsP2650SE6XEEHaoMG5nH_xJhBsofFH5yL0WmukjVl4=.8414e4f2-4adf-4466-ab6e-2615a27c874e@github.com>

On Wed, 7 Jun 2023 20:18:48 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add and use 'adjust_preserved_mark'
>
> Marked as reviewed by ayang (Reviewer).

@albertnetymk @rkennke @tschatzl Thanks for the reviews. I will integrate this patch after `Pre-submit tests` passing.

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

PR Comment: https://git.openjdk.org/jdk/pull/14274#issuecomment-1587277024

From tschatzl at openjdk.org  Mon Jun 12 13:18:52 2023
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Mon, 12 Jun 2023 13:18:52 GMT
Subject: RFR: 8309403: Serial: Remove the useless adaptive size policy in
 GenCollectedHeap [v4]
In-Reply-To: <MZhLt2ktfE3bDeJLNLasJVrDyWF_K0eL6Fv6mLYjvnc=.0f5c2974-d078-4794-9882-e578acf9ffda@github.com>
References: <AgndfVJuqHKLBUtf3Q8srBUH_BnNnXmxnvTz1rNXuRU=.36ab3363-d8b4-4fe3-b7e5-83f92af37d06@github.com>
 <MZhLt2ktfE3bDeJLNLasJVrDyWF_K0eL6Fv6mLYjvnc=.0f5c2974-d078-4794-9882-e578acf9ffda@github.com>
Message-ID: <APACDFFH2pvNJTw97qJyv8uO74JrhljU04pDcCH2eIc=.37e63a82-8e02-4887-8e9d-5173304c4b36@github.com>

On Thu, 8 Jun 2023 13:21:34 GMT, Guoxiong Li <gli at openjdk.org> wrote:

>> Hi all,
>> 
>> This patch removes the useless code related to the `AdaptiveSizePolicy` in `GenCollectedHeap`.
>> As a result, the `SoftRefGenPolicy` is unnecessary too, use `SoftRefPolicy` instead.
>> 
>> Thanks for the review.
>> 
>> Best Regards,
>> -- Guoxiong
>
> Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Treat INCLUDE_G1GC and INCLUDE_SERIALGC as variables.

Marked as reviewed by tschatzl (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/14296#pullrequestreview-1474905560

From tschatzl at openjdk.org  Mon Jun 12 13:19:43 2023
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Mon, 12 Jun 2023 13:19:43 GMT
Subject: RFR: 8309538: G1: Move total collection increment from Cleanup to
 Remark
In-Reply-To: <uMB-xwYhtwBWqvVAkaFpTmfYhxTlO_Rzm-XZxo6zsbA=.53ac8ffa-f346-4024-8b16-eebf0428c489@github.com>
References: <uMB-xwYhtwBWqvVAkaFpTmfYhxTlO_Rzm-XZxo6zsbA=.53ac8ffa-f346-4024-8b16-eebf0428c489@github.com>
Message-ID: <6_z0mDW7uBsNEwNiiB_uOc2Yzmg_IDG1ME9m1sZBYRU=.cae0efc8-dae0-47de-88ae-4d20cffca94d@github.com>

On Tue, 6 Jun 2023 13:37:13 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple moving `increment_total_collections` to where empty-region reclaim lives.
> 
> Test: hotspot_gc

Marked as reviewed by tschatzl (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/14334#pullrequestreview-1474907029

From iwalulya at openjdk.org  Mon Jun 12 13:32:52 2023
From: iwalulya at openjdk.org (Ivan Walulya)
Date: Mon, 12 Jun 2023 13:32:52 GMT
Subject: RFR: 8308507: G1: GClocker induced GCs can starve threads
 requiring memory leading to OOME [v10]
In-Reply-To: <OA_NUok57_CwYFRa6FjYHfQpxEIQrxO7tHQ-1VM3Cus=.1621f0a2-7766-41a0-a45b-94c2703ff4bf@github.com>
References: <OA_NUok57_CwYFRa6FjYHfQpxEIQrxO7tHQ-1VM3Cus=.1621f0a2-7766-41a0-a45b-94c2703ff4bf@github.com>
Message-ID: <2meSHY2dSGLyLNXPTeSwOBbsCh6Ki0itMEfh2x-GhUM=.a715c087-a300-452f-b406-04168843b363@github.com>

> Please review this change which fixes the thread starvation problem during allocation for G1.
> 
> The starvation problem is not limited to GCLocker, however, currently, it manifests as an OOME only when GCLocker is active. In other cases, the starvation only affects the "starved" thread as it may loop indefinitely. 
> 
> Starvation with an active GCLocker happens as below:
> 
> 1. Thread A tries to allocate memory as normal, and tries to start a GC; the GCLocker is active and so the thread gets stalled waiting for the GC.
> 2. GCLocker induced GC executes and frees some memory.
> 3. Thread A does not get any of that memory, but other threads also waiting for memory.
> 4. Goto 1 until the gclocker retry count has been reached.
> 
> In this change, we take the general approach to solving starvation problems with announcement tables (request queues). On slow allocation, a thread that wishes to complete an Allocation GC and then attempt an allocation, announces its allocation request before proceeding to participate in a race to execute a GC safepoint. Whichever thread succeeds in executing the Allocation GC safepoint will be tasked with completing all allocation requests that were announced before the safepoint. This guarantees that all announced allocation requests are either satisfied during the safepoint, or failed in case there is not enough memory to complete all requests. This effectively deals with the starvation issue and reduces the number of allocation GCs triggered.
> 
> Note: The change also adopts ZList from ZGC and makes it available under utilities as DoublyLinkedList with slight modifications. 
> 
> Testing: Tier 1-7

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

  clean up

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14077/files
  - new: https://git.openjdk.org/jdk/pull/14077/files/966cab92..eed46881

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

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

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

From ayang at openjdk.org  Mon Jun 12 13:38:52 2023
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Mon, 12 Jun 2023 13:38:52 GMT
Subject: RFR: 8309852: G1: Remove unnecessary assert_empty in
 G1ParScanThreadStateSet destructor
Message-ID: <EdJ05jdBSUPLvQX71f318PL2zlsa87tc4XjtQH--lX0=.86bd04f7-26db-4f56-88f4-f48eeca7b519@github.com>

Trivial removing redundant code.

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

Commit messages:
 - g1-preserved-marks-set-assert

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

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

From iwalulya at openjdk.org  Mon Jun 12 14:13:49 2023
From: iwalulya at openjdk.org (Ivan Walulya)
Date: Mon, 12 Jun 2023 14:13:49 GMT
Subject: RFR: 8309538: G1: Move total collection increment from Cleanup to
 Remark
In-Reply-To: <uMB-xwYhtwBWqvVAkaFpTmfYhxTlO_Rzm-XZxo6zsbA=.53ac8ffa-f346-4024-8b16-eebf0428c489@github.com>
References: <uMB-xwYhtwBWqvVAkaFpTmfYhxTlO_Rzm-XZxo6zsbA=.53ac8ffa-f346-4024-8b16-eebf0428c489@github.com>
Message-ID: <JwLQsagSvp3Q5tNkx6DHGBqm1l25YFcYbu3hQVlft-c=.5148db38-17bd-40ff-9a96-d50806acfa0d@github.com>

On Tue, 6 Jun 2023 13:37:13 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple moving `increment_total_collections` to where empty-region reclaim lives.
> 
> Test: hotspot_gc

Marked as reviewed by iwalulya (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/14334#pullrequestreview-1475033099

From dfuchs at openjdk.org  Mon Jun 12 14:29:50 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 12 Jun 2023 14:29:50 GMT
Subject: RFR: 8309622: Re-examine the cache mechanism in BaseLocale
In-Reply-To: <5MqmN4P1TLKDCfXPhKWrH1b2FTgOXmjtKgd1bVXDd_M=.2000f20d-365d-48dc-bc37-45d8bcb9447f@github.com>
References: <5MqmN4P1TLKDCfXPhKWrH1b2FTgOXmjtKgd1bVXDd_M=.2000f20d-365d-48dc-bc37-45d8bcb9447f@github.com>
Message-ID: <TvCCsF7rNR6_d0nbr9wgFtGzNyq-Ti4BxE9c6kljUz8=.a31f88ea-3a71-4423-bf9b-96c66ca5580f@github.com>

On Fri, 9 Jun 2023 22:17:39 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> This is stemming from the PR: https://github.com/openjdk/jdk/pull/14211 where aggressive GC can cause NPE in `BaseLocale$Key` class. I refactored the in-house cache with WeakHashMap, and removed the Key class as it is no longer needed (thus the original NPE will no longer be possible). Also with the new JMH test case, it gains some performance improvement:
> 
> (w/o fix)
> 
> Benchmark                       Mode  Cnt      Score     Error  Units
> LocaleCache.testForLanguageTag  avgt   20   5781.275 ? 569.580  ns/op
> LocaleCache.testLocaleOf        avgt   20  62564.079 ? 406.697  ns/op
> 
> (w/ fix)
> Benchmark                       Mode  Cnt      Score     Error  Units
> LocaleCache.testForLanguageTag  avgt   20   4801.175 ? 371.830  ns/op
> LocaleCache.testLocaleOf        avgt   20  60394.652 ? 352.471  ns/op

The new code looks much easier to maintain than the old one. I couldn't figure out what the old code was actually trying to do, but reading the new code I now understand what it does. Caching, retrieval, hashCode and equals look good. From the code it's trivial to see that a new normalised BaseLocale will be created if none is found in the cache - so that will assuredly fix the NPE that was experienced previously when the cache was cleared. The main change is that base locales will now be cached using WeakReference rather than SoftReference, and thus probably collected more eagerly, but that actually looks like a positive change. Not a usual reviewer in this area so please get another reviewer before integrating (also I haven't looked at the test).

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

Marked as reviewed by dfuchs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14404#pullrequestreview-1475076367

From dfuchs at openjdk.org  Mon Jun 12 14:37:41 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 12 Jun 2023 14:37:41 GMT
Subject: RFR: 8309622: Re-examine the cache mechanism in BaseLocale
In-Reply-To: <5MqmN4P1TLKDCfXPhKWrH1b2FTgOXmjtKgd1bVXDd_M=.2000f20d-365d-48dc-bc37-45d8bcb9447f@github.com>
References: <5MqmN4P1TLKDCfXPhKWrH1b2FTgOXmjtKgd1bVXDd_M=.2000f20d-365d-48dc-bc37-45d8bcb9447f@github.com>
Message-ID: <lTt_W4Ue-TJX0DRm890f_iScI2Wo902VXROCVIq2VTk=.794888d9-6019-4d7c-bbe0-46d41427e8aa@github.com>

On Fri, 9 Jun 2023 22:17:39 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> This is stemming from the PR: https://github.com/openjdk/jdk/pull/14211 where aggressive GC can cause NPE in `BaseLocale$Key` class. I refactored the in-house cache with WeakHashMap, and removed the Key class as it is no longer needed (thus the original NPE will no longer be possible). Also with the new JMH test case, it gains some performance improvement:
> 
> (w/o fix)
> 
> Benchmark                       Mode  Cnt      Score     Error  Units
> LocaleCache.testForLanguageTag  avgt   20   5781.275 ? 569.580  ns/op
> LocaleCache.testLocaleOf        avgt   20  62564.079 ? 406.697  ns/op
> 
> (w/ fix)
> Benchmark                       Mode  Cnt      Score     Error  Units
> LocaleCache.testForLanguageTag  avgt   20   4801.175 ? 371.830  ns/op
> LocaleCache.testLocaleOf        avgt   20  60394.652 ? 352.471  ns/op

One thing though - WeakHashMap is not thread safe - and I don't see any locks or synchronized to protect access to CACHE. Is that going to cause trouble if two threads compete to add a locale to the map? In other words - how confident are we that the race would be benign?

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

PR Review: https://git.openjdk.org/jdk/pull/14404#pullrequestreview-1475096535

From dfuchs at openjdk.org  Mon Jun 12 14:40:43 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 12 Jun 2023 14:40:43 GMT
Subject: RFR: 8309622: Re-examine the cache mechanism in BaseLocale
In-Reply-To: <5MqmN4P1TLKDCfXPhKWrH1b2FTgOXmjtKgd1bVXDd_M=.2000f20d-365d-48dc-bc37-45d8bcb9447f@github.com>
References: <5MqmN4P1TLKDCfXPhKWrH1b2FTgOXmjtKgd1bVXDd_M=.2000f20d-365d-48dc-bc37-45d8bcb9447f@github.com>
Message-ID: <nw4cq4eBoIjvhodXS-V3HULh5PrdMx6EaG31daNumdw=.05dc657b-3a90-4394-85cd-fff2445d2fb8@github.com>

On Fri, 9 Jun 2023 22:17:39 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> This is stemming from the PR: https://github.com/openjdk/jdk/pull/14211 where aggressive GC can cause NPE in `BaseLocale$Key` class. I refactored the in-house cache with WeakHashMap, and removed the Key class as it is no longer needed (thus the original NPE will no longer be possible). Also with the new JMH test case, it gains some performance improvement:
> 
> (w/o fix)
> 
> Benchmark                       Mode  Cnt      Score     Error  Units
> LocaleCache.testForLanguageTag  avgt   20   5781.275 ? 569.580  ns/op
> LocaleCache.testLocaleOf        avgt   20  62564.079 ? 406.697  ns/op
> 
> (w/ fix)
> Benchmark                       Mode  Cnt      Score     Error  Units
> LocaleCache.testForLanguageTag  avgt   20   4801.175 ? 371.830  ns/op
> LocaleCache.testLocaleOf        avgt   20  60394.652 ? 352.471  ns/op

I think this question should be answered before integrating.

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

Changes requested by dfuchs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14404#pullrequestreview-1475101795

From tschatzl at openjdk.org  Mon Jun 12 14:43:54 2023
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Mon, 12 Jun 2023 14:43:54 GMT
Subject: RFR: 8309852: G1: Remove unnecessary assert_empty in
 G1ParScanThreadStateSet destructor
In-Reply-To: <EdJ05jdBSUPLvQX71f318PL2zlsa87tc4XjtQH--lX0=.86bd04f7-26db-4f56-88f4-f48eeca7b519@github.com>
References: <EdJ05jdBSUPLvQX71f318PL2zlsa87tc4XjtQH--lX0=.86bd04f7-26db-4f56-88f4-f48eeca7b519@github.com>
Message-ID: <t1-RbwRqtb_FN7qIm4VXH0Gz4Z5xVNmaHCcO0yH54xo=.eadabf75-0673-4523-a369-967642737616@github.com>

On Mon, 12 Jun 2023 13:31:20 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Trivial removing redundant code.

Please copy&paste the description of the CR into the PR description for easier reference :)

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

Marked as reviewed by tschatzl (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14417#pullrequestreview-1475109042

From dfuchs at openjdk.org  Mon Jun 12 14:47:49 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 12 Jun 2023 14:47:49 GMT
Subject: RFR: 8309622: Re-examine the cache mechanism in BaseLocale
In-Reply-To: <TvCCsF7rNR6_d0nbr9wgFtGzNyq-Ti4BxE9c6kljUz8=.a31f88ea-3a71-4423-bf9b-96c66ca5580f@github.com>
References: <5MqmN4P1TLKDCfXPhKWrH1b2FTgOXmjtKgd1bVXDd_M=.2000f20d-365d-48dc-bc37-45d8bcb9447f@github.com>
 <TvCCsF7rNR6_d0nbr9wgFtGzNyq-Ti4BxE9c6kljUz8=.a31f88ea-3a71-4423-bf9b-96c66ca5580f@github.com>
Message-ID: <IIbDWS7D9Utzs38_5cnY4pjte1NvtI-u9LJ1bFLnrTY=.0d5f3a99-546c-4bc7-a219-f6db77493b79@github.com>

On Mon, 12 Jun 2023 14:26:34 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> The main change is that base locales will now be cached using WeakReference rather than SoftReference, and thus probably collected more eagerly, but that actually looks like a positive change.

Hmm.... or not. Nothing references the key, so the binding would be immediately eligible for garbage collection.

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

PR Comment: https://git.openjdk.org/jdk/pull/14404#issuecomment-1587493993

From gli at openjdk.org  Mon Jun 12 15:55:07 2023
From: gli at openjdk.org (Guoxiong Li)
Date: Mon, 12 Jun 2023 15:55:07 GMT
Subject: RFR: 8309403: Serial: Remove the useless adaptive size policy in
 GenCollectedHeap [v3]
In-Reply-To: <WsQ13HqNWnUEfpfxIalBr_lWYwREQpbzDvk3-DkNBK8=.2c8110d9-d3e4-445b-a327-387c742412b6@github.com>
References: <AgndfVJuqHKLBUtf3Q8srBUH_BnNnXmxnvTz1rNXuRU=.36ab3363-d8b4-4fe3-b7e5-83f92af37d06@github.com>
 <812_XKkG--eaJggAh0e3WAcTqWdxc9rUkk2dAL1-yMo=.dec5b815-dbb2-4926-b402-0d92b577f452@github.com>
 <WsQ13HqNWnUEfpfxIalBr_lWYwREQpbzDvk3-DkNBK8=.2c8110d9-d3e4-445b-a327-387c742412b6@github.com>
Message-ID: <uIQvT6G7R9in8LA_Zer4_frTWavuSxjEpHKm-VoWHqI=.3e5245b0-fd0f-4930-bd89-aaec6119cd77@github.com>

On Thu, 8 Jun 2023 11:02:33 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove Parallel GC in 'WB_FullGC'
>
> Marked as reviewed by ayang (Reviewer).

@albertnetymk @tschatzl Thanks for the reviews. Integrating.

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

PR Comment: https://git.openjdk.org/jdk/pull/14296#issuecomment-1587606278

From gli at openjdk.org  Mon Jun 12 15:55:08 2023
From: gli at openjdk.org (Guoxiong Li)
Date: Mon, 12 Jun 2023 15:55:08 GMT
Subject: Integrated: 8309403: Serial: Remove the useless adaptive size policy
 in GenCollectedHeap
In-Reply-To: <AgndfVJuqHKLBUtf3Q8srBUH_BnNnXmxnvTz1rNXuRU=.36ab3363-d8b4-4fe3-b7e5-83f92af37d06@github.com>
References: <AgndfVJuqHKLBUtf3Q8srBUH_BnNnXmxnvTz1rNXuRU=.36ab3363-d8b4-4fe3-b7e5-83f92af37d06@github.com>
Message-ID: <rmHGWy_ZkmoUKoW0hV5at-bSHzsNVnw7KsMm69hAcRs=.dce00e7d-a62d-494f-88ad-4362c44502fa@github.com>

On Sat, 3 Jun 2023 07:27:52 GMT, Guoxiong Li <gli at openjdk.org> wrote:

> Hi all,
> 
> This patch removes the useless code related to the `AdaptiveSizePolicy` in `GenCollectedHeap`.
> As a result, the `SoftRefGenPolicy` is unnecessary too, use `SoftRefPolicy` instead.
> 
> Thanks for the review.
> 
> Best Regards,
> -- Guoxiong

This pull request has now been integrated.

Changeset: 6cd166a2
Author:    Guoxiong Li <gli at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/6cd166a2841cc97f458b579d89a37282f73c6ba9
Stats:     118 lines in 6 files changed: 0 ins; 110 del; 8 mod

8309403: Serial: Remove the useless adaptive size policy in GenCollectedHeap

Reviewed-by: ayang, tschatzl

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

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

From gli at openjdk.org  Mon Jun 12 15:56:07 2023
From: gli at openjdk.org (Guoxiong Li)
Date: Mon, 12 Jun 2023 15:56:07 GMT
Subject: Integrated: 8272147: Consolidate preserved marks handling with other
 STW collectors
In-Reply-To: <jXZiOVJDgymUKJne7d-LXCpIx7xcPoFPGATHIGSw_HE=.cb5e5aa0-001c-4842-9c16-7cb70e41b8a2@github.com>
References: <jXZiOVJDgymUKJne7d-LXCpIx7xcPoFPGATHIGSw_HE=.cb5e5aa0-001c-4842-9c16-7cb70e41b8a2@github.com>
Message-ID: <NqKCuB7Id3vCIsmSgxsFtcJf-u7KkNgHuApnMgOkO48=.c96904e9-e4db-4897-b461-0e817494e0f2@github.com>

On Thu, 1 Jun 2023 22:32:52 GMT, Guoxiong Li <gli at openjdk.org> wrote:

> Hi all,
> 
> This patch removes the class `markSweep.hpp::PreservedMark` and uses the shared `PreservedMarksSet` instead.
> 
> In order to keep the meaning of the field `_preserved_marks` in `markSweep`,
> I need to use `OopAndMarkWord` explicitly. So I move `OopAndMarkWord` out of `PreservedMarks`.
> 
> Tests:
> `hotspot:tier1` passed locally (x86 & linux).
> 
> Thanks for the review.
> 
> Best Regards,
> -- Guoxiong

This pull request has now been integrated.

Changeset: 07275072
Author:    Guoxiong Li <gli at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/07275072aa684f85e70ba31ea6b2ee4a8656d9c6
Stats:     82 lines in 6 files changed: 21 ins; 34 del; 27 mod

8272147: Consolidate preserved marks handling with other STW collectors

Reviewed-by: tschatzl, ayang, rkennke

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

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

From rriggs at openjdk.org  Mon Jun 12 16:26:43 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 12 Jun 2023 16:26:43 GMT
Subject: RFR: 8309622: Re-examine the cache mechanism in BaseLocale
In-Reply-To: <5MqmN4P1TLKDCfXPhKWrH1b2FTgOXmjtKgd1bVXDd_M=.2000f20d-365d-48dc-bc37-45d8bcb9447f@github.com>
References: <5MqmN4P1TLKDCfXPhKWrH1b2FTgOXmjtKgd1bVXDd_M=.2000f20d-365d-48dc-bc37-45d8bcb9447f@github.com>
Message-ID: <zbx3xIqYwzCBzU6_qD-pnp0BS6s-RmUjv9J0phDd9ok=.b22fc675-1a82-451a-a13a-dfaf7e47e3e8@github.com>

On Fri, 9 Jun 2023 22:17:39 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> This is stemming from the PR: https://github.com/openjdk/jdk/pull/14211 where aggressive GC can cause NPE in `BaseLocale$Key` class. I refactored the in-house cache with WeakHashMap, and removed the Key class as it is no longer needed (thus the original NPE will no longer be possible). Also with the new JMH test case, it gains some performance improvement:
> 
> (w/o fix)
> 
> Benchmark                       Mode  Cnt      Score     Error  Units
> LocaleCache.testForLanguageTag  avgt   20   5781.275 ? 569.580  ns/op
> LocaleCache.testLocaleOf        avgt   20  62564.079 ? 406.697  ns/op
> 
> (w/ fix)
> Benchmark                       Mode  Cnt      Score     Error  Units
> LocaleCache.testForLanguageTag  avgt   20   4801.175 ? 371.830  ns/op
> LocaleCache.testLocaleOf        avgt   20  60394.652 ? 352.471  ns/op

One other thing to consider...
If the BaseLocale entries are being GC'd sooner, then perhaps the value of the String.intern() is reduced.
Eliminating `.intern90` would make creating a normalized BaseLocale faster.

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

PR Comment: https://git.openjdk.org/jdk/pull/14404#issuecomment-1587662100

From naoto at openjdk.org  Mon Jun 12 17:33:11 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 12 Jun 2023 17:33:11 GMT
Subject: RFR: 8309622: Re-examine the cache mechanism in BaseLocale [v2]
In-Reply-To: <5MqmN4P1TLKDCfXPhKWrH1b2FTgOXmjtKgd1bVXDd_M=.2000f20d-365d-48dc-bc37-45d8bcb9447f@github.com>
References: <5MqmN4P1TLKDCfXPhKWrH1b2FTgOXmjtKgd1bVXDd_M=.2000f20d-365d-48dc-bc37-45d8bcb9447f@github.com>
Message-ID: <I1w5uzuRAmk1eTqIwe1IMrxz5J39yZN3YYuMjHkYFTU=.cfe0ec7c-edd7-46e2-8444-0192d88022c8@github.com>

> This is stemming from the PR: https://github.com/openjdk/jdk/pull/14211 where aggressive GC can cause NPE in `BaseLocale$Key` class. I refactored the in-house cache with WeakHashMap, and removed the Key class as it is no longer needed (thus the original NPE will no longer be possible). Also with the new JMH test case, it gains some performance improvement:
> 
> (w/o fix)
> 
> Benchmark                       Mode  Cnt      Score     Error  Units
> LocaleCache.testForLanguageTag  avgt   20   5781.275 ? 569.580  ns/op
> LocaleCache.testLocaleOf        avgt   20  62564.079 ? 406.697  ns/op
> 
> (w/ fix)
> Benchmark                       Mode  Cnt      Score     Error  Units
> LocaleCache.testForLanguageTag  avgt   20   4801.175 ? 371.830  ns/op
> LocaleCache.testLocaleOf        avgt   20  60394.652 ? 352.471  ns/op

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

  Addressing comments (test grouping, synchronization), minor optimization on loop lookup

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14404/files
  - new: https://git.openjdk.org/jdk/pull/14404/files/06d199dc..fb1535ff

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

  Stats: 55 lines in 2 files changed: 16 ins; 14 del; 25 mod
  Patch: https://git.openjdk.org/jdk/pull/14404.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14404/head:pull/14404

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

From naoto at openjdk.org  Mon Jun 12 17:33:11 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 12 Jun 2023 17:33:11 GMT
Subject: RFR: 8309622: Re-examine the cache mechanism in BaseLocale [v2]
In-Reply-To: <lTt_W4Ue-TJX0DRm890f_iScI2Wo902VXROCVIq2VTk=.794888d9-6019-4d7c-bbe0-46d41427e8aa@github.com>
References: <5MqmN4P1TLKDCfXPhKWrH1b2FTgOXmjtKgd1bVXDd_M=.2000f20d-365d-48dc-bc37-45d8bcb9447f@github.com>
 <lTt_W4Ue-TJX0DRm890f_iScI2Wo902VXROCVIq2VTk=.794888d9-6019-4d7c-bbe0-46d41427e8aa@github.com>
Message-ID: <g2oOmzsd58gopPKyf3NS12-XXfcX9naws8Q6_1dNj7Q=.2ded240e-49bb-4b2b-a38e-11108db25cdb@github.com>

On Mon, 12 Jun 2023 14:35:15 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> One thing though - WeakHashMap is not thread safe - and I don't see any locks or synchronized to protect access to CACHE. Is that going to cause trouble if two threads compete to add a locale to the map? In other words - how confident are we that the race would be benign?

Although I think the possible race is benign (it would simply overwrite the existing normalized one), I put it in a synchronization block as a safety measure, as the race would be quite rare for creating a BaseLocale instance. Tested with the microbench mark and I didn't see the number change.

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

PR Comment: https://git.openjdk.org/jdk/pull/14404#issuecomment-1587759179

From naoto at openjdk.org  Mon Jun 12 17:33:11 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 12 Jun 2023 17:33:11 GMT
Subject: RFR: 8309622: Re-examine the cache mechanism in BaseLocale
In-Reply-To: <zbx3xIqYwzCBzU6_qD-pnp0BS6s-RmUjv9J0phDd9ok=.b22fc675-1a82-451a-a13a-dfaf7e47e3e8@github.com>
References: <5MqmN4P1TLKDCfXPhKWrH1b2FTgOXmjtKgd1bVXDd_M=.2000f20d-365d-48dc-bc37-45d8bcb9447f@github.com>
 <zbx3xIqYwzCBzU6_qD-pnp0BS6s-RmUjv9J0phDd9ok=.b22fc675-1a82-451a-a13a-dfaf7e47e3e8@github.com>
Message-ID: <pw8M2rDyrS5DSt4Hxk7poIQ5pL6c9ZJKuL49-6DaWOQ=.e11e348f-7beb-4c1a-ab03-56e819893530@github.com>

On Mon, 12 Jun 2023 16:23:29 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> One other thing to consider... If the BaseLocale entries are being GC'd sooner, then perhaps the value of the String.intern() is reduced. Eliminating `.intern90` would make creating a normalized BaseLocale faster.

Some code inside the Locale still relies on `intern` and do `==` comparison. Yes, it would be faster but I think that would be out of the scope of this fix

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

PR Comment: https://git.openjdk.org/jdk/pull/14404#issuecomment-1587760602

From naoto at openjdk.org  Mon Jun 12 17:33:11 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 12 Jun 2023 17:33:11 GMT
Subject: RFR: 8309622: Re-examine the cache mechanism in BaseLocale [v2]
In-Reply-To: <kY1A9vDf0wGk8SfYMgmE6en_3IICLsUpeNHuZUdOyRg=.74f0261d-ab5f-4624-8815-b6f770bb6f99@github.com>
References: <5MqmN4P1TLKDCfXPhKWrH1b2FTgOXmjtKgd1bVXDd_M=.2000f20d-365d-48dc-bc37-45d8bcb9447f@github.com>
 <kY1A9vDf0wGk8SfYMgmE6en_3IICLsUpeNHuZUdOyRg=.74f0261d-ab5f-4624-8815-b6f770bb6f99@github.com>
Message-ID: <7znWt-HGeAbK4ngG1xgIas71tNbe3yUHhPCz5sR42_Y=.24d27c62-2d80-4b70-b0b9-3d178902fed1@github.com>

On Mon, 12 Jun 2023 12:49:05 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Addressing comments (test grouping, synchronization), minor optimization on loop lookup
>
> test/hotspot/jtreg/gc/TestAllocHumongousFragment.java line 180:
> 
>> 178:  */
>> 179: 
>> 180: /*
> 
> Could you move this block a few lines above (e.g. next to the block of `id=iu-aggressive`) so that similar tests are grouped together?

Moved the block next to `iu-aggressive`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14404#discussion_r1227009171

From dfuchs at openjdk.org  Mon Jun 12 19:03:44 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 12 Jun 2023 19:03:44 GMT
Subject: RFR: 8309622: Re-examine the cache mechanism in BaseLocale [v2]
In-Reply-To: <I1w5uzuRAmk1eTqIwe1IMrxz5J39yZN3YYuMjHkYFTU=.cfe0ec7c-edd7-46e2-8444-0192d88022c8@github.com>
References: <5MqmN4P1TLKDCfXPhKWrH1b2FTgOXmjtKgd1bVXDd_M=.2000f20d-365d-48dc-bc37-45d8bcb9447f@github.com>
 <I1w5uzuRAmk1eTqIwe1IMrxz5J39yZN3YYuMjHkYFTU=.cfe0ec7c-edd7-46e2-8444-0192d88022c8@github.com>
Message-ID: <Jvmfztugmp9z0ePb3HyHZw8n4I2xnfFZK1A2JxOpEWY=.1b9b1ab5-643c-4a91-a67b-9d0b9f93f776@github.com>

On Mon, 12 Jun 2023 17:33:11 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> This is stemming from the PR: https://github.com/openjdk/jdk/pull/14211 where aggressive GC can cause NPE in `BaseLocale$Key` class. I refactored the in-house cache with WeakHashMap, and removed the Key class as it is no longer needed (thus the original NPE will no longer be possible). Also with the new JMH test case, it gains some performance improvement:
>> 
>> (w/o fix)
>> 
>> Benchmark                       Mode  Cnt      Score     Error  Units
>> LocaleCache.testForLanguageTag  avgt   20   5781.275 ? 569.580  ns/op
>> LocaleCache.testLocaleOf        avgt   20  62564.079 ? 406.697  ns/op
>> 
>> (w/ fix)
>> Benchmark                       Mode  Cnt      Score     Error  Units
>> LocaleCache.testForLanguageTag  avgt   20   4801.175 ? 371.830  ns/op
>> LocaleCache.testLocaleOf        avgt   20  60394.652 ? 352.471  ns/op
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Addressing comments (test grouping, synchronization), minor optimization on loop lookup

LGTM

FWIW I am not sure the race would have been benign - as `put` is not atomic - so I wouldn't be surprised if concurrent `put`s  could have resulted in an inconsistent internal state for the `WeakHashMap`.

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

Marked as reviewed by dfuchs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14404#pullrequestreview-1475620449

From iklam at openjdk.org  Mon Jun 12 19:08:45 2023
From: iklam at openjdk.org (Ioi Lam)
Date: Mon, 12 Jun 2023 19:08:45 GMT
Subject: RFR: 8309065: Move the logic to determine archive heap location
 from CDS to G1 GC [v4]
In-Reply-To: <j-x_2LhZ442Vm8iPVuOXBvclzwfWxuOxwr9fUDpbmTY=.e52d7a70-7e88-4f17-80b3-408c1a877c0a@github.com>
References: <Jy8pV1WnLW6fMktk9Jmx5SF4JDWL8fl1zPNKOpV6FpA=.324de220-9ad8-4316-b871-c2b7dea5e6d2@github.com>
 <j-x_2LhZ442Vm8iPVuOXBvclzwfWxuOxwr9fUDpbmTY=.e52d7a70-7e88-4f17-80b3-408c1a877c0a@github.com>
Message-ID: <_MIKfgFiZ7tZv9-nhjQotu_jnpXyxZoQZGpr4iw6VaE=.6010c7c7-df33-4a2f-a723-a45e0fab048b@github.com>

On Fri, 9 Jun 2023 23:06:12 GMT, Ashutosh Mehra <duke at openjdk.org> wrote:

>> This patch is the first step towards having a single set of GC APIs for allocating heap space for the archived objects (See https://bugs.openjdk.org/browse/JDK-8296263).
>> It moves some of the G1 specific logic from CDS to G1 gc without changing the functionality.
>> 
>> Changes that add/update GC APIs for handling archive heap would be introduced in upcoming patches.
>
> Ashutosh Mehra has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add comment to alloc_archive_region()
>   
>   Signed-off-by: Ashutosh Mehra <asmehra at redhat.com>

I merged with the latest mainline and started a final test run on our CI. I will sponsor this PR after the test passes.

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

PR Comment: https://git.openjdk.org/jdk/pull/14208#issuecomment-1587917421

From duke at openjdk.org  Mon Jun 12 22:12:05 2023
From: duke at openjdk.org (Ashutosh Mehra)
Date: Mon, 12 Jun 2023 22:12:05 GMT
Subject: Integrated: 8309065: Move the logic to determine archive heap location
 from CDS to G1 GC
In-Reply-To: <Jy8pV1WnLW6fMktk9Jmx5SF4JDWL8fl1zPNKOpV6FpA=.324de220-9ad8-4316-b871-c2b7dea5e6d2@github.com>
References: <Jy8pV1WnLW6fMktk9Jmx5SF4JDWL8fl1zPNKOpV6FpA=.324de220-9ad8-4316-b871-c2b7dea5e6d2@github.com>
Message-ID: <rI_R4CdgNIrtxIWNPHWJ7NuxmO7GSk9P54FDC7Uebjo=.d4c71616-9926-4568-9b0e-27a4771b68cd@github.com>

On Mon, 29 May 2023 21:15:33 GMT, Ashutosh Mehra <duke at openjdk.org> wrote:

> This patch is the first step towards having a single set of GC APIs for allocating heap space for the archived objects (See https://bugs.openjdk.org/browse/JDK-8296263).
> It moves some of the G1 specific logic from CDS to G1 gc without changing the functionality.
> 
> Changes that add/update GC APIs for handling archive heap would be introduced in upcoming patches.

This pull request has now been integrated.

Changeset: 3028295f
Author:    Ashutosh Mehra <asmehra at redhat.com>
Committer: Ioi Lam <iklam at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3028295fdd2e5caf22463d1ee8009e72d4221d53
Stats:     141 lines in 4 files changed: 40 ins; 82 del; 19 mod

8309065: Move the logic to determine archive heap location from CDS to G1 GC

Reviewed-by: iklam, tschatzl, stuefe

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

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

From stefank at openjdk.org  Tue Jun 13 05:56:19 2023
From: stefank at openjdk.org (Stefan Karlsson)
Date: Tue, 13 Jun 2023 05:56:19 GMT
Subject: RFR: 8309890: TestStringDeduplicationInterned.java waits for the wrong
 condition
Message-ID: <xNymjGQ0SGb4FA5rzcI4OxwV0MkuWTYFUbMgc-mxzKA=.72c6232f-62df-4f6c-a5f5-51239da5146c@github.com>

There's a section in the test that waits up to 10 seconds for a string to be deduplicated and then does a final verification that the string was correctly deduplicated. However, the initial waiting gets passed the wrong comparison string, which has the effect that this test always waits for 10 seconds before proceeding.

The problem is here:

            if (!waitForDeduplication(dupString3, baseString)) {
                if (getValue(dupString3) != getValue(internedString)) {

where the first line should say:

            if (!waitForDeduplication(dupString3, internedString)) {

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

Commit messages:
 - 8309890: TestStringDeduplicationInterned.java waits for the wrong condition

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

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

From aboldtch at openjdk.org  Tue Jun 13 06:29:51 2023
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Tue, 13 Jun 2023 06:29:51 GMT
Subject: RFR: 8309890: TestStringDeduplicationInterned.java waits for the
 wrong condition
In-Reply-To: <xNymjGQ0SGb4FA5rzcI4OxwV0MkuWTYFUbMgc-mxzKA=.72c6232f-62df-4f6c-a5f5-51239da5146c@github.com>
References: <xNymjGQ0SGb4FA5rzcI4OxwV0MkuWTYFUbMgc-mxzKA=.72c6232f-62df-4f6c-a5f5-51239da5146c@github.com>
Message-ID: <FqvE6JW55QKioxbVLk7g8tcSiPfVOFt9YSTvD5sw0xA=.973683fc-9304-4100-b6fd-d143d89da6b5@github.com>

On Tue, 13 Jun 2023 05:48:32 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> There's a section in the test that waits up to 10 seconds for a string to be deduplicated and then does a final verification that the string was correctly deduplicated. However, the initial waiting gets passed the wrong comparison string, which has the effect that this test always waits for 10 seconds before proceeding.
> 
> The problem is here:
> 
>             if (!waitForDeduplication(dupString3, baseString)) {
>                 if (getValue(dupString3) != getValue(internedString)) {
> 
> where the first line should say:
> 
>             if (!waitForDeduplication(dupString3, internedString)) {

Marked as reviewed by aboldtch (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/14437#pullrequestreview-1476344420

From tschatzl at openjdk.org  Tue Jun 13 07:13:52 2023
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Tue, 13 Jun 2023 07:13:52 GMT
Subject: RFR: 8140326: G1: Consider putting regions where evacuation failed
 into next collection set [v4]
In-Reply-To: <6B_KdGAaJUpyWL-h452IY0QLUWgjJhR_-6UvtiTdAL0=.7c5acee1-562d-4657-995c-11b3574b9819@github.com>
References: <mmq6sEkAicO7Mc5FKkk5tcRVJDU6qtjYoyySho56F80=.aea5db50-0ec5-4e27-944e-2750af3d0bd7@github.com>
 <siD6FS-fypLat5u9YQDYdzP6z2-8PiCzsn2xqMRXJc4=.55fa90c6-72c3-4442-a228-fef52bab717c@github.com>
 <6B_KdGAaJUpyWL-h452IY0QLUWgjJhR_-6UvtiTdAL0=.7c5acee1-562d-4657-995c-11b3574b9819@github.com>
Message-ID: <60Ff4RI0NCx0LEcxdwbrJNoz0fQ7_luUbLyWuI5_JT4=.df4d6d42-d884-4ad8-b465-ca062fc64593@github.com>

On Fri, 9 Jun 2023 13:12:29 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Thomas Schatzl has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - More debug option removal
>>  - Remove debug options for tests
>
> src/hotspot/share/gc/g1/g1CollectionSetCandidates.hpp line 138:
> 
>> 136: 
>> 137: // Iterator for G1CollectionSetCandidates. Multiplexes across the marking/retained
>> 138: // region lists based on gc efficiency.
> 
> Why does the iteration require ordering? Going through its use sites, I find they just need to perform SIMD like op on each element regardless of the order.

API consistency. All iterators return them sorted in efficiency order, and if not doing this for that as well will give unnecessary surprises.
I can change this if you insist, but I can already see problems with that in the future.

> src/hotspot/share/gc/g1/g1Policy.cpp line 655:
> 
>> 653: 
>> 654:   size_t threshold = G1MixedGCLiveThresholdPercent * HeapRegion::GrainBytes / 100;
>> 655:   return live_bytes < threshold;
> 
> If the region was Old at gc-start, it would have passed through the same criteria to be in cset; if the region was Young at gc-start, using a threshold meant only for Old-region is questionable, IMO.
> 
> Could retaining be performed unconditionally for now based on the assumption that evac-fail regions are sparse?

Testing showed that this can happen, i.e. fairly full young gen regions. As explained above, scheduling expensive regions within regular young gcs is painful which performance we want to keep unchanged as much as possible. This heuristic is fairly efficient to remove those (and also tests keeping regions that is required for the next change anyway.)

I understand that it is somewhat bad to use a metric that has old gen/mixed gc in it - I can add another option for that if you think it is better.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14220#discussion_r1227634772
PR Review Comment: https://git.openjdk.org/jdk/pull/14220#discussion_r1227633401

From tschatzl at openjdk.org  Tue Jun 13 07:19:43 2023
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Tue, 13 Jun 2023 07:19:43 GMT
Subject: RFR: 8140326: G1: Consider putting regions where evacuation failed
 into next collection set [v4]
In-Reply-To: <6B_KdGAaJUpyWL-h452IY0QLUWgjJhR_-6UvtiTdAL0=.7c5acee1-562d-4657-995c-11b3574b9819@github.com>
References: <mmq6sEkAicO7Mc5FKkk5tcRVJDU6qtjYoyySho56F80=.aea5db50-0ec5-4e27-944e-2750af3d0bd7@github.com>
 <siD6FS-fypLat5u9YQDYdzP6z2-8PiCzsn2xqMRXJc4=.55fa90c6-72c3-4442-a228-fef52bab717c@github.com>
 <6B_KdGAaJUpyWL-h452IY0QLUWgjJhR_-6UvtiTdAL0=.7c5acee1-562d-4657-995c-11b3574b9819@github.com>
Message-ID: <b8utOWerja8oMiCeomiL8bE-rS2K43J4pMI88jNu0dY=.42688a79-156a-440f-b95b-28ae2c0c422f@github.com>

On Fri, 9 Jun 2023 13:53:38 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Thomas Schatzl has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - More debug option removal
>>  - Remove debug options for tests
>
> src/hotspot/share/gc/g1/g1Policy.cpp line 516:
> 
>> 514: }
>> 515: 
>> 516: double G1Policy::predict_retained_regions_evac_time() const {
> 
> Seems that the result is only for log-print in its sole caller, `predict_base_time_ms`. However, it's also odd that this method is called there at all.

This is a bug. It's supposed to be used for calculating the total_time in that method too. Fixed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14220#discussion_r1227639920

From kbarrett at openjdk.org  Tue Jun 13 07:22:41 2023
From: kbarrett at openjdk.org (Kim Barrett)
Date: Tue, 13 Jun 2023 07:22:41 GMT
Subject: RFR: 8309890: TestStringDeduplicationInterned.java waits for the
 wrong condition
In-Reply-To: <xNymjGQ0SGb4FA5rzcI4OxwV0MkuWTYFUbMgc-mxzKA=.72c6232f-62df-4f6c-a5f5-51239da5146c@github.com>
References: <xNymjGQ0SGb4FA5rzcI4OxwV0MkuWTYFUbMgc-mxzKA=.72c6232f-62df-4f6c-a5f5-51239da5146c@github.com>
Message-ID: <xHEKhC-PiZYSWBt5YWA1sBSH5Ht-yFMmBkFhzWhCABs=.05b0eb10-a6e8-4d4e-972a-09b67c61d851@github.com>

On Tue, 13 Jun 2023 05:48:32 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> There's a section in the test that waits up to 10 seconds for a string to be deduplicated and then does a final verification that the string was correctly deduplicated. However, the initial waiting gets passed the wrong comparison string, which has the effect that this test always waits for 10 seconds before proceeding.
> 
> The problem is here:
> 
>             if (!waitForDeduplication(dupString3, baseString)) {
>                 if (getValue(dupString3) != getValue(internedString)) {
> 
> where the first line should say:
> 
>             if (!waitForDeduplication(dupString3, internedString)) {

Changes requested by kbarrett (Reviewer).

test/hotspot/jtreg/gc/stringdedup/TestStringDeduplicationTools.java line 396:

> 394: 
> 395:             if (!waitForDeduplication(dupString3, internedString)) {
> 396:                 if (getValue(dupString3) != getValue(internedString)) {

This line is no longer needed.  waitForDeduplication returns false if the two strings underlying char arrays
(returned by getValue) don't become equal during the waiting period.  So unless it just happened that they
became equal after waitForDeduplication gave up but before this check, this check will fail.

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

PR Review: https://git.openjdk.org/jdk/pull/14437#pullrequestreview-1476427449
PR Review Comment: https://git.openjdk.org/jdk/pull/14437#discussion_r1227643884

From kbarrett at openjdk.org  Tue Jun 13 07:35:24 2023
From: kbarrett at openjdk.org (Kim Barrett)
Date: Tue, 13 Jun 2023 07:35:24 GMT
Subject: RFR: 8309899: Rename PtrQueueSet::buffer_size()
Message-ID: <mmdB2PB2JtgaIrWdKFy6gF3ooTBSrUY_kDnnF271Nx0=.acb85028-8e69-4cbb-b6db-8b54bd07a241@github.com>

Please review this renaming of PtrQueueSet::buffer_size to buffer_capacity,
along with some associated function and variable renamings.

Despite the number of files and lines changed, it's just a name change, so
perhaps it's trivial?

Testing:
mach5 tier1

Note: There weren't any changes needed in Shenandoah, even though it uses the
SATBMarkQueue stuff.

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

Commit messages:
 - rename buffer_size to buffer_capacity

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

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

From ayang at openjdk.org  Tue Jun 13 07:56:50 2023
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Tue, 13 Jun 2023 07:56:50 GMT
Subject: RFR: 8309538: G1: Move total collection increment from Cleanup to
 Remark
In-Reply-To: <uMB-xwYhtwBWqvVAkaFpTmfYhxTlO_Rzm-XZxo6zsbA=.53ac8ffa-f346-4024-8b16-eebf0428c489@github.com>
References: <uMB-xwYhtwBWqvVAkaFpTmfYhxTlO_Rzm-XZxo6zsbA=.53ac8ffa-f346-4024-8b16-eebf0428c489@github.com>
Message-ID: <xO2PuQnieeo_hIbzckXYhc6xpTwV3T1VEXncGEqrnQY=.06c2b190-9c3e-46e3-b47b-32ad8aff6463@github.com>

On Tue, 6 Jun 2023 13:37:13 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple moving `increment_total_collections` to where empty-region reclaim lives.
> 
> Test: hotspot_gc

Thanks for the review.

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

PR Comment: https://git.openjdk.org/jdk/pull/14334#issuecomment-1588743435

From ayang at openjdk.org  Tue Jun 13 07:56:51 2023
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Tue, 13 Jun 2023 07:56:51 GMT
Subject: Integrated: 8309538: G1: Move total collection increment from Cleanup
 to Remark
In-Reply-To: <uMB-xwYhtwBWqvVAkaFpTmfYhxTlO_Rzm-XZxo6zsbA=.53ac8ffa-f346-4024-8b16-eebf0428c489@github.com>
References: <uMB-xwYhtwBWqvVAkaFpTmfYhxTlO_Rzm-XZxo6zsbA=.53ac8ffa-f346-4024-8b16-eebf0428c489@github.com>
Message-ID: <kWQg8Xr68sCwaxluMgvDz3ASaTPbFiSLEIrSN2i9TQg=.be888a39-a226-4ab1-b7c5-b067a54fd01e@github.com>

On Tue, 6 Jun 2023 13:37:13 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple moving `increment_total_collections` to where empty-region reclaim lives.
> 
> Test: hotspot_gc

This pull request has now been integrated.

Changeset: 23a54f37
Author:    Albert Mingkun Yang <ayang at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/23a54f37018bb9345a60a6891e81c1910fb8c3c8
Stats:     9 lines in 1 file changed: 5 ins; 4 del; 0 mod

8309538: G1: Move total collection increment from Cleanup to Remark

Reviewed-by: tschatzl, iwalulya

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

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

From ayang at openjdk.org  Tue Jun 13 07:57:50 2023
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Tue, 13 Jun 2023 07:57:50 GMT
Subject: RFR: 8309852: G1: Remove unnecessary assert_empty in
 G1ParScanThreadStateSet destructor
In-Reply-To: <EdJ05jdBSUPLvQX71f318PL2zlsa87tc4XjtQH--lX0=.86bd04f7-26db-4f56-88f4-f48eeca7b519@github.com>
References: <EdJ05jdBSUPLvQX71f318PL2zlsa87tc4XjtQH--lX0=.86bd04f7-26db-4f56-88f4-f48eeca7b519@github.com>
Message-ID: <Dx4Ip1W72itQ7gWK_uob7xee4DtvlA805PbI75UME4o=.b5149e62-effc-43bf-86c6-b1b684316639@github.com>

On Mon, 12 Jun 2023 13:31:20 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Trivial removing redundant code.

Thanks for the review.

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

PR Comment: https://git.openjdk.org/jdk/pull/14417#issuecomment-1588743772

From ayang at openjdk.org  Tue Jun 13 07:57:50 2023
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Tue, 13 Jun 2023 07:57:50 GMT
Subject: Integrated: 8309852: G1: Remove unnecessary assert_empty in
 G1ParScanThreadStateSet destructor
In-Reply-To: <EdJ05jdBSUPLvQX71f318PL2zlsa87tc4XjtQH--lX0=.86bd04f7-26db-4f56-88f4-f48eeca7b519@github.com>
References: <EdJ05jdBSUPLvQX71f318PL2zlsa87tc4XjtQH--lX0=.86bd04f7-26db-4f56-88f4-f48eeca7b519@github.com>
Message-ID: <svjUAuSXaetQFz0e8L_38uU9LXClv4oAvLs-LnjSYPc=.2e5ef239-ab09-4f21-ae1e-6fec33ac8eb0@github.com>

On Mon, 12 Jun 2023 13:31:20 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Trivial removing redundant code.

This pull request has now been integrated.

Changeset: 5d716121
Author:    Albert Mingkun Yang <ayang at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/5d716121c1ea3845d31862ed2357172cfe5aefae
Stats:     1 line in 1 file changed: 0 ins; 1 del; 0 mod

8309852: G1: Remove unnecessary assert_empty in G1ParScanThreadStateSet destructor

Reviewed-by: tschatzl

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

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

From tschatzl at openjdk.org  Tue Jun 13 08:55:50 2023
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Tue, 13 Jun 2023 08:55:50 GMT
Subject: RFR: 8140326: G1: Consider putting regions where evacuation failed
 into next collection set [v4]
In-Reply-To: <6B_KdGAaJUpyWL-h452IY0QLUWgjJhR_-6UvtiTdAL0=.7c5acee1-562d-4657-995c-11b3574b9819@github.com>
References: <mmq6sEkAicO7Mc5FKkk5tcRVJDU6qtjYoyySho56F80=.aea5db50-0ec5-4e27-944e-2750af3d0bd7@github.com>
 <siD6FS-fypLat5u9YQDYdzP6z2-8PiCzsn2xqMRXJc4=.55fa90c6-72c3-4442-a228-fef52bab717c@github.com>
 <6B_KdGAaJUpyWL-h452IY0QLUWgjJhR_-6UvtiTdAL0=.7c5acee1-562d-4657-995c-11b3574b9819@github.com>
Message-ID: <jgE-3waJyz5dvNbmPYz0wiFlUNN13gpf4sdKwK2MUkk=.77e759c0-a370-46a4-9be4-8e1455e2e087@github.com>

On Fri, 9 Jun 2023 11:43:35 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> I don't get why tams and CM-related data-structure need to be cleared here; shouldn't they be handled inside G1ClearBitmapClosure already?

First, evacuation failure already updated region statistics during concurrent start (as well as g1 updated TAMS during concurrent start).

It is not that evacuation failure and marking are linked, it is that bitmaps and TAMS and statistics are linked. Previous code also assumed that all old regions were marked through, so (as optimizations):

1) Bitmap: g1 keeps the marks on the bitmap of evac-fail regions
2) TAMS: could be kept to top() for all evac-failed regions during concurrent start
3) statistics: evacuation failure did already update them; clearing them in some cases simply been avoided by conditionally updating statistics (maybe remove that `if` now in evacuation failure handling now, what do you think?).

Generally, if you update one, you need to keep the other in sync for marking to work. However none of the marking data cleanup has been necessary before because of that assumption that all old regions are to be marked through.

`G1ClearBitmapClosure` doesn't interact with marking proper (as in: marking live objects on the bitmap), the regions that are cleared in that phase are only those that may not have their bitmap cleared yet due to the "clear bitmaps concurrently" optimization. If that were not the case, g1 would not need that phase.
At that time TAMS and statistics have already been reset by marking, so it does not need to (and both are marking data structures anyway).

That is, the reason to have `G1ClearBitmapClosure` is different compared to `ClearRetainedRegionBitmaps`.

Now that not all old regions may be marked through at concurrent start any more, g1 needs to undo the eagerly updated statistics and TAMS to not confuse other code (mainly marking, but there are asserts wrt to TAMS all over the place).

I do not think there is a way to avoid evacuation failure to interact with concurrent marking (during the concurrent start pause at least) if we want to clear out pinned regions efficiently and quickly.

Maybe making this explicit with something like (didn't test):


bool drop_mark_data = g1h->collector_state()->in_concurrent_start_gc() && 
                            g1h->policy()->retain_evac_failed_region(r);
if (drop_mark_data) {
  // clear statistics and tams
} else {
  // tams and statistics must be "set"
}
bool drop_bitmap = !g1h->collector_state()->in_concurrent_start_gc() ||
                            g1h->policy()->retain_evac_failed_region(r);
if (drop_bitmap) {
  // clear bitmap
} else {
  // bitmap must contain marks
}

would help?

I thought this would be too complicated for not much gain (resetting TAMS and statistics is little work compared to bitmaps), so I did not. The change I'm going to post is trying to improve the comment.

> (On a higher reasoning, evac-fail processing shouldn't interact with CM; I am assuming the bitmap is not related to CM.)

Evacuation failure already did and still does by a) using mark bitmaps and keeping the marks during concurrent start and b) needing to update marking statistics/tams if necessary (because it keeps marks on the bitmap). This particular change is only required extension to support the new functionality.

I assume we will keep the optimization to keep marks on the bitmap created by evacuation failure (we did in the past, the reason did not change), so evacuation failure be required to keep messing with CM.

I renamed `ClearRetainedRegionBitmaps` to `ClearRetainedRegionData` to make it more clear that retained regions need more processing than just bitmaps now.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14220#discussion_r1227773655

From ayang at openjdk.org  Tue Jun 13 09:05:01 2023
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Tue, 13 Jun 2023 09:05:01 GMT
Subject: RFR: 8308507: G1: GClocker induced GCs can starve threads
 requiring memory leading to OOME [v10]
In-Reply-To: <2meSHY2dSGLyLNXPTeSwOBbsCh6Ki0itMEfh2x-GhUM=.a715c087-a300-452f-b406-04168843b363@github.com>
References: <OA_NUok57_CwYFRa6FjYHfQpxEIQrxO7tHQ-1VM3Cus=.1621f0a2-7766-41a0-a45b-94c2703ff4bf@github.com>
 <2meSHY2dSGLyLNXPTeSwOBbsCh6Ki0itMEfh2x-GhUM=.a715c087-a300-452f-b406-04168843b363@github.com>
Message-ID: <bsBEmn5ZDWJy_PSguQVqui2wQjkZp4BSkCx9HoV0YMQ=.f84a59fe-c939-4be8-8148-18938dcdba44@github.com>

On Mon, 12 Jun 2023 13:32:52 GMT, Ivan Walulya <iwalulya at openjdk.org> wrote:

>> Please review this change which fixes the thread starvation problem during allocation for G1.
>> 
>> The starvation problem is not limited to GCLocker, however, currently, it manifests as an OOME only when GCLocker is active. In other cases, the starvation only affects the "starved" thread as it may loop indefinitely. 
>> 
>> Starvation with an active GCLocker happens as below:
>> 
>> 1. Thread A tries to allocate memory as normal, and tries to start a GC; the GCLocker is active and so the thread gets stalled waiting for the GC.
>> 2. GCLocker induced GC executes and frees some memory.
>> 3. Thread A does not get any of that memory, but other threads also waiting for memory.
>> 4. Goto 1 until the gclocker retry count has been reached.
>> 
>> In this change, we take the general approach to solving starvation problems with announcement tables (request queues). On slow allocation, a thread that wishes to complete an Allocation GC and then attempt an allocation, announces its allocation request before proceeding to participate in a race to execute a GC safepoint. Whichever thread succeeds in executing the Allocation GC safepoint will be tasked with completing all allocation requests that were announced before the safepoint. This guarantees that all announced allocation requests are either satisfied during the safepoint, or failed in case there is not enough memory to complete all requests. This effectively deals with the starvation issue and reduces the number of allocation GCs triggered.
>> 
>> Note: The change also adopts ZList from ZGC and makes it available under utilities as DoublyLinkedList with slight modifications. 
>> 
>> Testing: Tier 1-7
>
> Ivan Walulya has updated the pull request incrementally with one additional commit since the last revision:
> 
>   clean up

src/hotspot/share/gc/g1/g1CollectedHeap.hpp line 200:

> 198:       _g1h(g1h)
> 199:     {
> 200:       if (_g1h != nullptr) {

This check is always true, isn't it?

src/hotspot/share/utilities/doublyLinkedList.hpp line 63:

> 61: // or any position within the list.
> 62: //
> 63: // \tparam T The type of elements stored in the linked list. It must be default-constructible and derived from DoublyLinkedListNode.

"default-constructible" is outdated.

src/hotspot/share/utilities/doublyLinkedList.hpp line 99:

> 97:   void insert_last(T* elem);
> 98:   void insert_before(T* before, T* elem);
> 99:   void insert_after(T* after, T* elem);

Doesn't seem they need to be `T*`; maybe change the arg type to sth like in `insert`? On a higher level, everything going into the collection can take the `Node` type, while everything coming out of the collection can take the elem type, using template.

src/hotspot/share/utilities/doublyLinkedList.inline.hpp line 228:

> 226: template <typename T>
> 227: inline typename DoublyLinkedList<T>::Iterator DoublyLinkedList<T>::end() {
> 228:  return Iterator(this, cast_to_outer(&_head));

`_head` has the base type; it's illegal to cast it to elem type.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14077#discussion_r1227777988
PR Review Comment: https://git.openjdk.org/jdk/pull/14077#discussion_r1226703924
PR Review Comment: https://git.openjdk.org/jdk/pull/14077#discussion_r1226703048
PR Review Comment: https://git.openjdk.org/jdk/pull/14077#discussion_r1226699005

From ayang at openjdk.org  Tue Jun 13 09:13:10 2023
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Tue, 13 Jun 2023 09:13:10 GMT
Subject: RFR: 8309907: Remove unused _print_gc_overhead_limit_would_be_exceeded
Message-ID: <FHndpnxzk5zCQa0MKA3FumQg5UEP4tK-qcFlBqQWlbA=.eb85506c-9070-47ef-a26a-f3d9e97ac69c@github.com>

Trivial removing dead code.

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

Commit messages:
 - trivial

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

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

From stefank at openjdk.org  Tue Jun 13 09:16:54 2023
From: stefank at openjdk.org (Stefan Karlsson)
Date: Tue, 13 Jun 2023 09:16:54 GMT
Subject: RFR: 8309890: TestStringDeduplicationInterned.java waits for the
 wrong condition [v2]
In-Reply-To: <xNymjGQ0SGb4FA5rzcI4OxwV0MkuWTYFUbMgc-mxzKA=.72c6232f-62df-4f6c-a5f5-51239da5146c@github.com>
References: <xNymjGQ0SGb4FA5rzcI4OxwV0MkuWTYFUbMgc-mxzKA=.72c6232f-62df-4f6c-a5f5-51239da5146c@github.com>
Message-ID: <DnnD4DqHsl6OIl8WqvQNMdidQBCjl2N3sDPjxN23M2U=.ad3ce08d-a79d-4fbf-afcf-4d25e7214afe@github.com>

> There's a section in the test that waits up to 10 seconds for a string to be deduplicated and then does a final verification that the string was correctly deduplicated. However, the initial waiting gets passed the wrong comparison string, which has the effect that this test always waits for 10 seconds before proceeding.
> 
> The problem is here:
> 
>             if (!waitForDeduplication(dupString3, baseString)) {
>                 if (getValue(dupString3) != getValue(internedString)) {
> 
> where the first line should say:
> 
>             if (!waitForDeduplication(dupString3, internedString)) {

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

  Review kbarrett

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14437/files
  - new: https://git.openjdk.org/jdk/pull/14437/files/8e402a70..b56e8d0f

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

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

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

From stefank at openjdk.org  Tue Jun 13 09:16:55 2023
From: stefank at openjdk.org (Stefan Karlsson)
Date: Tue, 13 Jun 2023 09:16:55 GMT
Subject: RFR: 8309890: TestStringDeduplicationInterned.java waits for the
 wrong condition [v2]
In-Reply-To: <xHEKhC-PiZYSWBt5YWA1sBSH5Ht-yFMmBkFhzWhCABs=.05b0eb10-a6e8-4d4e-972a-09b67c61d851@github.com>
References: <xNymjGQ0SGb4FA5rzcI4OxwV0MkuWTYFUbMgc-mxzKA=.72c6232f-62df-4f6c-a5f5-51239da5146c@github.com>
 <xHEKhC-PiZYSWBt5YWA1sBSH5Ht-yFMmBkFhzWhCABs=.05b0eb10-a6e8-4d4e-972a-09b67c61d851@github.com>
Message-ID: <AQLmynH_pRSdlSZ008ZZBQphUhPAYFCBYLLIq-ToKAg=.fc14c4ef-7748-4cba-8b17-e90781ae4e9f@github.com>

On Tue, 13 Jun 2023 07:20:09 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review kbarrett
>
> test/hotspot/jtreg/gc/stringdedup/TestStringDeduplicationTools.java line 396:
> 
>> 394: 
>> 395:             if (!waitForDeduplication(dupString3, internedString)) {
>> 396:                 if (getValue(dupString3) != getValue(internedString)) {
> 
> This line is no longer needed.  waitForDeduplication returns false if the two strings underlying char arrays
> (returned by getValue) don't become equal during the waiting period.  So unless it just happened that they
> became equal after waitForDeduplication gave up but before this check, this check will fail.

I've updated the test.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14437#discussion_r1227799296

From tschatzl at openjdk.org  Tue Jun 13 09:22:44 2023
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Tue, 13 Jun 2023 09:22:44 GMT
Subject: RFR: 8309907: Remove unused
 _print_gc_overhead_limit_would_be_exceeded
In-Reply-To: <FHndpnxzk5zCQa0MKA3FumQg5UEP4tK-qcFlBqQWlbA=.eb85506c-9070-47ef-a26a-f3d9e97ac69c@github.com>
References: <FHndpnxzk5zCQa0MKA3FumQg5UEP4tK-qcFlBqQWlbA=.eb85506c-9070-47ef-a26a-f3d9e97ac69c@github.com>
Message-ID: <1gE2-T-WXu9VvwNCS8HTqGxZ51Bhs7V0sXtuTSdEE3w=.35ddb006-c907-43f9-9d35-9386eca79f88@github.com>

On Tue, 13 Jun 2023 09:05:59 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Trivial removing dead code.

lgtm and trivial

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

Marked as reviewed by tschatzl (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14442#pullrequestreview-1476675571

From tschatzl at openjdk.org  Tue Jun 13 09:42:10 2023
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Tue, 13 Jun 2023 09:42:10 GMT
Subject: RFR: 8140326: G1: Consider putting regions where evacuation failed
 into next collection set [v5]
In-Reply-To: <mmq6sEkAicO7Mc5FKkk5tcRVJDU6qtjYoyySho56F80=.aea5db50-0ec5-4e27-944e-2750af3d0bd7@github.com>
References: <mmq6sEkAicO7Mc5FKkk5tcRVJDU6qtjYoyySho56F80=.aea5db50-0ec5-4e27-944e-2750af3d0bd7@github.com>
Message-ID: <Iqx9myuC06zwg1aPTPMHz6UIBVhitRdDaLZPYib1YSA=.64c689b4-d345-4b68-bb20-2bebcb30d12d@github.com>

> This change adds management of retained regions, i.e. trying to evacuate evacuation failed regions asap.
> 
> The advantage is that evacuation failed regions do not need to wait until the next marking to be cleaned out; as they are often very sparsely occupied (often being eden regions), this occupies a lot of space, potentially causing additional evacuation failures later on.
> Another use of this change will be region pinning, which are basically evacuation failed regions that can not be reclaimed as long as they are pinned - however as soon as they are unpinned, they should be reclaimed for the same reasons as well.
> 
> It consists of several behavioral changes:
> 
> During garbage collection:
> 
> ... in the Evacuation phase:
> * always collect dirty cards into evacuation failed regions proactively. In tests, the amount of cards/live objects per evacuation failed region is typically very small. Dirty cards are always put into the global refinement buffer immediately, assuming that we will keep most if not all evacuation failed regions.
> 
> ... during Post Evacuation 2/Free Collection Set phase:
> * determine whether the region will be retained (kept for "immediate" evacuation) or not. Highly occupied regions are assumed to stay (mostly) live at least until the next marking, so do not bother with them.
> 
> These "retained" regions are collected in a new "from retained" set in the collection set candidates and managed separately from "from marking" regions. Having the "from retained" and "from marking" sets separate in the collection set candidates is easier to manage than to use a single list and the picking stuff from it. Particularly wrt to making sure that mixed gcs preferentially pick from the "from marking" list first, then second from the "from retained" list.
> 
> ... determining the collection set during the pause:
>   * during gc, the collection set is preferentially (first) populated with regions from the "from marking" candidates (these are the important regions to get cleaned out), second from the "from retained" list.
>   * g1 reserves up to 20% of max gc pause time for retained regions as optional candidates (this is a random number) to make sure that these are cleared out asap to free memory. There is also a minimum number of regions to take from the retained regions list.
> 
> During marking
> 
> ... changes to marking proper
> * retained regions will not be marked through during concurrent mark, i.e. they are considered outside of the snapshot. So they are added to the "root regio...

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

  ayang review:
  - improve comment in ClearRetainedRegionData (formerly ClearRetainedRegionBitmap) about why we need to clear marking data here
  - added separate flag for threshold for retaining evacuation failed regions
  - fix bug in calculating total base time

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14220/files
  - new: https://git.openjdk.org/jdk/pull/14220/files/a304afed..53350858

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

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

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

From alanb at openjdk.org  Tue Jun 13 11:24:52 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 13 Jun 2023 11:24:52 GMT
Subject: RFR: 8309622: Re-examine the cache mechanism in BaseLocale [v2]
In-Reply-To: <I1w5uzuRAmk1eTqIwe1IMrxz5J39yZN3YYuMjHkYFTU=.cfe0ec7c-edd7-46e2-8444-0192d88022c8@github.com>
References: <5MqmN4P1TLKDCfXPhKWrH1b2FTgOXmjtKgd1bVXDd_M=.2000f20d-365d-48dc-bc37-45d8bcb9447f@github.com>
 <I1w5uzuRAmk1eTqIwe1IMrxz5J39yZN3YYuMjHkYFTU=.cfe0ec7c-edd7-46e2-8444-0192d88022c8@github.com>
Message-ID: <hGqRm8mQ8Fit1yhFhVVJt2UnUMq1d2U3BgEUhXYJlWI=.ebe2f332-86b1-4e08-8e25-c39dba2dd87d@github.com>

On Mon, 12 Jun 2023 17:33:11 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> This is stemming from the PR: https://github.com/openjdk/jdk/pull/14211 where aggressive GC can cause NPE in `BaseLocale$Key` class. I refactored the in-house cache with WeakHashMap, and removed the Key class as it is no longer needed (thus the original NPE will no longer be possible). Also with the new JMH test case, it gains some performance improvement:
>> 
>> (w/o fix)
>> 
>> Benchmark                       Mode  Cnt      Score     Error  Units
>> LocaleCache.testForLanguageTag  avgt   20   5781.275 ? 569.580  ns/op
>> LocaleCache.testLocaleOf        avgt   20  62564.079 ? 406.697  ns/op
>> 
>> (w/ fix)
>> Benchmark                       Mode  Cnt      Score     Error  Units
>> LocaleCache.testForLanguageTag  avgt   20   4801.175 ? 371.830  ns/op
>> LocaleCache.testLocaleOf        avgt   20  60394.652 ? 352.471  ns/op
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Addressing comments (test grouping, synchronization), minor optimization on loop lookup

src/java.base/share/classes/sun/util/locale/BaseLocale.java line 166:

> 164:         // can subsequently be used by the Locale instance which
> 165:         // guarantees the locale components are properly cased/interned.
> 166:         synchronized (BaseLocale.class) {

The simplification is good but I wonder if this coarse locking is going to be a problem, do we need to use some concurrent to avoid contention here?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14404#discussion_r1227963571

From aturbanov at openjdk.org  Tue Jun 13 13:14:54 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Tue, 13 Jun 2023 13:14:54 GMT
Subject: RFR: 8309622: Re-examine the cache mechanism in BaseLocale [v2]
In-Reply-To: <I1w5uzuRAmk1eTqIwe1IMrxz5J39yZN3YYuMjHkYFTU=.cfe0ec7c-edd7-46e2-8444-0192d88022c8@github.com>
References: <5MqmN4P1TLKDCfXPhKWrH1b2FTgOXmjtKgd1bVXDd_M=.2000f20d-365d-48dc-bc37-45d8bcb9447f@github.com>
 <I1w5uzuRAmk1eTqIwe1IMrxz5J39yZN3YYuMjHkYFTU=.cfe0ec7c-edd7-46e2-8444-0192d88022c8@github.com>
Message-ID: <MivX2vJkygO5loJYR6IttGKuD9z5K0zOFgn_pfhUAB4=.25630661-8ee7-484d-b3e9-39212fb22a8f@github.com>

On Mon, 12 Jun 2023 17:33:11 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> This is stemming from the PR: https://github.com/openjdk/jdk/pull/14211 where aggressive GC can cause NPE in `BaseLocale$Key` class. I refactored the in-house cache with WeakHashMap, and removed the Key class as it is no longer needed (thus the original NPE will no longer be possible). Also with the new JMH test case, it gains some performance improvement:
>> 
>> (w/o fix)
>> 
>> Benchmark                       Mode  Cnt      Score     Error  Units
>> LocaleCache.testForLanguageTag  avgt   20   5781.275 ? 569.580  ns/op
>> LocaleCache.testLocaleOf        avgt   20  62564.079 ? 406.697  ns/op
>> 
>> (w/ fix)
>> Benchmark                       Mode  Cnt      Score     Error  Units
>> LocaleCache.testForLanguageTag  avgt   20   4801.175 ? 371.830  ns/op
>> LocaleCache.testLocaleOf        avgt   20  60394.652 ? 352.471  ns/op
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Addressing comments (test grouping, synchronization), minor optimization on loop lookup

test/micro/org/openjdk/bench/java/util/LocaleCache.java line 58:

> 56:                 throw new RuntimeException("Different Locale was created");
> 57:             }
> 58:             previous =  l;

Suggestion:

            previous = l;

test/micro/org/openjdk/bench/java/util/LocaleCache.java line 70:

> 68:                 throw new RuntimeException("Different Locale was created");
> 69:             }
> 70:             previous =  l;

Suggestion:

            previous = l;

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14404#discussion_r1228106882
PR Review Comment: https://git.openjdk.org/jdk/pull/14404#discussion_r1228109502

From kbarrett at openjdk.org  Tue Jun 13 13:36:42 2023
From: kbarrett at openjdk.org (Kim Barrett)
Date: Tue, 13 Jun 2023 13:36:42 GMT
Subject: RFR: 8309890: TestStringDeduplicationInterned.java waits for the
 wrong condition [v2]
In-Reply-To: <DnnD4DqHsl6OIl8WqvQNMdidQBCjl2N3sDPjxN23M2U=.ad3ce08d-a79d-4fbf-afcf-4d25e7214afe@github.com>
References: <xNymjGQ0SGb4FA5rzcI4OxwV0MkuWTYFUbMgc-mxzKA=.72c6232f-62df-4f6c-a5f5-51239da5146c@github.com>
 <DnnD4DqHsl6OIl8WqvQNMdidQBCjl2N3sDPjxN23M2U=.ad3ce08d-a79d-4fbf-afcf-4d25e7214afe@github.com>
Message-ID: <sv92z2sIr3H05d5aFvut_orfTjV8RPNuFC1KU20WRgo=.3a8418ec-3f47-483e-a189-3bd3ca0021b4@github.com>

On Tue, 13 Jun 2023 09:16:54 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> There's a section in the test that waits up to 10 seconds for a string to be deduplicated and then does a final verification that the string was correctly deduplicated. However, the initial waiting gets passed the wrong comparison string, which has the effect that this test always waits for 10 seconds before proceeding.
>> 
>> The problem is here:
>> 
>>             if (!waitForDeduplication(dupString3, baseString)) {
>>                 if (getValue(dupString3) != getValue(internedString)) {
>> 
>> where the first line should say:
>> 
>>             if (!waitForDeduplication(dupString3, internedString)) {
>
> Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review kbarrett

Looks good.

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

Marked as reviewed by kbarrett (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14437#pullrequestreview-1477195942

From ayang at openjdk.org  Tue Jun 13 14:06:58 2023
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Tue, 13 Jun 2023 14:06:58 GMT
Subject: RFR: 8309907: Remove unused
 _print_gc_overhead_limit_would_be_exceeded
In-Reply-To: <FHndpnxzk5zCQa0MKA3FumQg5UEP4tK-qcFlBqQWlbA=.eb85506c-9070-47ef-a26a-f3d9e97ac69c@github.com>
References: <FHndpnxzk5zCQa0MKA3FumQg5UEP4tK-qcFlBqQWlbA=.eb85506c-9070-47ef-a26a-f3d9e97ac69c@github.com>
Message-ID: <bfJ3MoeCCa0_NZ7Be5es_aM-vzJskIb-1MdJDke-AdU=.13ff4510-6643-405f-ad8c-cbb6689fd74d@github.com>

On Tue, 13 Jun 2023 09:05:59 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Trivial removing dead code.

Thanks for the review.

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

PR Comment: https://git.openjdk.org/jdk/pull/14442#issuecomment-1589375900

From ayang at openjdk.org  Tue Jun 13 14:06:59 2023
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Tue, 13 Jun 2023 14:06:59 GMT
Subject: Integrated: 8309907: Remove unused
 _print_gc_overhead_limit_would_be_exceeded
In-Reply-To: <FHndpnxzk5zCQa0MKA3FumQg5UEP4tK-qcFlBqQWlbA=.eb85506c-9070-47ef-a26a-f3d9e97ac69c@github.com>
References: <FHndpnxzk5zCQa0MKA3FumQg5UEP4tK-qcFlBqQWlbA=.eb85506c-9070-47ef-a26a-f3d9e97ac69c@github.com>
Message-ID: <sioPDyjshfTpsbvAAsLiTzGwfVOhBJa-7pf17L5aMKU=.13d441bd-a754-4a9f-9bc4-8918b497198a@github.com>

On Tue, 13 Jun 2023 09:05:59 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Trivial removing dead code.

This pull request has now been integrated.

Changeset: 63843b11
Author:    Albert Mingkun Yang <ayang at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/63843b1153c1d1ab8716895567e7385ad09d48fd
Stats:     4 lines in 2 files changed: 0 ins; 4 del; 0 mod

8309907: Remove unused _print_gc_overhead_limit_would_be_exceeded

Reviewed-by: tschatzl

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

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

From naoto at openjdk.org  Tue Jun 13 17:56:57 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 13 Jun 2023 17:56:57 GMT
Subject: RFR: 8309622: Re-examine the cache mechanism in BaseLocale [v3]
In-Reply-To: <5MqmN4P1TLKDCfXPhKWrH1b2FTgOXmjtKgd1bVXDd_M=.2000f20d-365d-48dc-bc37-45d8bcb9447f@github.com>
References: <5MqmN4P1TLKDCfXPhKWrH1b2FTgOXmjtKgd1bVXDd_M=.2000f20d-365d-48dc-bc37-45d8bcb9447f@github.com>
Message-ID: <fCAxvr4_FpMeWhmZdgF2k3CUaPlIESDD0wda2N4haDM=.a238b319-720d-4ee2-b659-81d717a59d37@github.com>

> This is stemming from the PR: https://github.com/openjdk/jdk/pull/14211 where aggressive GC can cause NPE in `BaseLocale$Key` class. I refactored the in-house cache with WeakHashMap, and removed the Key class as it is no longer needed (thus the original NPE will no longer be possible). Also with the new JMH test case, it gains some performance improvement:
> 
> (w/o fix)
> 
> Benchmark                       Mode  Cnt      Score     Error  Units
> LocaleCache.testForLanguageTag  avgt   20   5781.275 ? 569.580  ns/op
> LocaleCache.testLocaleOf        avgt   20  62564.079 ? 406.697  ns/op
> 
> (w/ fix)
> Benchmark                       Mode  Cnt      Score     Error  Units
> LocaleCache.testForLanguageTag  avgt   20   4801.175 ? 371.830  ns/op
> LocaleCache.testLocaleOf        avgt   20  60394.652 ? 352.471  ns/op

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

  Addressing review comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14404/files
  - new: https://git.openjdk.org/jdk/pull/14404/files/fb1535ff..ac6ea421

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

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

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

From naoto at openjdk.org  Tue Jun 13 18:00:53 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 13 Jun 2023 18:00:53 GMT
Subject: RFR: 8309622: Re-examine the cache mechanism in BaseLocale [v2]
In-Reply-To: <hGqRm8mQ8Fit1yhFhVVJt2UnUMq1d2U3BgEUhXYJlWI=.ebe2f332-86b1-4e08-8e25-c39dba2dd87d@github.com>
References: <5MqmN4P1TLKDCfXPhKWrH1b2FTgOXmjtKgd1bVXDd_M=.2000f20d-365d-48dc-bc37-45d8bcb9447f@github.com>
 <I1w5uzuRAmk1eTqIwe1IMrxz5J39yZN3YYuMjHkYFTU=.cfe0ec7c-edd7-46e2-8444-0192d88022c8@github.com>
 <hGqRm8mQ8Fit1yhFhVVJt2UnUMq1d2U3BgEUhXYJlWI=.ebe2f332-86b1-4e08-8e25-c39dba2dd87d@github.com>
Message-ID: <ECgM_b7fO1Hcxcfv79KxBGH6Q8ooCSS-NFZCjNUTCDs=.e6a92f6c-2e6c-4fda-88d3-570f04e98df7@github.com>

On Tue, 13 Jun 2023 11:22:11 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Addressing comments (test grouping, synchronization), minor optimization on loop lookup
>
> src/java.base/share/classes/sun/util/locale/BaseLocale.java line 166:
> 
>> 164:         // can subsequently be used by the Locale instance which
>> 165:         // guarantees the locale components are properly cased/interned.
>> 166:         synchronized (BaseLocale.class) {
> 
> The simplification is good but I wonder if this coarse locking is going to be a problem, do we need to use some concurrent to avoid contention here?

Replaced it with a ReentrantLock

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14404#discussion_r1228504526

From naoto at openjdk.org  Tue Jun 13 18:00:57 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 13 Jun 2023 18:00:57 GMT
Subject: RFR: 8309622: Re-examine the cache mechanism in BaseLocale [v2]
In-Reply-To: <MivX2vJkygO5loJYR6IttGKuD9z5K0zOFgn_pfhUAB4=.25630661-8ee7-484d-b3e9-39212fb22a8f@github.com>
References: <5MqmN4P1TLKDCfXPhKWrH1b2FTgOXmjtKgd1bVXDd_M=.2000f20d-365d-48dc-bc37-45d8bcb9447f@github.com>
 <I1w5uzuRAmk1eTqIwe1IMrxz5J39yZN3YYuMjHkYFTU=.cfe0ec7c-edd7-46e2-8444-0192d88022c8@github.com>
 <MivX2vJkygO5loJYR6IttGKuD9z5K0zOFgn_pfhUAB4=.25630661-8ee7-484d-b3e9-39212fb22a8f@github.com>
Message-ID: <FgaAVqdLpB3Raw_J5LTFCFKjrapHhgOuR6_LoDcFx94=.c7246736-c8cb-4959-9830-3b071ebef54a@github.com>

On Tue, 13 Jun 2023 13:09:49 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Addressing comments (test grouping, synchronization), minor optimization on loop lookup
>
> test/micro/org/openjdk/bench/java/util/LocaleCache.java line 58:
> 
>> 56:                 throw new RuntimeException("Different Locale was created");
>> 57:             }
>> 58:             previous =  l;
> 
> Suggestion:
> 
>             previous = l;

Fixed

> test/micro/org/openjdk/bench/java/util/LocaleCache.java line 70:
> 
>> 68:                 throw new RuntimeException("Different Locale was created");
>> 69:             }
>> 70:             previous =  l;
> 
> Suggestion:
> 
>             previous = l;

Fixed

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14404#discussion_r1228504659
PR Review Comment: https://git.openjdk.org/jdk/pull/14404#discussion_r1228504936

From shade at openjdk.org  Tue Jun 13 19:16:50 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 13 Jun 2023 19:16:50 GMT
Subject: RFR: 8309956: Shenandoah: Strengthen the mark word check in string
 dedup
Message-ID: <cPP_wuHfIu9xxso8rcHosrnoJsT_K5obf1mQ4NO9o7I=.0fe8713e-83ac-4243-af8b-2ccaa09b72e5@github.com>

See the bug for details.

Additional testing:
 - [x] macos-aarch64-server-fastdebug, `hotspot_gc_shenandoah`

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

Commit messages:
 - Fix

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

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

From wkemper at openjdk.org  Tue Jun 13 21:30:51 2023
From: wkemper at openjdk.org (William Kemper)
Date: Tue, 13 Jun 2023 21:30:51 GMT
Subject: RFR: 8309956: Shenandoah: Strengthen the mark word check in string
 dedup
In-Reply-To: <cPP_wuHfIu9xxso8rcHosrnoJsT_K5obf1mQ4NO9o7I=.0fe8713e-83ac-4243-af8b-2ccaa09b72e5@github.com>
References: <cPP_wuHfIu9xxso8rcHosrnoJsT_K5obf1mQ4NO9o7I=.0fe8713e-83ac-4243-af8b-2ccaa09b72e5@github.com>
Message-ID: <_rnPmpNFwBZGc2SDmYG_3aSAP-xayoAUq9bRatEN9Bc=.f756df0d-64c2-48b0-9ecc-01c03259c973@github.com>

On Tue, 13 Jun 2023 19:10:15 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> See the bug for details.
> 
> Additional testing:
>  - [x] macos-aarch64-server-fastdebug, `hotspot_gc_shenandoah`

LGTM.

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

Marked as reviewed by wkemper (no project role).

PR Review: https://git.openjdk.org/jdk/pull/14455#pullrequestreview-1478078790

From zgu at openjdk.org  Tue Jun 13 23:13:57 2023
From: zgu at openjdk.org (Zhengyu Gu)
Date: Tue, 13 Jun 2023 23:13:57 GMT
Subject: RFR: 8309956: Shenandoah: Strengthen the mark word check in string
 dedup
In-Reply-To: <cPP_wuHfIu9xxso8rcHosrnoJsT_K5obf1mQ4NO9o7I=.0fe8713e-83ac-4243-af8b-2ccaa09b72e5@github.com>
References: <cPP_wuHfIu9xxso8rcHosrnoJsT_K5obf1mQ4NO9o7I=.0fe8713e-83ac-4243-af8b-2ccaa09b72e5@github.com>
Message-ID: <_-BlC41WZUJMyibAvkDCFN9MEHny3aalOS7V3gbZUEI=.a2e25607-bf90-4a01-bdf4-de605d49d14c@github.com>

On Tue, 13 Jun 2023 19:10:15 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> See the bug for details.
> 
> Additional testing:
>  - [x] macos-aarch64-server-fastdebug, `hotspot_gc_shenandoah`

LGTM

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

Marked as reviewed by zgu (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14455#pullrequestreview-1478194338

From amenkov at openjdk.org  Wed Jun 14 01:08:03 2023
From: amenkov at openjdk.org (Alex Menkov)
Date: Wed, 14 Jun 2023 01:08:03 GMT
Subject: RFR: 8309663: test fails
 "assert(check_alignment(result)) failed: address not aligned:
 0x00000008baadbabe"
Message-ID: <fqPCs7pEUNY9ODLKOspB5buuBWtDPfKmouI8p05KBKw=.16dec9bd-ca79-41ef-808f-4967073151d2@github.com>

If virtual thread has frames in stackChunks, need to apply load barriers before processing nmethods (javaVFrame::locals() and javaVFrame::expressions() do it internally)

Testing: tier1-tier5 (still in progress);
400 runs of VThreadStackRefTest.java test on linux-x64 and linux-x64-debug with "-XX:+UseZGC -Xcomp -XX:-TieredCompilation"

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

Commit messages:
 - Added load barriers

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

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

From amenkov at openjdk.org  Wed Jun 14 01:20:56 2023
From: amenkov at openjdk.org (Alex Menkov)
Date: Wed, 14 Jun 2023 01:20:56 GMT
Subject: RFR: 8309663: test fails
 "assert(check_alignment(result)) failed: address not aligned:
 0x00000008baadbabe"
In-Reply-To: <fqPCs7pEUNY9ODLKOspB5buuBWtDPfKmouI8p05KBKw=.16dec9bd-ca79-41ef-808f-4967073151d2@github.com>
References: <fqPCs7pEUNY9ODLKOspB5buuBWtDPfKmouI8p05KBKw=.16dec9bd-ca79-41ef-808f-4967073151d2@github.com>
Message-ID: <KzkpvKHgFEo5FnXPzluO5r3rSDjx6EIzc_Oq3uj5_Z0=.40009d56-5406-46a6-8ab9-048ba7c822c0@github.com>

On Wed, 14 Jun 2023 01:02:09 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> If virtual thread has frames in stackChunks, need to apply load barriers before processing nmethods (javaVFrame::locals() and javaVFrame::expressions() do it internally)
> 
> Testing: tier1-tier5 (still in progress);
> 400 runs of VThreadStackRefTest.java test on linux-x64 and linux-x64-debug with "-XX:+UseZGC -Xcomp -XX:-TieredCompilation"

added serviceability as it was not added automatically

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

PR Comment: https://git.openjdk.org/jdk/pull/14460#issuecomment-1590288091

From aboldtch at openjdk.org  Wed Jun 14 06:00:57 2023
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Wed, 14 Jun 2023 06:00:57 GMT
Subject: RFR: 8309890: TestStringDeduplicationInterned.java waits for the
 wrong condition [v2]
In-Reply-To: <DnnD4DqHsl6OIl8WqvQNMdidQBCjl2N3sDPjxN23M2U=.ad3ce08d-a79d-4fbf-afcf-4d25e7214afe@github.com>
References: <xNymjGQ0SGb4FA5rzcI4OxwV0MkuWTYFUbMgc-mxzKA=.72c6232f-62df-4f6c-a5f5-51239da5146c@github.com>
 <DnnD4DqHsl6OIl8WqvQNMdidQBCjl2N3sDPjxN23M2U=.ad3ce08d-a79d-4fbf-afcf-4d25e7214afe@github.com>
Message-ID: <_tfMwL_0rptJ58O5bvpBWuuO-8XMgdZtS2GMZotbKPA=.c92ee481-9e44-4c98-82f0-a4d950fd566c@github.com>

On Tue, 13 Jun 2023 09:16:54 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> There's a section in the test that waits up to 10 seconds for a string to be deduplicated and then does a final verification that the string was correctly deduplicated. However, the initial waiting gets passed the wrong comparison string, which has the effect that this test always waits for 10 seconds before proceeding.
>> 
>> The problem is here:
>> 
>>             if (!waitForDeduplication(dupString3, baseString)) {
>>                 if (getValue(dupString3) != getValue(internedString)) {
>> 
>> where the first line should say:
>> 
>>             if (!waitForDeduplication(dupString3, internedString)) {
>
> Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review kbarrett

Marked as reviewed by aboldtch (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/14437#pullrequestreview-1478537022

From stefank at openjdk.org  Wed Jun 14 06:33:04 2023
From: stefank at openjdk.org (Stefan Karlsson)
Date: Wed, 14 Jun 2023 06:33:04 GMT
Subject: RFR: 8309890: TestStringDeduplicationInterned.java waits for the
 wrong condition [v2]
In-Reply-To: <DnnD4DqHsl6OIl8WqvQNMdidQBCjl2N3sDPjxN23M2U=.ad3ce08d-a79d-4fbf-afcf-4d25e7214afe@github.com>
References: <xNymjGQ0SGb4FA5rzcI4OxwV0MkuWTYFUbMgc-mxzKA=.72c6232f-62df-4f6c-a5f5-51239da5146c@github.com>
 <DnnD4DqHsl6OIl8WqvQNMdidQBCjl2N3sDPjxN23M2U=.ad3ce08d-a79d-4fbf-afcf-4d25e7214afe@github.com>
Message-ID: <0DMwwm7BfGJ0F5JPHJxYBaf-rGFwQuXi5ARpSQxOL4o=.2d3dde74-2fd8-4e8f-a3e0-2ed94a61277a@github.com>

On Tue, 13 Jun 2023 09:16:54 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> There's a section in the test that waits up to 10 seconds for a string to be deduplicated and then does a final verification that the string was correctly deduplicated. However, the initial waiting gets passed the wrong comparison string, which has the effect that this test always waits for 10 seconds before proceeding.
>> 
>> The problem is here:
>> 
>>             if (!waitForDeduplication(dupString3, baseString)) {
>>                 if (getValue(dupString3) != getValue(internedString)) {
>> 
>> where the first line should say:
>> 
>>             if (!waitForDeduplication(dupString3, internedString)) {
>
> Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review kbarrett

Thanks for the reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/14437#issuecomment-1590554053

From stefank at openjdk.org  Wed Jun 14 06:33:06 2023
From: stefank at openjdk.org (Stefan Karlsson)
Date: Wed, 14 Jun 2023 06:33:06 GMT
Subject: Integrated: 8309890: TestStringDeduplicationInterned.java waits for
 the wrong condition
In-Reply-To: <xNymjGQ0SGb4FA5rzcI4OxwV0MkuWTYFUbMgc-mxzKA=.72c6232f-62df-4f6c-a5f5-51239da5146c@github.com>
References: <xNymjGQ0SGb4FA5rzcI4OxwV0MkuWTYFUbMgc-mxzKA=.72c6232f-62df-4f6c-a5f5-51239da5146c@github.com>
Message-ID: <0CeMHf5sMsQvjKOHRBFTsN9YnB1wmFjyH4iRljm96hg=.7d8c94ac-0e48-4fbd-a247-65296e286591@github.com>

On Tue, 13 Jun 2023 05:48:32 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> There's a section in the test that waits up to 10 seconds for a string to be deduplicated and then does a final verification that the string was correctly deduplicated. However, the initial waiting gets passed the wrong comparison string, which has the effect that this test always waits for 10 seconds before proceeding.
> 
> The problem is here:
> 
>             if (!waitForDeduplication(dupString3, baseString)) {
>                 if (getValue(dupString3) != getValue(internedString)) {
> 
> where the first line should say:
> 
>             if (!waitForDeduplication(dupString3, internedString)) {

This pull request has now been integrated.

Changeset: 63fe413d
Author:    Stefan Karlsson <stefank at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/63fe413d93861c79af5587859f01822980969c24
Stats:     4 lines in 1 file changed: 0 ins; 2 del; 2 mod

8309890: TestStringDeduplicationInterned.java waits for the wrong condition

Reviewed-by: aboldtch, kbarrett

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

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

From ysr at openjdk.org  Wed Jun 14 06:49:56 2023
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Wed, 14 Jun 2023 06:49:56 GMT
Subject: RFR: 8309956: Shenandoah: Strengthen the mark word check in string
 dedup
In-Reply-To: <cPP_wuHfIu9xxso8rcHosrnoJsT_K5obf1mQ4NO9o7I=.0fe8713e-83ac-4243-af8b-2ccaa09b72e5@github.com>
References: <cPP_wuHfIu9xxso8rcHosrnoJsT_K5obf1mQ4NO9o7I=.0fe8713e-83ac-4243-af8b-2ccaa09b72e5@github.com>
Message-ID: <TSYg5awk8N7rT_jvdY9swQf4l8ZbrQXcpfKC7VEjT1Y=.a4c6ba9a-36d0-4522-a682-308abe5ed327@github.com>

On Tue, 13 Jun 2023 19:10:15 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> See the bug for details.
> 
> Additional testing:
>  - [x] macos-aarch64-server-fastdebug, `hotspot_gc_shenandoah`

?

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

Marked as reviewed by ysr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14455#pullrequestreview-1478633629

From sspitsyn at openjdk.org  Wed Jun 14 09:10:59 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 14 Jun 2023 09:10:59 GMT
Subject: RFR: 8309663: test fails
 "assert(check_alignment(result)) failed: address not aligned:
 0x00000008baadbabe"
In-Reply-To: <fqPCs7pEUNY9ODLKOspB5buuBWtDPfKmouI8p05KBKw=.16dec9bd-ca79-41ef-808f-4967073151d2@github.com>
References: <fqPCs7pEUNY9ODLKOspB5buuBWtDPfKmouI8p05KBKw=.16dec9bd-ca79-41ef-808f-4967073151d2@github.com>
Message-ID: <Q5PaUjdpGBvTADcC1vItvofC1VMICsdSYvoVsTslqzA=.e03a47a5-a331-4d13-b622-f203e3430404@github.com>

On Wed, 14 Jun 2023 01:02:09 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> If virtual thread has frames in stackChunks, need to apply load barriers before processing nmethods (javaVFrame::locals() and javaVFrame::expressions() do it internally)
> 
> Testing: tier1-tier5 (still in progress);
> 400 runs of VThreadStackRefTest.java test on linux-x64 and linux-x64-debug with "-XX:+UseZGC -Xcomp -XX:-TieredCompilation"

src/hotspot/share/prims/jvmtiTagMap.cpp line 2325:

> 2323:         // Need to apply load barriers for unmounted vthreads.
> 2324:         nmethod* nm = jvf->cb()->as_nmethod();
> 2325:         nm->run_nmethod_entry_barrier();

This looks good in general.
However, I'm looking at the `stackChunkOopDesc::do_barriers0()` implementation and wonder if a similar trick is needed for interpreter frames (to support `Class Redefinition`):

template <stackChunkOopDesc::BarrierType barrier, ChunkFrames frame_kind, typename RegisterMapT>
void stackChunkOopDesc::do_barriers0(const StackChunkFrameStream<frame_kind>& f, const RegisterMapT* map) {
  // We need to invoke the write barriers so as not to miss oops in old chunks that haven't yet been concurrently scanned
  assert (!f.is_done(), "");

  if (f.is_interpreted()) {
    Method* m = f.to_frame().interpreter_frame_method();
    // Class redefinition support
    m->record_gc_epoch();
  } else if (f.is_compiled()) {
    nmethod* nm = f.cb()->as_nmethod();
    // The entry barrier takes care of having the right synchronization
    // when keeping the nmethod alive during concurrent execution.
    nm->run_nmethod_entry_barrier();
    // There is no need to mark the Method, as class redefinition will walk the
    // CodeCache, noting their Methods
  }
  . . .

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14460#discussion_r1229273861

From shade at openjdk.org  Wed Jun 14 10:50:49 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 14 Jun 2023 10:50:49 GMT
Subject: RFR: 8309956: Shenandoah: Strengthen the mark word check in string
 dedup [v2]
In-Reply-To: <cPP_wuHfIu9xxso8rcHosrnoJsT_K5obf1mQ4NO9o7I=.0fe8713e-83ac-4243-af8b-2ccaa09b72e5@github.com>
References: <cPP_wuHfIu9xxso8rcHosrnoJsT_K5obf1mQ4NO9o7I=.0fe8713e-83ac-4243-af8b-2ccaa09b72e5@github.com>
Message-ID: <zF0ayJ_KBHOmA-q0gr2QPUj0kSLS0LO9rr7-WugkZXU=.5cf7196f-411b-4ef5-9621-6d7344f97369@github.com>

> See the bug for details.
> 
> Additional testing:
>  - [x] macos-aarch64-server-fastdebug, `hotspot_gc_shenandoah`

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

 - Merge branch 'master' into JDK-8309956-shenandoah-strdedup-check
 - Fix

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14455/files
  - new: https://git.openjdk.org/jdk/pull/14455/files/facfb975..fb8a70b2

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

  Stats: 68073 lines in 1080 files changed: 50776 ins; 13698 del; 3599 mod
  Patch: https://git.openjdk.org/jdk/pull/14455.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14455/head:pull/14455

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

From alanb at openjdk.org  Wed Jun 14 13:17:04 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 14 Jun 2023 13:17:04 GMT
Subject: RFR: 8309622: Re-examine the cache mechanism in BaseLocale [v2]
In-Reply-To: <ECgM_b7fO1Hcxcfv79KxBGH6Q8ooCSS-NFZCjNUTCDs=.e6a92f6c-2e6c-4fda-88d3-570f04e98df7@github.com>
References: <5MqmN4P1TLKDCfXPhKWrH1b2FTgOXmjtKgd1bVXDd_M=.2000f20d-365d-48dc-bc37-45d8bcb9447f@github.com>
 <I1w5uzuRAmk1eTqIwe1IMrxz5J39yZN3YYuMjHkYFTU=.cfe0ec7c-edd7-46e2-8444-0192d88022c8@github.com>
 <hGqRm8mQ8Fit1yhFhVVJt2UnUMq1d2U3BgEUhXYJlWI=.ebe2f332-86b1-4e08-8e25-c39dba2dd87d@github.com>
 <ECgM_b7fO1Hcxcfv79KxBGH6Q8ooCSS-NFZCjNUTCDs=.e6a92f6c-2e6c-4fda-88d3-570f04e98df7@github.com>
Message-ID: <IRgvtRmbZ7SoAby8TV4ARmi5K1022K24tc1v85RBexs=.f09c4d0e-1f50-4f6c-8001-d2c687848c78@github.com>

On Tue, 13 Jun 2023 17:57:36 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Replaced it with a ReentrantLock

The concern is that this is a system-wide lock and so creates the potential for contention when many threads are bashing on Locale.of and other methods. Moving to use the JDK's ReferenceKeyMap with a CHM, or roll something similar, would avoid that but I can't helping feeling that the lookup is already a bit complicated. Right now, obtaining a Locale will create a non-normalized BaseLocale to use as a key, use the key to get (or compute) the normalized BaseLocale, then the normalized BaseLocale as a key for the Locale cache. Since it's early in JDK 22 it makes me wonder if we should step back and re-think this.

On the WHM, then it is a bit surprising that a Locales don't keep the non-normalized BaseLocale reachable. I assume this means that entries will be expunged from the CACHE if there is a reference processing between lookups. Also using weak refs makes it harder to reason about when the other part of the caching (in LocaleObjectCache) is used soft refs. I think this is another reason to think about a larger overhaul.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14404#discussion_r1229601286

From dfuchs at openjdk.org  Wed Jun 14 13:34:59 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 14 Jun 2023 13:34:59 GMT
Subject: RFR: 8309622: Re-examine the cache mechanism in BaseLocale [v2]
In-Reply-To: <IRgvtRmbZ7SoAby8TV4ARmi5K1022K24tc1v85RBexs=.f09c4d0e-1f50-4f6c-8001-d2c687848c78@github.com>
References: <5MqmN4P1TLKDCfXPhKWrH1b2FTgOXmjtKgd1bVXDd_M=.2000f20d-365d-48dc-bc37-45d8bcb9447f@github.com>
 <I1w5uzuRAmk1eTqIwe1IMrxz5J39yZN3YYuMjHkYFTU=.cfe0ec7c-edd7-46e2-8444-0192d88022c8@github.com>
 <hGqRm8mQ8Fit1yhFhVVJt2UnUMq1d2U3BgEUhXYJlWI=.ebe2f332-86b1-4e08-8e25-c39dba2dd87d@github.com>
 <ECgM_b7fO1Hcxcfv79KxBGH6Q8ooCSS-NFZCjNUTCDs=.e6a92f6c-2e6c-4fda-88d3-570f04e98df7@github.com>
 <IRgvtRmbZ7SoAby8TV4ARmi5K1022K24tc1v85RBexs=.f09c4d0e-1f50-4f6c-8001-d2c687848c78@github.com>
Message-ID: <_xpukvI9UxxknHQYdoBKxkt98mUJu1FCli6BdnxJylE=.a8c63915-2ae4-4ce6-ad73-e6ee42f5db0a@github.com>

On Wed, 14 Jun 2023 13:13:50 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Replaced it with a ReentrantLock
>
>> Replaced it with a ReentrantLock
> 
> The concern is that this is a system-wide lock and so creates the potential for contention when many threads are bashing on Locale.of and other methods. Moving to use the JDK's ReferenceKeyMap with a CHM, or roll something similar, would avoid that but I can't helping feeling that the lookup is already a bit complicated. Right now, obtaining a Locale will create a non-normalized BaseLocale to use as a key, use the key to get (or compute) the normalized BaseLocale, then the normalized BaseLocale as a key for the Locale cache. Since it's early in JDK 22 it makes me wonder if we should step back and re-think this.
> 
> On the WHM, then it is a bit surprising that a Locales don't keep the non-normalized BaseLocale reachable. I assume this means that entries will be expunged from the CACHE if there is a reference processing between lookups. Also using weak refs makes it harder to reason about when the other part of the caching (in LocaleObjectCache) is used soft refs. I think this is another reason to think about a larger overhaul.

One possibility would be to have the whole cache be soft-referenced, instead of individually weak-referencing the keys.
Something like Reference<Map<BaseLocale, BaseLocale>> where Reference is a SoftReference and Map is a ConcurrentHashMap. 
But then you'd have to deal with a non-final field for the reference to the cache, and creating a new map and a new cache (and new SoftReference) when the reference to the cache gets cleared, and dealing with potential race conditions at that time.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14404#discussion_r1229625153

From ayang at openjdk.org  Wed Jun 14 14:16:01 2023
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Wed, 14 Jun 2023 14:16:01 GMT
Subject: RFR: 8309960: ParallelGC young collections very slow in DelayInducer
Message-ID: <VoGzDvHPG1PtlXJFJ8SLroRYwEPwsA-Zocu4VtTYoe4=.0570f3cd-01ee-41de-90d4-56b02805982a@github.com>

Using the benchmark from the JBS ticket, one can observe the young-gc-pause regression is gone.

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

Commit messages:
 - pgc-overflow-queue

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

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

From tschatzl at openjdk.org  Wed Jun 14 14:19:02 2023
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Wed, 14 Jun 2023 14:19:02 GMT
Subject: RFR: 8309960: ParallelGC young collections very slow in
 DelayInducer
In-Reply-To: <VoGzDvHPG1PtlXJFJ8SLroRYwEPwsA-Zocu4VtTYoe4=.0570f3cd-01ee-41de-90d4-56b02805982a@github.com>
References: <VoGzDvHPG1PtlXJFJ8SLroRYwEPwsA-Zocu4VtTYoe4=.0570f3cd-01ee-41de-90d4-56b02805982a@github.com>
Message-ID: <R6g_JIClHzMt9LcgMgOlAJGeRI4sC720HcehVgYuGzk=.bfcdbbe2-8c3e-4ebc-8554-c9a729623199@github.com>

On Wed, 14 Jun 2023 14:09:07 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Using the benchmark from the JBS ticket, one can observe the young-gc-pause regression is gone.

Changes requested by tschatzl (Reviewer).

src/hotspot/share/gc/parallel/psPromotionManager.cpp line 248:

> 246:       // pause, so processing locally until large-objArray-split is implemented.
> 247: 
> 248:       process_popped_location_depth(task);

Suggestion:

      // In PSCardTable::scavenge_contents_parallel(), when work is distributed
      // among different workers, an object is never split between multiple workers.
      // Therefore, if a worker gets owned a large objArray, it may accumulate
      // many tasks (corresponding to every element in this array) in its
      // task queue. When there are too many overflow tasks, publishing them
      // (via try_push_to_taskqueue()) can incur noticeable overhead in Young GC
      // pause, so it is better to process them locally until large-objArray-splitting is implemented.
      process_popped_location_depth(task);

Feel free to incorporate only parts of this suggestion.

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

PR Review: https://git.openjdk.org/jdk/pull/14469#pullrequestreview-1479571793
PR Review Comment: https://git.openjdk.org/jdk/pull/14469#discussion_r1229694942

From ayang at openjdk.org  Wed Jun 14 14:59:27 2023
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Wed, 14 Jun 2023 14:59:27 GMT
Subject: RFR: 8309960: ParallelGC young collections very slow in
 DelayInducer [v2]
In-Reply-To: <VoGzDvHPG1PtlXJFJ8SLroRYwEPwsA-Zocu4VtTYoe4=.0570f3cd-01ee-41de-90d4-56b02805982a@github.com>
References: <VoGzDvHPG1PtlXJFJ8SLroRYwEPwsA-Zocu4VtTYoe4=.0570f3cd-01ee-41de-90d4-56b02805982a@github.com>
Message-ID: <dO3YDOs4X3Mour2namEZh3_84OHxwlOZ18Nr_W2lYN4=.59a11853-b2ff-407b-9e6d-a464cc624ba0@github.com>

> Using the benchmark from the JBS ticket, one can observe the young-gc-pause regression is gone.

Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision:

  Update src/hotspot/share/gc/parallel/psPromotionManager.cpp
  
  Co-authored-by: Thomas Schatzl <59967451+tschatzl at users.noreply.github.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14469/files
  - new: https://git.openjdk.org/jdk/pull/14469/files/49e97995..90db6a63

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

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

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

From tschatzl at openjdk.org  Wed Jun 14 15:22:01 2023
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Wed, 14 Jun 2023 15:22:01 GMT
Subject: RFR: 8309960: ParallelGC young collections very slow in
 DelayInducer [v2]
In-Reply-To: <dO3YDOs4X3Mour2namEZh3_84OHxwlOZ18Nr_W2lYN4=.59a11853-b2ff-407b-9e6d-a464cc624ba0@github.com>
References: <VoGzDvHPG1PtlXJFJ8SLroRYwEPwsA-Zocu4VtTYoe4=.0570f3cd-01ee-41de-90d4-56b02805982a@github.com>
 <dO3YDOs4X3Mour2namEZh3_84OHxwlOZ18Nr_W2lYN4=.59a11853-b2ff-407b-9e6d-a464cc624ba0@github.com>
Message-ID: <8ZHm8RZcLPPQVWGTvLtwvKEiCQYKvUpDnCgT5DC4zII=.e9894cc3-5bd5-4386-a54a-be67af9f6f7e@github.com>

On Wed, 14 Jun 2023 14:59:27 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Using the benchmark from the JBS ticket, one can observe the young-gc-pause regression is gone.
>
> Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/hotspot/share/gc/parallel/psPromotionManager.cpp
>   
>   Co-authored-by: Thomas Schatzl <59967451+tschatzl at users.noreply.github.com>

lgtm.

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

Marked as reviewed by tschatzl (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14469#pullrequestreview-1479739205

From tschatzl at openjdk.org  Wed Jun 14 15:49:59 2023
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Wed, 14 Jun 2023 15:49:59 GMT
Subject: RFR: 8309899: Rename PtrQueueSet::buffer_size()
In-Reply-To: <mmdB2PB2JtgaIrWdKFy6gF3ooTBSrUY_kDnnF271Nx0=.acb85028-8e69-4cbb-b6db-8b54bd07a241@github.com>
References: <mmdB2PB2JtgaIrWdKFy6gF3ooTBSrUY_kDnnF271Nx0=.acb85028-8e69-4cbb-b6db-8b54bd07a241@github.com>
Message-ID: <1hSjYhSOhN-pHxcpgpi9Gnt_XFcjWkpwuz5G2cniXwo=.e418e69e-b4ff-4d70-ad14-ffaa13accc4e@github.com>

On Tue, 13 Jun 2023 07:28:32 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this renaming of PtrQueueSet::buffer_size to buffer_capacity,
> along with some associated function and variable renamings.
> 
> Despite the number of files and lines changed, it's just a name change, so
> perhaps it's trivial?
> 
> Testing:
> mach5 tier1
> 
> Note: There weren't any changes needed in Shenandoah, even though it uses the
> SATBMarkQueue stuff.

lgtm

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

Marked as reviewed by tschatzl (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14439#pullrequestreview-1479800167

From naoto at openjdk.org  Wed Jun 14 16:07:59 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 14 Jun 2023 16:07:59 GMT
Subject: RFR: 8309622: Re-examine the cache mechanism in BaseLocale [v2]
In-Reply-To: <_xpukvI9UxxknHQYdoBKxkt98mUJu1FCli6BdnxJylE=.a8c63915-2ae4-4ce6-ad73-e6ee42f5db0a@github.com>
References: <5MqmN4P1TLKDCfXPhKWrH1b2FTgOXmjtKgd1bVXDd_M=.2000f20d-365d-48dc-bc37-45d8bcb9447f@github.com>
 <I1w5uzuRAmk1eTqIwe1IMrxz5J39yZN3YYuMjHkYFTU=.cfe0ec7c-edd7-46e2-8444-0192d88022c8@github.com>
 <hGqRm8mQ8Fit1yhFhVVJt2UnUMq1d2U3BgEUhXYJlWI=.ebe2f332-86b1-4e08-8e25-c39dba2dd87d@github.com>
 <ECgM_b7fO1Hcxcfv79KxBGH6Q8ooCSS-NFZCjNUTCDs=.e6a92f6c-2e6c-4fda-88d3-570f04e98df7@github.com>
 <IRgvtRmbZ7SoAby8TV4ARmi5K1022K24tc1v85RBexs=.f09c4d0e-1f50-4f6c-8001-d2c687848c78@github.com>
 <_xpukvI9UxxknHQYdoBKxkt98mUJu1FCli6BdnxJylE=.a8c63915-2ae4-4ce6-ad73-e6ee42f5db0a@github.com>
Message-ID: <95kv6OUnZpcUEpnvAyZZYgeA7JTMmuau8NMBlb62u0Y=.a47b5d21-669c-4633-93f9-eaaf27657109@github.com>

On Wed, 14 Jun 2023 13:29:39 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>>> Replaced it with a ReentrantLock
>> 
>> The concern is that this is a system-wide lock and so creates the potential for contention when many threads are bashing on Locale.of and other methods. Moving to use the JDK's ReferenceKeyMap with a CHM, or roll something similar, would avoid that but I can't helping feeling that the lookup is already a bit complicated. Right now, obtaining a Locale will create a non-normalized BaseLocale to use as a key, use the key to get (or compute) the normalized BaseLocale, then the normalized BaseLocale as a key for the Locale cache. Since it's early in JDK 22 it makes me wonder if we should step back and re-think this.
>> 
>> On the WHM, then it is a bit surprising that a Locales don't keep the non-normalized BaseLocale reachable. I assume this means that entries will be expunged from the CACHE if there is a reference processing between lookups. Also using weak refs makes it harder to reason about when the other part of the caching (in LocaleObjectCache) is used soft refs. I think this is another reason to think about a larger overhaul.
>
> One possibility would be to have the whole cache be soft-referenced, instead of individually weak-referencing the keys.
> Something like Reference<Map<BaseLocale, BaseLocale>> where Reference is a SoftReference and Map is a ConcurrentHashMap. 
> But then you'd have to deal with a non-final field for the reference to the cache, and creating a new map and a new cache (and new SoftReference) when the reference to the cache gets cleared, and dealing with potential race conditions at that time.

Jim's `java.lang.runtime.ReferenceKeyMap` would be a possible solution for it, although it is currently package private. But I will need to think about it more as Alan suggests.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14404#discussion_r1229857996

From zgu at openjdk.org  Wed Jun 14 16:57:11 2023
From: zgu at openjdk.org (Zhengyu Gu)
Date: Wed, 14 Jun 2023 16:57:11 GMT
Subject: RFR: 8310037: Leak MutableSpaceUsedHelper in parallel GC's
 SpaceCounters class
Message-ID: <HZhfPsRC9Imnoeyr5oQFxRTy9YkvMHqizuGTws83IeY=.710793c8-c2b5-4a72-b8b8-7d2e56c8123f@github.com>

Please review this small fix for memory leak.

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

Commit messages:
 - update copyright year
 - 8310037: Leak MutableSpaceUsedHelper in parallel GC's SpaceCounters class

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

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

From shade at openjdk.org  Wed Jun 14 17:00:08 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 14 Jun 2023 17:00:08 GMT
Subject: RFR: 8309956: Shenandoah: Strengthen the mark word check in string
 dedup [v2]
In-Reply-To: <zF0ayJ_KBHOmA-q0gr2QPUj0kSLS0LO9rr7-WugkZXU=.5cf7196f-411b-4ef5-9621-6d7344f97369@github.com>
References: <cPP_wuHfIu9xxso8rcHosrnoJsT_K5obf1mQ4NO9o7I=.0fe8713e-83ac-4243-af8b-2ccaa09b72e5@github.com>
 <zF0ayJ_KBHOmA-q0gr2QPUj0kSLS0LO9rr7-WugkZXU=.5cf7196f-411b-4ef5-9621-6d7344f97369@github.com>
Message-ID: <cy0LH2I-Sw2stnU3-U-rtRHlWM-1JXdNZuh6cnKaiMc=.101fd171-3752-49d0-b265-099231e033ea@github.com>

On Wed, 14 Jun 2023 10:50:49 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> See the bug for details.
>> 
>> Additional testing:
>>  - [x] macos-aarch64-server-fastdebug, `hotspot_gc_shenandoah`
>
> Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK-8309956-shenandoah-strdedup-check
>  - Fix

Thank you all!

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

PR Comment: https://git.openjdk.org/jdk/pull/14455#issuecomment-1591652888

From shade at openjdk.org  Wed Jun 14 17:00:10 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 14 Jun 2023 17:00:10 GMT
Subject: Integrated: 8309956: Shenandoah: Strengthen the mark word check in
 string dedup
In-Reply-To: <cPP_wuHfIu9xxso8rcHosrnoJsT_K5obf1mQ4NO9o7I=.0fe8713e-83ac-4243-af8b-2ccaa09b72e5@github.com>
References: <cPP_wuHfIu9xxso8rcHosrnoJsT_K5obf1mQ4NO9o7I=.0fe8713e-83ac-4243-af8b-2ccaa09b72e5@github.com>
Message-ID: <45m4_4TH67yQsWAgyf8PyL9MvTPIv3J99FtaYM3eUVw=.9ab02024-6863-4b5d-acb9-27fc8b72f623@github.com>

On Tue, 13 Jun 2023 19:10:15 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> See the bug for details.
> 
> Additional testing:
>  - [x] macos-aarch64-server-fastdebug, `hotspot_gc_shenandoah`

This pull request has now been integrated.

Changeset: 57b82512
Author:    Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/57b8251241e2044d5039ce162bf4637a9b2e5466
Stats:     8 lines in 1 file changed: 1 ins; 0 del; 7 mod

8309956: Shenandoah: Strengthen the mark word check in string dedup

Reviewed-by: wkemper, zgu, ysr

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

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

From shade at openjdk.org  Wed Jun 14 17:15:23 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 14 Jun 2023 17:15:23 GMT
Subject: RFR: 8309956: Shenandoah: Strengthen the mark word check in string
 dedup
Message-ID: <9SkcjmZCZYU5XfoCXff171H3FKz6hB8L7oUcD6SeIfk=.41a6b96d-a5b4-4202-9b0b-023970d18598@github.com>

Clean backport to improve Shenandoah reliability.

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

Commit messages:
 - Backport 57b8251241e2044d5039ce162bf4637a9b2e5466

Changes: https://git.openjdk.org/jdk21/pull/19/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk21&pr=19&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8309956
  Stats: 8 lines in 1 file changed: 1 ins; 0 del; 7 mod
  Patch: https://git.openjdk.org/jdk21/pull/19.diff
  Fetch: git fetch https://git.openjdk.org/jdk21.git pull/19/head:pull/19

PR: https://git.openjdk.org/jdk21/pull/19

From ayang at openjdk.org  Wed Jun 14 19:08:57 2023
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Wed, 14 Jun 2023 19:08:57 GMT
Subject: RFR: 8309899: Rename PtrQueueSet::buffer_size()
In-Reply-To: <mmdB2PB2JtgaIrWdKFy6gF3ooTBSrUY_kDnnF271Nx0=.acb85028-8e69-4cbb-b6db-8b54bd07a241@github.com>
References: <mmdB2PB2JtgaIrWdKFy6gF3ooTBSrUY_kDnnF271Nx0=.acb85028-8e69-4cbb-b6db-8b54bd07a241@github.com>
Message-ID: <DK28dJQe3oCrvtHQsT_nIrJFxnGGN37fdIgUKTqH3II=.9bdcccd2-b5ab-4ca8-bdce-70a8399f6ad4@github.com>

On Tue, 13 Jun 2023 07:28:32 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this renaming of PtrQueueSet::buffer_size to buffer_capacity,
> along with some associated function and variable renamings.
> 
> Despite the number of files and lines changed, it's just a name change, so
> perhaps it's trivial?
> 
> Testing:
> mach5 tier1
> 
> Note: There weren't any changes needed in Shenandoah, even though it uses the
> SATBMarkQueue stuff.

Marked as reviewed by ayang (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/14439#pullrequestreview-1480122739

From amenkov at openjdk.org  Wed Jun 14 19:31:04 2023
From: amenkov at openjdk.org (Alex Menkov)
Date: Wed, 14 Jun 2023 19:31:04 GMT
Subject: RFR: 8309663: test fails
 "assert(check_alignment(result)) failed: address not aligned:
 0x00000008baadbabe"
In-Reply-To: <Q5PaUjdpGBvTADcC1vItvofC1VMICsdSYvoVsTslqzA=.e03a47a5-a331-4d13-b622-f203e3430404@github.com>
References: <fqPCs7pEUNY9ODLKOspB5buuBWtDPfKmouI8p05KBKw=.16dec9bd-ca79-41ef-808f-4967073151d2@github.com>
 <Q5PaUjdpGBvTADcC1vItvofC1VMICsdSYvoVsTslqzA=.e03a47a5-a331-4d13-b622-f203e3430404@github.com>
Message-ID: <E2U5bfawmMjCgzqe9pnzCBsL32YGRPcJUQ-ECswmLiY=.3cd140e7-1118-4485-9b32-822fa0af8f33@github.com>

On Wed, 14 Jun 2023 09:07:37 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> This looks good in general. However, I'm looking at the `stackChunkOopDesc::do_barriers0()` implementation and wonder if a similar trick is needed for interpreter frames (to support `Class Redefinition`):
> 

This code collects references from thread stack, I don't see how class redefinition can affect them

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14460#discussion_r1230074035

From iwalulya at openjdk.org  Wed Jun 14 20:00:58 2023
From: iwalulya at openjdk.org (Ivan Walulya)
Date: Wed, 14 Jun 2023 20:00:58 GMT
Subject: RFR: 8309960: ParallelGC young collections very slow in
 DelayInducer [v2]
In-Reply-To: <dO3YDOs4X3Mour2namEZh3_84OHxwlOZ18Nr_W2lYN4=.59a11853-b2ff-407b-9e6d-a464cc624ba0@github.com>
References: <VoGzDvHPG1PtlXJFJ8SLroRYwEPwsA-Zocu4VtTYoe4=.0570f3cd-01ee-41de-90d4-56b02805982a@github.com>
 <dO3YDOs4X3Mour2namEZh3_84OHxwlOZ18Nr_W2lYN4=.59a11853-b2ff-407b-9e6d-a464cc624ba0@github.com>
Message-ID: <WTgQTCks-uzqjd9bYQerxNVLJVyZJgJ-FI1yRgxXO-U=.8448f643-016f-41a2-b87d-e3ffc5976a82@github.com>

On Wed, 14 Jun 2023 14:59:27 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Using the benchmark from the JBS ticket, one can observe the young-gc-pause regression is gone.
>
> Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/hotspot/share/gc/parallel/psPromotionManager.cpp
>   
>   Co-authored-by: Thomas Schatzl <59967451+tschatzl at users.noreply.github.com>

Marked as reviewed by iwalulya (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/14469#pullrequestreview-1480197596

From rkennke at openjdk.org  Wed Jun 14 20:09:05 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Wed, 14 Jun 2023 20:09:05 GMT
Subject: RFR: 8309956: Shenandoah: Strengthen the mark word check in string
 dedup
In-Reply-To: <9SkcjmZCZYU5XfoCXff171H3FKz6hB8L7oUcD6SeIfk=.41a6b96d-a5b4-4202-9b0b-023970d18598@github.com>
References: <9SkcjmZCZYU5XfoCXff171H3FKz6hB8L7oUcD6SeIfk=.41a6b96d-a5b4-4202-9b0b-023970d18598@github.com>
Message-ID: <1P5JPpdRct95svPvbDfbqgW_htvMPNliMqtkBYxMUdM=.050333ae-ac31-4ff6-ad1d-3a7caf9bc14b@github.com>

On Wed, 14 Jun 2023 17:06:30 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Clean backport to improve Shenandoah reliability.

Looks good, thanks!

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

Marked as reviewed by rkennke (Reviewer).

PR Review: https://git.openjdk.org/jdk21/pull/19#pullrequestreview-1480207966

From kbarrett at openjdk.org  Wed Jun 14 21:59:57 2023
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 14 Jun 2023 21:59:57 GMT
Subject: RFR: 8308643: Incorrect value of 'used' jvmstat counter
In-Reply-To: <_ajTwaXeUNCGXRFCoc0A5dawGsbAQwIPd425fhjErts=.14eff994-14f8-417a-adc7-a5819f9a5181@github.com>
References: <fAi8nyXQf0uv3JMtBXgIoDdSXLOur4hIoSb4O_U2lhQ=.023b252a-d50e-4b6b-b7c0-1b7975c3206c@github.com>
 <Ib0ZJO7EkoUFfzAbieEhf7pw2I99bQTvl738ZnOymjo=.4e563938-6741-4dac-83e5-69fef34d22db@github.com>
 <KNoFTQteHu4EgXgffKEwPKZC7iMExeyxdHQSSwDSRik=.3640e65e-2a8c-4384-8967-3921155a3dbd@github.com>
 <_ajTwaXeUNCGXRFCoc0A5dawGsbAQwIPd425fhjErts=.14eff994-14f8-417a-adc7-a5819f9a5181@github.com>
Message-ID: <DmC46UBwpwaEXo00FrnjXnwbJAVA7CI_bsu8NiqcxwU=.5543c4ad-bdf3-41f1-ad10-641abf179b03@github.com>

On Tue, 30 May 2023 13:59:06 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> The _used counters only seem to be updated by GCs.  The take_sample function reports "current" data.
>
> Can `take_sample` update `_used` instead? IOW, what's the fundamental reason for having two distinct counters here?

Using the perf-counter to carry the periodic samples doesn't work. During
construction of the perf-counter, the sampler is called to provide the initial
value for the counter. Since the counter is not yet fully constructed and
accessible to the sampling function (_used is not yet initialized), this crashes.

A workaround for that problem would be to add constructors that take both a
sampler and an initial value. That's kind of messy, and doesn't seem better
than the proposed solution at hand.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14195#discussion_r1230209819

From kbarrett at openjdk.org  Wed Jun 14 21:59:58 2023
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 14 Jun 2023 21:59:58 GMT
Subject: RFR: 8308643: Incorrect value of 'used' jvmstat counter
In-Reply-To: <DmC46UBwpwaEXo00FrnjXnwbJAVA7CI_bsu8NiqcxwU=.5543c4ad-bdf3-41f1-ad10-641abf179b03@github.com>
References: <fAi8nyXQf0uv3JMtBXgIoDdSXLOur4hIoSb4O_U2lhQ=.023b252a-d50e-4b6b-b7c0-1b7975c3206c@github.com>
 <Ib0ZJO7EkoUFfzAbieEhf7pw2I99bQTvl738ZnOymjo=.4e563938-6741-4dac-83e5-69fef34d22db@github.com>
 <KNoFTQteHu4EgXgffKEwPKZC7iMExeyxdHQSSwDSRik=.3640e65e-2a8c-4384-8967-3921155a3dbd@github.com>
 <_ajTwaXeUNCGXRFCoc0A5dawGsbAQwIPd425fhjErts=.14eff994-14f8-417a-adc7-a5819f9a5181@github.com>
 <DmC46UBwpwaEXo00FrnjXnwbJAVA7CI_bsu8NiqcxwU=.5543c4ad-bdf3-41f1-ad10-641abf179b03@github.com>
Message-ID: <b1WnpJ8Lb7vVBMAUs9mUin_WrJNNBhDUTX8_Y-Ar0pI=.1cb4b1ad-0433-4542-a896-900580e953a9@github.com>

On Wed, 14 Jun 2023 21:55:27 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Can `take_sample` update `_used` instead? IOW, what's the fundamental reason for having two distinct counters here?
>
> Using the perf-counter to carry the periodic samples doesn't work. During
> construction of the perf-counter, the sampler is called to provide the initial
> value for the counter. Since the counter is not yet fully constructed and
> accessible to the sampling function (_used is not yet initialized), this crashes.
> 
> A workaround for that problem would be to add constructors that take both a
> sampler and an initial value. That's kind of messy, and doesn't seem better
> than the proposed solution at hand.

BTW, I was wrong about the _used counter only being updated by GC.  It is
updated by the sampler to the newly sampled value.  I hadn't fully chased
through the call chains before.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14195#discussion_r1230210856

From kbarrett at openjdk.org  Wed Jun 14 22:06:57 2023
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 14 Jun 2023 22:06:57 GMT
Subject: RFR: 8309899: Rename PtrQueueSet::buffer_size() [v2]
In-Reply-To: <mmdB2PB2JtgaIrWdKFy6gF3ooTBSrUY_kDnnF271Nx0=.acb85028-8e69-4cbb-b6db-8b54bd07a241@github.com>
References: <mmdB2PB2JtgaIrWdKFy6gF3ooTBSrUY_kDnnF271Nx0=.acb85028-8e69-4cbb-b6db-8b54bd07a241@github.com>
Message-ID: <WIR0Phleutxr0O8XSeGVVaX65Olx1nJIQlk_QSaO_xo=.a621dac4-2c68-4915-a543-7475eb2e6a85@github.com>

> Please review this renaming of PtrQueueSet::buffer_size to buffer_capacity,
> along with some associated function and variable renamings.
> 
> Despite the number of files and lines changed, it's just a name change, so
> perhaps it's trivial?
> 
> Testing:
> mach5 tier1
> 
> Note: There weren't any changes needed in Shenandoah, even though it uses the
> SATBMarkQueue stuff.

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

 - Merge branch 'master' into buffer-capacity
 - rename buffer_size to buffer_capacity

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14439/files
  - new: https://git.openjdk.org/jdk/pull/14439/files/200870ba..90832c78

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

  Stats: 8217 lines in 218 files changed: 1084 ins; 6843 del; 290 mod
  Patch: https://git.openjdk.org/jdk/pull/14439.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14439/head:pull/14439

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

From kbarrett at openjdk.org  Wed Jun 14 22:06:59 2023
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 14 Jun 2023 22:06:59 GMT
Subject: RFR: 8309899: Rename PtrQueueSet::buffer_size() [v2]
In-Reply-To: <1hSjYhSOhN-pHxcpgpi9Gnt_XFcjWkpwuz5G2cniXwo=.e418e69e-b4ff-4d70-ad14-ffaa13accc4e@github.com>
References: <mmdB2PB2JtgaIrWdKFy6gF3ooTBSrUY_kDnnF271Nx0=.acb85028-8e69-4cbb-b6db-8b54bd07a241@github.com>
 <1hSjYhSOhN-pHxcpgpi9Gnt_XFcjWkpwuz5G2cniXwo=.e418e69e-b4ff-4d70-ad14-ffaa13accc4e@github.com>
Message-ID: <1ZUUv0zWPk9znAdDGgqUlnvV0XigM6prBAAiqj2uYes=.e4c2127d-a0e3-45ef-b628-7adc0679daa1@github.com>

On Wed, 14 Jun 2023 15:47:37 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Kim Barrett has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
>> 
>>  - Merge branch 'master' into buffer-capacity
>>  - rename buffer_size to buffer_capacity
>
> lgtm

Thanks for reviews @tschatzl and @albertnetymk .

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

PR Comment: https://git.openjdk.org/jdk/pull/14439#issuecomment-1592048380

From kbarrett at openjdk.org  Wed Jun 14 22:07:01 2023
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 14 Jun 2023 22:07:01 GMT
Subject: Integrated: 8309899: Rename PtrQueueSet::buffer_size()
In-Reply-To: <mmdB2PB2JtgaIrWdKFy6gF3ooTBSrUY_kDnnF271Nx0=.acb85028-8e69-4cbb-b6db-8b54bd07a241@github.com>
References: <mmdB2PB2JtgaIrWdKFy6gF3ooTBSrUY_kDnnF271Nx0=.acb85028-8e69-4cbb-b6db-8b54bd07a241@github.com>
Message-ID: <Wqgc7y7qndBbSUSfA4Z0C8dn-LH_TW8_ua2CorQbzpQ=.c53834fc-d46f-47c1-9587-c64a0b3a2ca4@github.com>

On Tue, 13 Jun 2023 07:28:32 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this renaming of PtrQueueSet::buffer_size to buffer_capacity,
> along with some associated function and variable renamings.
> 
> Despite the number of files and lines changed, it's just a name change, so
> perhaps it's trivial?
> 
> Testing:
> mach5 tier1
> 
> Note: There weren't any changes needed in Shenandoah, even though it uses the
> SATBMarkQueue stuff.

This pull request has now been integrated.

Changeset: 181845ae
Author:    Kim Barrett <kbarrett at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/181845ae46157a9bb3bf8e2a328fa59eddc0273a
Stats:     68 lines in 12 files changed: 1 ins; 2 del; 65 mod

8309899: Rename PtrQueueSet::buffer_size()

Reviewed-by: tschatzl, ayang

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

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

From dholmes at openjdk.org  Thu Jun 15 00:56:14 2023
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 15 Jun 2023 00:56:14 GMT
Subject: RFR: 8309953: Strengthen and optimize oopDesc age methods [v2]
In-Reply-To: <EeoxbA_ASU4FJxBMvyEsIM8IVQnXmEvQC2jaeF_giMo=.fd5aef53-0969-44e7-a106-487f73a8e2c4@github.com>
References: <O6rI6qZw5bUx8VxkJ2xxraxtkV5GOZL2v9rdROj8yZY=.3fb16a13-4f80-4e2b-8f0e-a68b7726a6c9@github.com>
 <EeoxbA_ASU4FJxBMvyEsIM8IVQnXmEvQC2jaeF_giMo=.fd5aef53-0969-44e7-a106-487f73a8e2c4@github.com>
Message-ID: <DLYEG4CCYAWn8wk-0UnglXgNWNju6HJ0ryZbnIyRufo=.743af16d-365c-4001-b066-8e9268a32ba3@github.com>

On Wed, 14 Jun 2023 10:49:44 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> See the RFE for discussion. Basically, there is little reason to do two loads of mark word, when we can do one. 
>> 
>> Additional testing:
>>  - [x] Eyeballing generated code
>>  - [x] Linux x86_64 fastdebug `tier1 tier2 tier3`
>>  - [x] Linux AArch64 fastdebug `tier1 tier2 tier3`
>
> Aleksey Shipilev 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 branch 'master' into JDK-8309953-oopdesc-age
>  - Revert helper method removals
>  - Fix

The issue is not whether we can construct a benchmark that demonstrates a gain with this kind of micro-optimisation, but whether the micro-optimisation provides sufficient gain in general to trade-off against the reduction in code readability. I'm dubious about the value but will leave it to the GC folk to make the call. Thanks for the updated info.

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

PR Comment: https://git.openjdk.org/jdk/pull/14456#issuecomment-1592173561

From shade at openjdk.org  Thu Jun 15 07:54:06 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 15 Jun 2023 07:54:06 GMT
Subject: Integrated: 8309956: Shenandoah: Strengthen the mark word check in
 string dedup
In-Reply-To: <9SkcjmZCZYU5XfoCXff171H3FKz6hB8L7oUcD6SeIfk=.41a6b96d-a5b4-4202-9b0b-023970d18598@github.com>
References: <9SkcjmZCZYU5XfoCXff171H3FKz6hB8L7oUcD6SeIfk=.41a6b96d-a5b4-4202-9b0b-023970d18598@github.com>
Message-ID: <_nED8s3lKKrDczdO0UEgZoNXwkXwr4cjTwuEV8oHAgY=.d0275bef-bec7-466b-9fe9-055d71704443@github.com>

On Wed, 14 Jun 2023 17:06:30 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Clean backport to improve Shenandoah reliability.

This pull request has now been integrated.

Changeset: 0ac92753
Author:    Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.org/jdk21/commit/0ac92753dd3991123cbbf72cc812c158f68fe6e1
Stats:     8 lines in 1 file changed: 1 ins; 0 del; 7 mod

8309956: Shenandoah: Strengthen the mark word check in string dedup

Reviewed-by: rkennke
Backport-of: 57b8251241e2044d5039ce162bf4637a9b2e5466

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

PR: https://git.openjdk.org/jdk21/pull/19

From tschatzl at openjdk.org  Thu Jun 15 08:44:02 2023
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Thu, 15 Jun 2023 08:44:02 GMT
Subject: RFR: 8310037: Leak MutableSpaceUsedHelper in parallel GC's
 SpaceCounters class
In-Reply-To: <HZhfPsRC9Imnoeyr5oQFxRTy9YkvMHqizuGTws83IeY=.710793c8-c2b5-4a72-b8b8-7d2e56c8123f@github.com>
References: <HZhfPsRC9Imnoeyr5oQFxRTy9YkvMHqizuGTws83IeY=.710793c8-c2b5-4a72-b8b8-7d2e56c8123f@github.com>
Message-ID: <jMVtoJ9azQcmg0YddJUgOGi_R6iNtKF346egPF0Xbo0=.3720b3d6-ac01-4ce8-8c18-72324b130e97@github.com>

On Wed, 14 Jun 2023 16:14:15 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> Please review this small fix for memory leak.

The change is good, and I'm approving it. The same issue exists for serial gc (in `CSpaceCounters`), so maybe this could be dealt with here too, but feel free to defer to a separate CR.

Fwiw, this seems to be one of those memory leaks of (single) instances that would be cleaned out automatically at VM exit anyway, am I correct?

src/hotspot/share/gc/parallel/spaceCounters.cpp line 65:

> 63:     _perf_used_helper = new MutableSpaceUsedHelper(_object_space);
> 64:     _used = PerfDataManager::create_variable(SUN_GC, cname, PerfData::U_Bytes,
> 65:                                     _perf_used_helper,

The same issue affects serial gc in the `CSpaceCounters` file; since these are very minor changes, could you do this in the same change (renaming the CR too)?
Otherwise please file a bug for serial gc too.

src/hotspot/share/gc/parallel/spaceCounters.cpp line 65:

> 63:     _perf_used_helper = new MutableSpaceUsedHelper(_object_space);
> 64:     _used = PerfDataManager::create_variable(SUN_GC, cname, PerfData::U_Bytes,
> 65:                                     _perf_used_helper,

Pre-existing: the formatting of `PerfDataManager::create*` calls is rather unusual. I filed [JDK-8310116](https://bugs.openjdk.org/browse/JDK-8310116) for that.

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

Marked as reviewed by tschatzl (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14472#pullrequestreview-1481012551
PR Review Comment: https://git.openjdk.org/jdk/pull/14472#discussion_r1230649832
PR Review Comment: https://git.openjdk.org/jdk/pull/14472#discussion_r1230651103

From tschatzl at openjdk.org  Thu Jun 15 09:30:10 2023
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Thu, 15 Jun 2023 09:30:10 GMT
Subject: RFR: 8248149: G1: change _cleaning_claimed from int to bool
Message-ID: <Dty-AHn0hLZmHpX9Kl0YtYFjKveyKMJArFc-fX048iQ=.1787da0c-6026-4e61-b036-92480e17fac4@github.com>

Hi all,

  please review this change to fix some claim variable from `int` to `bool` as it should be.

Testing: gha

Thanks,
  Thomas

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

Commit messages:
 - Initial version

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

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

From tschatzl at openjdk.org  Thu Jun 15 09:37:00 2023
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Thu, 15 Jun 2023 09:37:00 GMT
Subject: RFR: 8309953: Strengthen and optimize oopDesc age methods [v2]
In-Reply-To: <EeoxbA_ASU4FJxBMvyEsIM8IVQnXmEvQC2jaeF_giMo=.fd5aef53-0969-44e7-a106-487f73a8e2c4@github.com>
References: <O6rI6qZw5bUx8VxkJ2xxraxtkV5GOZL2v9rdROj8yZY=.3fb16a13-4f80-4e2b-8f0e-a68b7726a6c9@github.com>
 <EeoxbA_ASU4FJxBMvyEsIM8IVQnXmEvQC2jaeF_giMo=.fd5aef53-0969-44e7-a106-487f73a8e2c4@github.com>
Message-ID: <Lauo4a8NBoG8loL2aQw7em30UVyd0Yios7ZqhnfUqVE=.9287c84a-e9dc-4015-beaf-914b1a9e44eb@github.com>

On Wed, 14 Jun 2023 10:49:44 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> See the RFE for discussion. Basically, there is little reason to do two loads of mark word, when we can do one. 
>> 
>> Additional testing:
>>  - [x] Eyeballing generated code
>>  - [x] Linux x86_64 fastdebug `tier1 tier2 tier3`
>>  - [x] Linux AArch64 fastdebug `tier1 tier2 tier3`
>
> Aleksey Shipilev 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 branch 'master' into JDK-8309953-oopdesc-age
>  - Revert helper method removals
>  - Fix

Marked as reviewed by tschatzl (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/14456#pullrequestreview-1481138793

From lkorinth at openjdk.org  Thu Jun 15 10:10:13 2023
From: lkorinth at openjdk.org (Leo Korinth)
Date: Thu, 15 Jun 2023 10:10:13 GMT
Subject: RFR: 8248149: G1: change _cleaning_claimed from int to bool
In-Reply-To: <Dty-AHn0hLZmHpX9Kl0YtYFjKveyKMJArFc-fX048iQ=.1787da0c-6026-4e61-b036-92480e17fac4@github.com>
References: <Dty-AHn0hLZmHpX9Kl0YtYFjKveyKMJArFc-fX048iQ=.1787da0c-6026-4e61-b036-92480e17fac4@github.com>
Message-ID: <pvf_JOLw7vf8Jf35wjrI8KL8J6Cn1CjHhoBC3ii52ig=.1633b3fc-9336-4995-957b-05da4f3bd7c9@github.com>

On Thu, 15 Jun 2023 09:22:39 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   please review this change to fix some claim variable from `int` to `bool` as it should be.
> 
> Testing: gha
> 
> Thanks,
>   Thomas

Looks good to me, thanks for cleaning it up.

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

Marked as reviewed by lkorinth (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14487#pullrequestreview-1481201149

From ayang at openjdk.org  Thu Jun 15 10:44:00 2023
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Thu, 15 Jun 2023 10:44:00 GMT
Subject: RFR: 8248149: G1: change _cleaning_claimed from int to bool
In-Reply-To: <Dty-AHn0hLZmHpX9Kl0YtYFjKveyKMJArFc-fX048iQ=.1787da0c-6026-4e61-b036-92480e17fac4@github.com>
References: <Dty-AHn0hLZmHpX9Kl0YtYFjKveyKMJArFc-fX048iQ=.1787da0c-6026-4e61-b036-92480e17fac4@github.com>
Message-ID: <ZjN_tCzYGG_anDVJc-cTOhdqt8tGG-WzrRT7f-NmRvk=.a35732cb-43c9-4f7c-8157-da9128a995c5@github.com>

On Thu, 15 Jun 2023 09:22:39 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   please review this change to fix some claim variable from `int` to `bool` as it should be.
> 
> Testing: gha
> 
> Thanks,
>   Thomas

Marked as reviewed by ayang (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/14487#pullrequestreview-1481258910

From ayang at openjdk.org  Thu Jun 15 10:45:59 2023
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Thu, 15 Jun 2023 10:45:59 GMT
Subject: RFR: 8308643: Incorrect value of 'used' jvmstat counter
In-Reply-To: <fAi8nyXQf0uv3JMtBXgIoDdSXLOur4hIoSb4O_U2lhQ=.023b252a-d50e-4b6b-b7c0-1b7975c3206c@github.com>
References: <fAi8nyXQf0uv3JMtBXgIoDdSXLOur4hIoSb4O_U2lhQ=.023b252a-d50e-4b6b-b7c0-1b7975c3206c@github.com>
Message-ID: <6Z3qA26K3nNFK9FkklIzXdiG3E6qMlgSLfPBomKpM74=.a3a7173a-5bc9-4f38-a508-96f66be99de9@github.com>

On Sun, 28 May 2023 02:08:59 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this change that fixes the space-used performance counters
> provided by ParallelGC and SerialGC.
> 
> The prior fix for a problem in this area (JDK-8268265) wasn't correct.  It
> used a static "last value" variable, for use when sampling is blocked by an
> in-progress GC.  But there are multiple counters, so having one static "last
> value" variable doesn't work.  (Not sure what I and my reviewers were thinking
> at the time. Maybe we overlooked that there are multiple counters.)  The
> solution is to associate a "last value" with each of the counters.
> 
> Also added a test of basic functionality (just accessibility) of the space
> counters.  No regression test of the problem being fixed here, as its hard to
> reliably set up.
> 
> Note: SpaceCounters and CSpaceCounters are very nearly identical.  It's likely
> possible to refactor for more code sharing, which could be done as a followup.
> 
> Testing:
> mach5 tier1

Marked as reviewed by ayang (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/14195#pullrequestreview-1481262144

From ayang at openjdk.org  Thu Jun 15 10:46:00 2023
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Thu, 15 Jun 2023 10:46:00 GMT
Subject: RFR: 8308643: Incorrect value of 'used' jvmstat counter
In-Reply-To: <b1WnpJ8Lb7vVBMAUs9mUin_WrJNNBhDUTX8_Y-Ar0pI=.1cb4b1ad-0433-4542-a896-900580e953a9@github.com>
References: <fAi8nyXQf0uv3JMtBXgIoDdSXLOur4hIoSb4O_U2lhQ=.023b252a-d50e-4b6b-b7c0-1b7975c3206c@github.com>
 <Ib0ZJO7EkoUFfzAbieEhf7pw2I99bQTvl738ZnOymjo=.4e563938-6741-4dac-83e5-69fef34d22db@github.com>
 <KNoFTQteHu4EgXgffKEwPKZC7iMExeyxdHQSSwDSRik=.3640e65e-2a8c-4384-8967-3921155a3dbd@github.com>
 <_ajTwaXeUNCGXRFCoc0A5dawGsbAQwIPd425fhjErts=.14eff994-14f8-417a-adc7-a5819f9a5181@github.com>
 <DmC46UBwpwaEXo00FrnjXnwbJAVA7CI_bsu8NiqcxwU=.5543c4ad-bdf3-41f1-ad10-641abf179b03@github.com>
 <b1WnpJ8Lb7vVBMAUs9mUin_WrJNNBhDUTX8_Y-Ar0pI=.1cb4b1ad-0433-4542-a896-900580e953a9@github.com>
Message-ID: <nhTEtQXxfkqaXy5R7BPlyXmg-vUN1K2KCJ0_0j8T3eE=.18fc0768-157b-45b8-a102-7ae058ff27a1@github.com>

On Wed, 14 Jun 2023 21:56:50 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Using the perf-counter to carry the periodic samples doesn't work. During
>> construction of the perf-counter, the sampler is called to provide the initial
>> value for the counter. Since the counter is not yet fully constructed and
>> accessible to the sampling function (_used is not yet initialized), this crashes.
>> 
>> A workaround for that problem would be to add constructors that take both a
>> sampler and an initial value. That's kind of messy, and doesn't seem better
>> than the proposed solution at hand.
>
> BTW, I was wrong about the _used counter only being updated by GC.  It is
> updated by the sampler to the newly sampled value.  I hadn't fully chased
> through the call chains before.

Thank you for the clarification.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14195#discussion_r1230812091

From kbarrett at openjdk.org  Thu Jun 15 10:52:59 2023
From: kbarrett at openjdk.org (Kim Barrett)
Date: Thu, 15 Jun 2023 10:52:59 GMT
Subject: RFR: 8248149: G1: change _cleaning_claimed from int to bool
In-Reply-To: <Dty-AHn0hLZmHpX9Kl0YtYFjKveyKMJArFc-fX048iQ=.1787da0c-6026-4e61-b036-92480e17fac4@github.com>
References: <Dty-AHn0hLZmHpX9Kl0YtYFjKveyKMJArFc-fX048iQ=.1787da0c-6026-4e61-b036-92480e17fac4@github.com>
Message-ID: <EstxXeQXpNxGrlI0wIT3Xb5D38MVYBci3wFV7REvitQ=.7bd9a9b3-af25-4d60-bbeb-37435e1f17ae@github.com>

On Thu, 15 Jun 2023 09:22:39 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   please review this change to fix some claim variable from `int` to `bool` as it should be.
> 
> Testing: gha
> 
> Thanks,
>   Thomas

src/hotspot/share/gc/g1/g1ParallelCleaning.cpp line 43:

> 41:   }
> 42: 
> 43:   return !Atomic::cmpxchg(&_cleaning_claimed, false, true);

It might be an int because making it a bool may involve a byte-sized cmpxchg, which has a not very
nice implementation on some platforms.  Though even with that the claim cost is likely dwarfed by
other costs here.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14487#discussion_r1230819175

From tschatzl at openjdk.org  Thu Jun 15 11:03:58 2023
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Thu, 15 Jun 2023 11:03:58 GMT
Subject: RFR: 8248149: G1: change _cleaning_claimed from int to bool
In-Reply-To: <EstxXeQXpNxGrlI0wIT3Xb5D38MVYBci3wFV7REvitQ=.7bd9a9b3-af25-4d60-bbeb-37435e1f17ae@github.com>
References: <Dty-AHn0hLZmHpX9Kl0YtYFjKveyKMJArFc-fX048iQ=.1787da0c-6026-4e61-b036-92480e17fac4@github.com>
 <EstxXeQXpNxGrlI0wIT3Xb5D38MVYBci3wFV7REvitQ=.7bd9a9b3-af25-4d60-bbeb-37435e1f17ae@github.com>
Message-ID: <QHquIh4UksQ79s2IV1D7WZOdGyvUxsNPqRzsbF8s8Og=.e428e275-4c33-41b6-a5ba-8268e30578d1@github.com>

On Thu, 15 Jun 2023 10:49:53 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Hi all,
>> 
>>   please review this change to fix some claim variable from `int` to `bool` as it should be.
>> 
>> Testing: gha
>> 
>> Thanks,
>>   Thomas
>
> src/hotspot/share/gc/g1/g1ParallelCleaning.cpp line 43:
> 
>> 41:   }
>> 42: 
>> 43:   return !Atomic::cmpxchg(&_cleaning_claimed, false, true);
> 
> It might be an int because making it a bool may involve a byte-sized cmpxchg, which has a not very
> nice implementation on some platforms.  Though even with that the claim cost is likely dwarfed by
> other costs here.

I prefer to believe that when this has been implemented, there has been no cmpxchg overload for bools before the atomics refactoring. We did not go back and look for these kind of mismatches.

There should be no visible performance difference, so I prefer using the more appropriate type.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14487#discussion_r1230838203

From ayang at openjdk.org  Thu Jun 15 12:05:07 2023
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Thu, 15 Jun 2023 12:05:07 GMT
Subject: RFR: 8309960: ParallelGC young collections very slow in
 DelayInducer [v2]
In-Reply-To: <dO3YDOs4X3Mour2namEZh3_84OHxwlOZ18Nr_W2lYN4=.59a11853-b2ff-407b-9e6d-a464cc624ba0@github.com>
References: <VoGzDvHPG1PtlXJFJ8SLroRYwEPwsA-Zocu4VtTYoe4=.0570f3cd-01ee-41de-90d4-56b02805982a@github.com>
 <dO3YDOs4X3Mour2namEZh3_84OHxwlOZ18Nr_W2lYN4=.59a11853-b2ff-407b-9e6d-a464cc624ba0@github.com>
Message-ID: <Bcqvd5tJc1Xtohypmzk3WhLWNFHTHAc36xxGCaW81cs=.1a78fa5e-aaf8-430b-b59f-a264ba759df4@github.com>

On Wed, 14 Jun 2023 14:59:27 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Using the benchmark from the JBS ticket, one can observe the young-gc-pause regression is gone.
>
> Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/hotspot/share/gc/parallel/psPromotionManager.cpp
>   
>   Co-authored-by: Thomas Schatzl <59967451+tschatzl at users.noreply.github.com>

Thanks for the review.

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

PR Comment: https://git.openjdk.org/jdk/pull/14469#issuecomment-1592907412

From ayang at openjdk.org  Thu Jun 15 12:05:08 2023
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Thu, 15 Jun 2023 12:05:08 GMT
Subject: Integrated: 8309960: ParallelGC young collections very slow in
 DelayInducer
In-Reply-To: <VoGzDvHPG1PtlXJFJ8SLroRYwEPwsA-Zocu4VtTYoe4=.0570f3cd-01ee-41de-90d4-56b02805982a@github.com>
References: <VoGzDvHPG1PtlXJFJ8SLroRYwEPwsA-Zocu4VtTYoe4=.0570f3cd-01ee-41de-90d4-56b02805982a@github.com>
Message-ID: <Qsh_GI08WwbYDAj-7DCjv8PX7lKsN42bWiStT3slg0M=.f54ebbce-9069-4b51-a910-0e311a3b4b37@github.com>

On Wed, 14 Jun 2023 14:09:07 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Using the benchmark from the JBS ticket, one can observe the young-gc-pause regression is gone.

This pull request has now been integrated.

Changeset: 5f3613e0
Author:    Albert Mingkun Yang <ayang at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/5f3613e0604f7da252421e08fe7ded7406538caa
Stats:     8 lines in 1 file changed: 5 ins; 0 del; 3 mod

8309960: ParallelGC young collections very slow in DelayInducer

Reviewed-by: tschatzl, iwalulya

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

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

From ayang at openjdk.org  Thu Jun 15 12:21:11 2023
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Thu, 15 Jun 2023 12:21:11 GMT
Subject: RFR: 8309960: ParallelGC young collections very slow in DelayInducer
Message-ID: <mntEDz2bEJF-ZQ5KxaRQ_vkMV4_P7JwrrgBhWsVDtEI=.ddf1c6ab-f90f-48c8-beef-1c78e7c51b9c@github.com>

8309960: ParallelGC young collections very slow in DelayInducer

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

Commit messages:
 - Backport 5f3613e0604f7da252421e08fe7ded7406538caa

Changes: https://git.openjdk.org/jdk21/pull/22/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk21&pr=22&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8309960
  Stats: 8 lines in 1 file changed: 5 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk21/pull/22.diff
  Fetch: git fetch https://git.openjdk.org/jdk21.git pull/22/head:pull/22

PR: https://git.openjdk.org/jdk21/pull/22

From tschatzl at openjdk.org  Thu Jun 15 14:21:04 2023
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Thu, 15 Jun 2023 14:21:04 GMT
Subject: RFR: 8309960: ParallelGC young collections very slow in
 DelayInducer
In-Reply-To: <mntEDz2bEJF-ZQ5KxaRQ_vkMV4_P7JwrrgBhWsVDtEI=.ddf1c6ab-f90f-48c8-beef-1c78e7c51b9c@github.com>
References: <mntEDz2bEJF-ZQ5KxaRQ_vkMV4_P7JwrrgBhWsVDtEI=.ddf1c6ab-f90f-48c8-beef-1c78e7c51b9c@github.com>
Message-ID: <30aCWPukOjzSSvBEnHHhNW7lpgIok3D9TjORs48mWhg=.ef755098-3e88-4fe9-8416-55aaf58e0c37@github.com>

On Thu, 15 Jun 2023 12:12:23 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> 8309960: ParallelGC young collections very slow in DelayInducer

Marked as reviewed by tschatzl (Reviewer).

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

PR Review: https://git.openjdk.org/jdk21/pull/22#pullrequestreview-1481697427

From zgu at openjdk.org  Thu Jun 15 14:26:25 2023
From: zgu at openjdk.org (Zhengyu Gu)
Date: Thu, 15 Jun 2023 14:26:25 GMT
Subject: RFR: 8310037: Parallel/Serial: Space Counters classes leak helper
 instances [v2]
In-Reply-To: <HZhfPsRC9Imnoeyr5oQFxRTy9YkvMHqizuGTws83IeY=.710793c8-c2b5-4a72-b8b8-7d2e56c8123f@github.com>
References: <HZhfPsRC9Imnoeyr5oQFxRTy9YkvMHqizuGTws83IeY=.710793c8-c2b5-4a72-b8b8-7d2e56c8123f@github.com>
Message-ID: <v5EM3GD2Dbf460iEoOuM2UpMaYPMKGyylAR5VTbmQUc=.8e49c33b-50d3-45ca-8073-c0fe1a4f1adb@github.com>

> Please review this small fix for memory leak.

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

  tschatzl's suggestion

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14472/files
  - new: https://git.openjdk.org/jdk/pull/14472/files/7b4c83d4..988fe8da

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

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

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

From tschatzl at openjdk.org  Thu Jun 15 14:30:58 2023
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Thu, 15 Jun 2023 14:30:58 GMT
Subject: RFR: 8310037: Parallel/Serial: Space Counters classes leak helper
 instances [v2]
In-Reply-To: <v5EM3GD2Dbf460iEoOuM2UpMaYPMKGyylAR5VTbmQUc=.8e49c33b-50d3-45ca-8073-c0fe1a4f1adb@github.com>
References: <HZhfPsRC9Imnoeyr5oQFxRTy9YkvMHqizuGTws83IeY=.710793c8-c2b5-4a72-b8b8-7d2e56c8123f@github.com>
 <v5EM3GD2Dbf460iEoOuM2UpMaYPMKGyylAR5VTbmQUc=.8e49c33b-50d3-45ca-8073-c0fe1a4f1adb@github.com>
Message-ID: <dQlgqU_Hqd5Q2a93vAmGnN1CVJWcs97mWF8EllOLBXY=.c88ed83d-33b6-4b2f-969f-4d9601862f35@github.com>

On Thu, 15 Jun 2023 14:26:25 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

>> Please review this small fix for memory leak.
>
> Zhengyu Gu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   tschatzl's suggestion

Still good. Thanks.

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

Marked as reviewed by tschatzl (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14472#pullrequestreview-1481723406

From duke at openjdk.org  Thu Jun 15 15:12:59 2023
From: duke at openjdk.org (Ashutosh Mehra)
Date: Thu, 15 Jun 2023 15:12:59 GMT
Subject: RFR: 8309979: BootstrapMethods attribute is missing in class files
 recreated by SA
Message-ID: <nSooA6CtKm8LsaxzYdqJ6mtVV0os-kT5F2xNvYI4lJo=.c27bd28e-88d3-4bcb-ac3d-9036140eeff0@github.com>

Please review this PR that extends SA to write BootstrapMethods attribute when dumping the class files.

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

Commit messages:
 - 8309979: BootstrapMethods attribute is missing in class files recreated by SA

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

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

From stefank at openjdk.org  Thu Jun 15 15:55:59 2023
From: stefank at openjdk.org (Stefan Karlsson)
Date: Thu, 15 Jun 2023 15:55:59 GMT
Subject: RFR: 8310037: Parallel/Serial: Space Counters classes leak helper
 instances [v2]
In-Reply-To: <jMVtoJ9azQcmg0YddJUgOGi_R6iNtKF346egPF0Xbo0=.3720b3d6-ac01-4ce8-8c18-72324b130e97@github.com>
References: <HZhfPsRC9Imnoeyr5oQFxRTy9YkvMHqizuGTws83IeY=.710793c8-c2b5-4a72-b8b8-7d2e56c8123f@github.com>
 <jMVtoJ9azQcmg0YddJUgOGi_R6iNtKF346egPF0Xbo0=.3720b3d6-ac01-4ce8-8c18-72324b130e97@github.com>
Message-ID: <ZASGSpQhf3czZIjgWFvKHknj0v9AY6hG49tCFkJkNP8=.1c590343-81fd-49e2-b09d-b0b27599a11d@github.com>

On Thu, 15 Jun 2023 08:41:10 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Fwiw, this seems to be one of those memory leaks of (single) instances that would be cleaned out automatically at VM exit anyway, am I correct?

And IIUC this code will never be called. How did you test the added code?

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

PR Comment: https://git.openjdk.org/jdk/pull/14472#issuecomment-1593330686

From stefank at openjdk.org  Thu Jun 15 16:01:11 2023
From: stefank at openjdk.org (Stefan Karlsson)
Date: Thu, 15 Jun 2023 16:01:11 GMT
Subject: RFR: 8309953: Strengthen and optimize oopDesc age methods [v2]
In-Reply-To: <EeoxbA_ASU4FJxBMvyEsIM8IVQnXmEvQC2jaeF_giMo=.fd5aef53-0969-44e7-a106-487f73a8e2c4@github.com>
References: <O6rI6qZw5bUx8VxkJ2xxraxtkV5GOZL2v9rdROj8yZY=.3fb16a13-4f80-4e2b-8f0e-a68b7726a6c9@github.com>
 <EeoxbA_ASU4FJxBMvyEsIM8IVQnXmEvQC2jaeF_giMo=.fd5aef53-0969-44e7-a106-487f73a8e2c4@github.com>
Message-ID: <FWQpy5J8VfWVABvD-YY6i8rgNnmgVPvyN-daryWLQu4=.e0d70399-43ef-46fb-a05b-c736a9e95dc2@github.com>

On Wed, 14 Jun 2023 10:49:44 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> See the RFE for discussion. Basically, there is little reason to do two loads of mark word, when we can do one. 
>> 
>> Additional testing:
>>  - [x] Eyeballing generated code
>>  - [x] Linux x86_64 fastdebug `tier1 tier2 tier3`
>>  - [x] Linux AArch64 fastdebug `tier1 tier2 tier3`
>
> Aleksey Shipilev 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 branch 'master' into JDK-8309953-oopdesc-age
>  - Revert helper method removals
>  - Fix

Marked as reviewed by stefank (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/14456#pullrequestreview-1481934726

From shade at openjdk.org  Thu Jun 15 18:26:11 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 15 Jun 2023 18:26:11 GMT
Subject: RFR: 8309953: Strengthen and optimize oopDesc age methods [v2]
In-Reply-To: <EeoxbA_ASU4FJxBMvyEsIM8IVQnXmEvQC2jaeF_giMo=.fd5aef53-0969-44e7-a106-487f73a8e2c4@github.com>
References: <O6rI6qZw5bUx8VxkJ2xxraxtkV5GOZL2v9rdROj8yZY=.3fb16a13-4f80-4e2b-8f0e-a68b7726a6c9@github.com>
 <EeoxbA_ASU4FJxBMvyEsIM8IVQnXmEvQC2jaeF_giMo=.fd5aef53-0969-44e7-a106-487f73a8e2c4@github.com>
Message-ID: <o5ryk_-h1p4dF_CSuvkXoOaYAi-wsWGHndsDZ37nIVs=.e6f156bf-fa1e-4844-b912-dbc91631b295@github.com>

On Wed, 14 Jun 2023 10:49:44 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> See the RFE for discussion. Basically, there is little reason to do two loads of mark word, when we can do one. 
>> 
>> Additional testing:
>>  - [x] Eyeballing generated code
>>  - [x] Linux x86_64 fastdebug `tier1 tier2 tier3`
>>  - [x] Linux AArch64 fastdebug `tier1 tier2 tier3`
>
> Aleksey Shipilev 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 branch 'master' into JDK-8309953-oopdesc-age
>  - Revert helper method removals
>  - Fix

Seems like we are good, as I see approvals from 3 GC engineers :)

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

PR Comment: https://git.openjdk.org/jdk/pull/14456#issuecomment-1593535481

From kbarrett at openjdk.org  Thu Jun 15 18:32:27 2023
From: kbarrett at openjdk.org (Kim Barrett)
Date: Thu, 15 Jun 2023 18:32:27 GMT
Subject: RFR: 8248149: G1: change _cleaning_claimed from int to bool
In-Reply-To: <Dty-AHn0hLZmHpX9Kl0YtYFjKveyKMJArFc-fX048iQ=.1787da0c-6026-4e61-b036-92480e17fac4@github.com>
References: <Dty-AHn0hLZmHpX9Kl0YtYFjKveyKMJArFc-fX048iQ=.1787da0c-6026-4e61-b036-92480e17fac4@github.com>
Message-ID: <2i9RHtAhL6AKS7c6X6859luSuD5hYH4B96kB3SV4_CM=.96dd0f01-fcc6-4039-8907-a9136371adb8@github.com>

On Thu, 15 Jun 2023 09:22:39 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   please review this change to fix some claim variable from `int` to `bool` as it should be.
> 
> Testing: gha
> 
> Thanks,
>   Thomas

Marked as reviewed by kbarrett (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/14487#pullrequestreview-1482175022

From kbarrett at openjdk.org  Thu Jun 15 18:32:31 2023
From: kbarrett at openjdk.org (Kim Barrett)
Date: Thu, 15 Jun 2023 18:32:31 GMT
Subject: RFR: 8248149: G1: change _cleaning_claimed from int to bool
In-Reply-To: <QHquIh4UksQ79s2IV1D7WZOdGyvUxsNPqRzsbF8s8Og=.e428e275-4c33-41b6-a5ba-8268e30578d1@github.com>
References: <Dty-AHn0hLZmHpX9Kl0YtYFjKveyKMJArFc-fX048iQ=.1787da0c-6026-4e61-b036-92480e17fac4@github.com>
 <EstxXeQXpNxGrlI0wIT3Xb5D38MVYBci3wFV7REvitQ=.7bd9a9b3-af25-4d60-bbeb-37435e1f17ae@github.com>
 <QHquIh4UksQ79s2IV1D7WZOdGyvUxsNPqRzsbF8s8Og=.e428e275-4c33-41b6-a5ba-8268e30578d1@github.com>
Message-ID: <sEPcZaKtHAxKhvO36EPCxSuYQC-YM6OYdEQ3zzKhkJU=.5996033f-23ad-4db8-b856-700100f4f235@github.com>

On Thu, 15 Jun 2023 11:01:18 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> src/hotspot/share/gc/g1/g1ParallelCleaning.cpp line 43:
>> 
>>> 41:   }
>>> 42: 
>>> 43:   return !Atomic::cmpxchg(&_cleaning_claimed, false, true);
>> 
>> It might be an int because making it a bool may involve a byte-sized cmpxchg, which has a not very
>> nice implementation on some platforms.  Though even with that the claim cost is likely dwarfed by
>> other costs here.
>
> I prefer to believe that when this has been implemented, there has been no cmpxchg overload for bools before the atomics refactoring. We did not go back and look for these kind of mismatches.
> 
> There should be no visible performance difference, so I prefer using the more appropriate type.

Yeah, that's probably correct.  We used to have a cmpxchg overload for jbyte, but never explicitly bool.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14487#discussion_r1231399226

From shade at openjdk.org  Thu Jun 15 19:17:47 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 15 Jun 2023 19:17:47 GMT
Subject: Integrated: 8309953: Strengthen and optimize oopDesc age methods
In-Reply-To: <O6rI6qZw5bUx8VxkJ2xxraxtkV5GOZL2v9rdROj8yZY=.3fb16a13-4f80-4e2b-8f0e-a68b7726a6c9@github.com>
References: <O6rI6qZw5bUx8VxkJ2xxraxtkV5GOZL2v9rdROj8yZY=.3fb16a13-4f80-4e2b-8f0e-a68b7726a6c9@github.com>
Message-ID: <hERwT9Ncw387qnkgL5o0qBnqaFQKb4j34mF-7xUWCQo=.0a98ba8a-2c08-4b79-bbca-493f4a078381@github.com>

On Tue, 13 Jun 2023 20:04:48 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> See the RFE for discussion. Basically, there is little reason to do two loads of mark word, when we can do one. 
> 
> Additional testing:
>  - [x] Eyeballing generated code
>  - [x] Linux x86_64 fastdebug `tier1 tier2 tier3`
>  - [x] Linux AArch64 fastdebug `tier1 tier2 tier3`

This pull request has now been integrated.

Changeset: 4a5475ce
Author:    Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4a5475ce0492fc02019b0f89b50601c388c63e21
Stats:     10 lines in 1 file changed: 2 ins; 0 del; 8 mod

8309953: Strengthen and optimize oopDesc age methods

Reviewed-by: mdoerr, rkennke, tschatzl, stefank

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

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

From minqi at openjdk.org  Thu Jun 15 19:20:05 2023
From: minqi at openjdk.org (Yumin Qi)
Date: Thu, 15 Jun 2023 19:20:05 GMT
Subject: RFR: 8310037: Parallel/Serial: Space Counters classes leak helper
 instances [v2]
In-Reply-To: <v5EM3GD2Dbf460iEoOuM2UpMaYPMKGyylAR5VTbmQUc=.8e49c33b-50d3-45ca-8073-c0fe1a4f1adb@github.com>
References: <HZhfPsRC9Imnoeyr5oQFxRTy9YkvMHqizuGTws83IeY=.710793c8-c2b5-4a72-b8b8-7d2e56c8123f@github.com>
 <v5EM3GD2Dbf460iEoOuM2UpMaYPMKGyylAR5VTbmQUc=.8e49c33b-50d3-45ca-8073-c0fe1a4f1adb@github.com>
Message-ID: <3RpBJOCfe8xIEVcquD_BGEXAKwvCp7MtfxGtGOW_BBM=.b884123c-eb2c-4e83-a35a-25293bcb12db@github.com>

On Thu, 15 Jun 2023 14:26:25 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

>> Please review this small fix for memory leak.
>
> Zhengyu Gu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   tschatzl's suggestion

LGTM

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

Marked as reviewed by minqi (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14472#pullrequestreview-1482239488

From zgu at openjdk.org  Thu Jun 15 19:28:59 2023
From: zgu at openjdk.org (Zhengyu Gu)
Date: Thu, 15 Jun 2023 19:28:59 GMT
Subject: RFR: 8310037: Parallel/Serial: Space Counters classes leak helper
 instances [v2]
In-Reply-To: <ZASGSpQhf3czZIjgWFvKHknj0v9AY6hG49tCFkJkNP8=.1c590343-81fd-49e2-b09d-b0b27599a11d@github.com>
References: <HZhfPsRC9Imnoeyr5oQFxRTy9YkvMHqizuGTws83IeY=.710793c8-c2b5-4a72-b8b8-7d2e56c8123f@github.com>
 <jMVtoJ9azQcmg0YddJUgOGi_R6iNtKF346egPF0Xbo0=.3720b3d6-ac01-4ce8-8c18-72324b130e97@github.com>
 <ZASGSpQhf3czZIjgWFvKHknj0v9AY6hG49tCFkJkNP8=.1c590343-81fd-49e2-b09d-b0b27599a11d@github.com>
Message-ID: <KzohZsuXrILekQVl1B9xeBOF4-3hNHRFR2VvDEXCd4U=.54d65559-6f59-4199-a90d-c0aec2144c58@github.com>

On Thu, 15 Jun 2023 15:53:20 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> > Fwiw, this seems to be one of those memory leaks of (single) instances that would be cleaned out automatically at VM exit anyway, am I correct?
> 
> And IIUC this code will never be called. How did you test the added code?

It does seem that the destructors are never called. I have no idea why it shows up in memory leak profiling, while `_space_name` does not.

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

PR Comment: https://git.openjdk.org/jdk/pull/14472#issuecomment-1593606694

From kbarrett at openjdk.org  Thu Jun 15 19:36:53 2023
From: kbarrett at openjdk.org (Kim Barrett)
Date: Thu, 15 Jun 2023 19:36:53 GMT
Subject: RFR: 8308643: Incorrect value of 'used' jvmstat counter [v2]
In-Reply-To: <fAi8nyXQf0uv3JMtBXgIoDdSXLOur4hIoSb4O_U2lhQ=.023b252a-d50e-4b6b-b7c0-1b7975c3206c@github.com>
References: <fAi8nyXQf0uv3JMtBXgIoDdSXLOur4hIoSb4O_U2lhQ=.023b252a-d50e-4b6b-b7c0-1b7975c3206c@github.com>
Message-ID: <3sfjeNdv2YKesQqd4Uo6aYWlpwbWCAm09dFn47MEXUI=.59ece5ee-3665-4fcd-9ee5-6356a8376d44@github.com>

> Please review this change that fixes the space-used performance counters
> provided by ParallelGC and SerialGC.
> 
> The prior fix for a problem in this area (JDK-8268265) wasn't correct.  It
> used a static "last value" variable, for use when sampling is blocked by an
> in-progress GC.  But there are multiple counters, so having one static "last
> value" variable doesn't work.  (Not sure what I and my reviewers were thinking
> at the time. Maybe we overlooked that there are multiple counters.)  The
> solution is to associate a "last value" with each of the counters.
> 
> Also added a test of basic functionality (just accessibility) of the space
> counters.  No regression test of the problem being fixed here, as its hard to
> reliably set up.
> 
> Note: SpaceCounters and CSpaceCounters are very nearly identical.  It's likely
> possible to refactor for more code sharing, which could be done as a followup.
> 
> Testing:
> mach5 tier1

Kim Barrett 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 four additional commits since the last revision:

 - Merge branch 'master' into space-counters
 - test basic functionality
 - fix CSpaceCounters
 - fix SpaceCounters

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14195/files
  - new: https://git.openjdk.org/jdk/pull/14195/files/f8933db3..771d8599

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

  Stats: 104392 lines in 1769 files changed: 77753 ins; 18652 del; 7987 mod
  Patch: https://git.openjdk.org/jdk/pull/14195.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14195/head:pull/14195

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

From kbarrett at openjdk.org  Thu Jun 15 19:36:54 2023
From: kbarrett at openjdk.org (Kim Barrett)
Date: Thu, 15 Jun 2023 19:36:54 GMT
Subject: RFR: 8308643: Incorrect value of 'used' jvmstat counter
In-Reply-To: <fAi8nyXQf0uv3JMtBXgIoDdSXLOur4hIoSb4O_U2lhQ=.023b252a-d50e-4b6b-b7c0-1b7975c3206c@github.com>
References: <fAi8nyXQf0uv3JMtBXgIoDdSXLOur4hIoSb4O_U2lhQ=.023b252a-d50e-4b6b-b7c0-1b7975c3206c@github.com>
Message-ID: <0ZxCUuyItQNxrwu6v6ieO4VYT6_ox1j84loncMXbskI=.1b262941-416f-4137-977c-3ae028f76f31@github.com>

On Sun, 28 May 2023 02:08:59 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this change that fixes the space-used performance counters
> provided by ParallelGC and SerialGC.
> 
> The prior fix for a problem in this area (JDK-8268265) wasn't correct.  It
> used a static "last value" variable, for use when sampling is blocked by an
> in-progress GC.  But there are multiple counters, so having one static "last
> value" variable doesn't work.  (Not sure what I and my reviewers were thinking
> at the time. Maybe we overlooked that there are multiple counters.)  The
> solution is to associate a "last value" with each of the counters.
> 
> Also added a test of basic functionality (just accessibility) of the space
> counters.  No regression test of the problem being fixed here, as its hard to
> reliably set up.
> 
> Note: SpaceCounters and CSpaceCounters are very nearly identical.  It's likely
> possible to refactor for more code sharing, which could be done as a followup.
> 
> Testing:
> mach5 tier1

Thanks for reviews.

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

PR Comment: https://git.openjdk.org/jdk/pull/14195#issuecomment-1593611373

From kbarrett at openjdk.org  Thu Jun 15 22:26:10 2023
From: kbarrett at openjdk.org (Kim Barrett)
Date: Thu, 15 Jun 2023 22:26:10 GMT
Subject: Integrated: 8308643: Incorrect value of 'used' jvmstat counter
In-Reply-To: <fAi8nyXQf0uv3JMtBXgIoDdSXLOur4hIoSb4O_U2lhQ=.023b252a-d50e-4b6b-b7c0-1b7975c3206c@github.com>
References: <fAi8nyXQf0uv3JMtBXgIoDdSXLOur4hIoSb4O_U2lhQ=.023b252a-d50e-4b6b-b7c0-1b7975c3206c@github.com>
Message-ID: <zbpIwGy6y6eZXi9RevlIPpis5WPZZrwrKq7q1nIiEjQ=.c6f9dd82-325d-4532-a4e3-10032780428b@github.com>

On Sun, 28 May 2023 02:08:59 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this change that fixes the space-used performance counters
> provided by ParallelGC and SerialGC.
> 
> The prior fix for a problem in this area (JDK-8268265) wasn't correct.  It
> used a static "last value" variable, for use when sampling is blocked by an
> in-progress GC.  But there are multiple counters, so having one static "last
> value" variable doesn't work.  (Not sure what I and my reviewers were thinking
> at the time. Maybe we overlooked that there are multiple counters.)  The
> solution is to associate a "last value" with each of the counters.
> 
> Also added a test of basic functionality (just accessibility) of the space
> counters.  No regression test of the problem being fixed here, as its hard to
> reliably set up.
> 
> Note: SpaceCounters and CSpaceCounters are very nearly identical.  It's likely
> possible to refactor for more code sharing, which could be done as a followup.
> 
> Testing:
> mach5 tier1

This pull request has now been integrated.

Changeset: 92167505
Author:    Kim Barrett <kbarrett at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/92167505b217c0e6074f58f8479be97bc4c776b3
Stats:     150 lines in 5 files changed: 107 ins; 4 del; 39 mod

8308643: Incorrect value of 'used' jvmstat counter

Reviewed-by: tschatzl, ayang

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

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

From sspitsyn at openjdk.org  Fri Jun 16 05:52:59 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 16 Jun 2023 05:52:59 GMT
Subject: RFR: 8309663: test fails
 "assert(check_alignment(result)) failed: address not aligned:
 0x00000008baadbabe"
In-Reply-To: <fqPCs7pEUNY9ODLKOspB5buuBWtDPfKmouI8p05KBKw=.16dec9bd-ca79-41ef-808f-4967073151d2@github.com>
References: <fqPCs7pEUNY9ODLKOspB5buuBWtDPfKmouI8p05KBKw=.16dec9bd-ca79-41ef-808f-4967073151d2@github.com>
Message-ID: <iqmW_fIFTeMoYg62tAA3pLT4fM1Aq3boeGyxEIodKoQ=.3aa24da9-b5db-4c32-952c-d098dcf59344@github.com>

On Wed, 14 Jun 2023 01:02:09 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> If virtual thread has frames in stackChunks, need to apply load barriers before processing nmethods (javaVFrame::locals() and javaVFrame::expressions() do it internally)
> 
> Testing: tier1-tier5;
> 400 runs of VThreadStackRefTest.java test on linux-x64 and linux-x64-debug with "-XX:+UseZGC -Xcomp -XX:-TieredCompilation"

Looks good.
Thanks,
Serguei

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

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14460#pullrequestreview-1482760969

From sspitsyn at openjdk.org  Fri Jun 16 05:53:02 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 16 Jun 2023 05:53:02 GMT
Subject: RFR: 8309663: test fails
 "assert(check_alignment(result)) failed: address not aligned:
 0x00000008baadbabe"
In-Reply-To: <E2U5bfawmMjCgzqe9pnzCBsL32YGRPcJUQ-ECswmLiY=.3cd140e7-1118-4485-9b32-822fa0af8f33@github.com>
References: <fqPCs7pEUNY9ODLKOspB5buuBWtDPfKmouI8p05KBKw=.16dec9bd-ca79-41ef-808f-4967073151d2@github.com>
 <Q5PaUjdpGBvTADcC1vItvofC1VMICsdSYvoVsTslqzA=.e03a47a5-a331-4d13-b622-f203e3430404@github.com>
 <E2U5bfawmMjCgzqe9pnzCBsL32YGRPcJUQ-ECswmLiY=.3cd140e7-1118-4485-9b32-822fa0af8f33@github.com>
Message-ID: <KmgtTOPbRb1Tpw6nDG576zl6_JRsdh_sk_WwmSS61AU=.9ed092da-0c5a-4596-a4fb-886b708d7e60@github.com>

On Wed, 14 Jun 2023 19:28:23 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> src/hotspot/share/prims/jvmtiTagMap.cpp line 2325:
>> 
>>> 2323:         // Need to apply load barriers for unmounted vthreads.
>>> 2324:         nmethod* nm = jvf->cb()->as_nmethod();
>>> 2325:         nm->run_nmethod_entry_barrier();
>> 
>> This looks good in general.
>> However, I'm looking at the `stackChunkOopDesc::do_barriers0()` implementation and wonder if a similar trick is needed for interpreter frames (to support `Class Redefinition`):
>> 
>> template <stackChunkOopDesc::BarrierType barrier, ChunkFrames frame_kind, typename RegisterMapT>
>> void stackChunkOopDesc::do_barriers0(const StackChunkFrameStream<frame_kind>& f, const RegisterMapT* map) {
>>   // We need to invoke the write barriers so as not to miss oops in old chunks that haven't yet been concurrently scanned
>>   assert (!f.is_done(), "");
>> 
>>   if (f.is_interpreted()) {
>>     Method* m = f.to_frame().interpreter_frame_method();
>>     // Class redefinition support
>>     m->record_gc_epoch();
>>   } else if (f.is_compiled()) {
>>     nmethod* nm = f.cb()->as_nmethod();
>>     // The entry barrier takes care of having the right synchronization
>>     // when keeping the nmethod alive during concurrent execution.
>>     nm->run_nmethod_entry_barrier();
>>     // There is no need to mark the Method, as class redefinition will walk the
>>     // CodeCache, noting their Methods
>>   }
>>   . . .
>
>> This looks good in general. However, I'm looking at the `stackChunkOopDesc::do_barriers0()` implementation and wonder if a similar trick is needed for interpreter frames (to support `Class Redefinition`):
>> 
> 
> This code collects references from thread stack, I don't see how class redefinition can affect them

Thanks. I agree with it.
The stackChunkOopDesc implementation needs it as it does some stack chunk updates.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14460#discussion_r1231803017

From tschatzl at openjdk.org  Fri Jun 16 09:41:15 2023
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Fri, 16 Jun 2023 09:41:15 GMT
Subject: RFR: 8219357: G1: G1GCPhaseTimes::debug_phase uses unnecessary
 ResourceMark
Message-ID: <_VX8z68nagpqV5vSaaHQ43A5soD3aZB1SFR_FRAaRos=.11fb1011-407d-4679-af6b-dadcd6898390@github.com>

Hi all,

  please review this removal of an unnecessary `ResourceMark`.

Testing: local compilation, gha

Thanks,
  Thomas

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

Commit messages:
 - initial version

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

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

From tschatzl at openjdk.org  Fri Jun 16 10:07:10 2023
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Fri, 16 Jun 2023 10:07:10 GMT
Subject: RFR: 8248149: G1: change _cleaning_claimed from int to bool
In-Reply-To: <ZjN_tCzYGG_anDVJc-cTOhdqt8tGG-WzrRT7f-NmRvk=.a35732cb-43c9-4f7c-8157-da9128a995c5@github.com>
References: <Dty-AHn0hLZmHpX9Kl0YtYFjKveyKMJArFc-fX048iQ=.1787da0c-6026-4e61-b036-92480e17fac4@github.com>
 <ZjN_tCzYGG_anDVJc-cTOhdqt8tGG-WzrRT7f-NmRvk=.a35732cb-43c9-4f7c-8157-da9128a995c5@github.com>
Message-ID: <pNBqKHPjHMVbiqWiNa_oWlwL94lROW7lf0FjpRvBWiQ=.a9672dd5-cad6-40e3-8d49-06545bb651c6@github.com>

On Thu, 15 Jun 2023 10:41:23 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Hi all,
>> 
>>   please review this change to fix some claim variable from `int` to `bool` as it should be.
>> 
>> Testing: gha
>> 
>> Thanks,
>>   Thomas
>
> Marked as reviewed by ayang (Reviewer).

Thanks @albertnetymk @kimbarrett @lkorinth for your reviews

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

PR Comment: https://git.openjdk.org/jdk/pull/14487#issuecomment-1594435677

From tschatzl at openjdk.org  Fri Jun 16 10:07:10 2023
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Fri, 16 Jun 2023 10:07:10 GMT
Subject: Integrated: 8248149: G1: change _cleaning_claimed from int to bool
In-Reply-To: <Dty-AHn0hLZmHpX9Kl0YtYFjKveyKMJArFc-fX048iQ=.1787da0c-6026-4e61-b036-92480e17fac4@github.com>
References: <Dty-AHn0hLZmHpX9Kl0YtYFjKveyKMJArFc-fX048iQ=.1787da0c-6026-4e61-b036-92480e17fac4@github.com>
Message-ID: <-Vb9FnVXO7lVOH2-yBCdf_8yHnU9CEWUhXmlWRBVybQ=.79e0324f-a44c-4299-9a61-33b6e8e11f21@github.com>

On Thu, 15 Jun 2023 09:22:39 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   please review this change to fix some claim variable from `int` to `bool` as it should be.
> 
> Testing: gha
> 
> Thanks,
>   Thomas

This pull request has now been integrated.

Changeset: fb024fde
Author:    Thomas Schatzl <tschatzl at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/fb024fde7bffde29dd3ec1ae26d04f4ccd64ad7e
Stats:     4 lines in 2 files changed: 0 ins; 0 del; 4 mod

8248149: G1: change _cleaning_claimed from int to bool

Reviewed-by: lkorinth, ayang, kbarrett

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

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

From shade at openjdk.org  Fri Jun 16 10:16:00 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 16 Jun 2023 10:16:00 GMT
Subject: RFR: 8219357: G1: G1GCPhaseTimes::debug_phase uses unnecessary
 ResourceMark
In-Reply-To: <_VX8z68nagpqV5vSaaHQ43A5soD3aZB1SFR_FRAaRos=.11fb1011-407d-4679-af6b-dadcd6898390@github.com>
References: <_VX8z68nagpqV5vSaaHQ43A5soD3aZB1SFR_FRAaRos=.11fb1011-407d-4679-af6b-dadcd6898390@github.com>
Message-ID: <YMmswXyrwEKmFwJ5lbzTLeJHgDaDmXQQAhaakFyRCa8=.37cd0632-e708-4ee3-ac2f-30c0e654c838@github.com>

On Fri, 16 Jun 2023 09:35:12 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   please review this removal of an unnecessary `ResourceMark`.
> 
> Testing: local compilation, gha
> 
> Thanks,
>   Thomas

Looks okay, just from the symmetry with `trace_phase` below.

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

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14512#pullrequestreview-1483158365

From tschatzl at openjdk.org  Fri Jun 16 10:26:03 2023
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Fri, 16 Jun 2023 10:26:03 GMT
Subject: RFR: 8219357: G1: G1GCPhaseTimes::debug_phase uses unnecessary
 ResourceMark
In-Reply-To: <YMmswXyrwEKmFwJ5lbzTLeJHgDaDmXQQAhaakFyRCa8=.37cd0632-e708-4ee3-ac2f-30c0e654c838@github.com>
References: <_VX8z68nagpqV5vSaaHQ43A5soD3aZB1SFR_FRAaRos=.11fb1011-407d-4679-af6b-dadcd6898390@github.com>
 <YMmswXyrwEKmFwJ5lbzTLeJHgDaDmXQQAhaakFyRCa8=.37cd0632-e708-4ee3-ac2f-30c0e654c838@github.com>
Message-ID: <iJQ1YVl_KwJTPue6jiwI2Yl1c4L_SQSNRWhtcqD_9kk=.567d091d-c18b-433c-a7f6-5e8581ce5bad@github.com>

On Fri, 16 Jun 2023 10:13:25 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Looks okay, just from the symmetry with `trace_phase` below.

I did go through the code to see if there would be a reason to have it, but found none.

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

PR Comment: https://git.openjdk.org/jdk/pull/14512#issuecomment-1594460456

From stefank at openjdk.org  Fri Jun 16 12:13:29 2023
From: stefank at openjdk.org (Stefan Karlsson)
Date: Fri, 16 Jun 2023 12:13:29 GMT
Subject: RFR: 8310194: Generational ZGC: Lock-order asserts in JVMTI
 IterateThroughHeap
Message-ID: <JFgqaXsFv8JyuOzQuXC3sioAeiGTZxTiw-4gnX-j6Ok=.6a2ceeb4-b304-46cb-be4e-9816beeb7d6a@github.com>

Generational ZGC changed the location where the heap object iterator called the visit function. It used to be called when the objects were popped and then followed, but it was changed so that the function where called immediately when the objects are marked. This gave the benefit that the verification code code show exactly what root had a broken object. Unfortunately, this change started to apply non-GC closure during the root iteration. This code lead to lock order issues, just like the one described in the JBS entry.

This fix moves the visit calls for non-GC closures back to the follow calls.

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

Commit messages:
 - Clean out old comment
 - 8310194: Generational ZGC: Lock order asserts in JVMTI IterateThroughHeap

Changes: https://git.openjdk.org/jdk/pull/14518/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14518&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8310194
  Stats: 203 lines in 5 files changed: 103 ins; 37 del; 63 mod
  Patch: https://git.openjdk.org/jdk/pull/14518.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14518/head:pull/14518

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

From stefank at openjdk.org  Fri Jun 16 12:13:29 2023
From: stefank at openjdk.org (Stefan Karlsson)
Date: Fri, 16 Jun 2023 12:13:29 GMT
Subject: RFR: 8310194: Generational ZGC: Lock-order asserts in JVMTI
 IterateThroughHeap
In-Reply-To: <JFgqaXsFv8JyuOzQuXC3sioAeiGTZxTiw-4gnX-j6Ok=.6a2ceeb4-b304-46cb-be4e-9816beeb7d6a@github.com>
References: <JFgqaXsFv8JyuOzQuXC3sioAeiGTZxTiw-4gnX-j6Ok=.6a2ceeb4-b304-46cb-be4e-9816beeb7d6a@github.com>
Message-ID: <hLEOeImTFr0z6EmCenvYktBFC8G9lpWcfJcxxwUw2f4=.1665b330-b63e-4dea-ab8f-a5180cf3a29d@github.com>

On Fri, 16 Jun 2023 11:52:51 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> Generational ZGC changed the location where the heap object iterator called the visit function. It used to be called when the objects were popped and then followed, but it was changed so that the function where called immediately when the objects are marked. This gave the benefit that the verification code code show exactly what root had a broken object. Unfortunately, this change started to apply non-GC closure during the root iteration. This code lead to lock order issues, just like the one described in the JBS entry.
> 
> This fix moves the visit calls for non-GC closures back to the follow calls.

It was quite hard to provoke this problem, and this bug was found in one of Oracle's internal stress tests. The stack trace looked like this:

#  assert(false) failed: Attempting to acquire lock ObjectSynchronizer Weak alloc lock/oopstorage out of order with lock Service_lock/service -- possible deadlock
...
V  [libjvm.so+0x13fcc3c]  Mutex::check_rank(Thread*)+0x36c  (mutex.cpp:447)
V  [libjvm.so+0x13fdee0]  Mutex::lock_without_safepoint_check()+0x50  (mutex.cpp:145)
V  [libjvm.so+0x14819b9]  OopStorage::allocate()+0x29  (mutexLocker.hpp:199)
V  [libjvm.so+0x18a8bd0]  WeakHandle::WeakHandle(OopStorage*, oop)+0x20  (weakHandle.cpp:37)
V  [libjvm.so+0x144e4f2]  ObjectMonitor::ObjectMonitor(oop)+0x62  (objectMonitor.cpp:261)
V  [libjvm.so+0x17337f5]  ObjectSynchronizer::inflate(Thread*, oop, ObjectSynchronizer::InflateCause)+0x675  (synchronizer.cpp:1425)
V  [libjvm.so+0x1736036]  ObjectSynchronizer::FastHashCode(Thread*, oop)+0x146  (synchronizer.cpp:1001)
V  [libjvm.so+0x146491f]  oopDesc::slow_identity_hash()+0x6f  (oop.cpp:112)
V  [libjvm.so+0x11bf2c5]  JvmtiTagMapTable::remove(oop)+0x265  (oop.inline.hpp:366)
V  [libjvm.so+0x11b6e0f]  CallbackWrapper::~CallbackWrapper()+0xef  (jvmtiTagMap.cpp:248)
V  [libjvm.so+0x11b290c]  IterateThroughHeapObjectClosure::do_object(oop)+0x59c  (jvmtiTagMap.cpp:1089)
V  [libjvm.so+0x1999518]  ZHeapIteratorContext::mark_and_push(oop) const [clone .part.0]+0x58  (zHeapIterator.cpp:81)
V  [libjvm.so+0x199c6d4]  ZHeapIteratorUncoloredRootOopClosure::do_oop(oop*)+0x154  (zHeapIterator.cpp:161)
V  [libjvm.so+0x19bda57]  ZNMethod::nmethod_oops_do_inner(nmethod*, OopClosure*)+0x47  (zNMethod.cpp:264)
V  [libjvm.so+0x19bdc1e]  ZNMethod::nmethod_oops_do(nmethod*, OopClosure*)+0x8e  (zNMethod.cpp:254)
V  [libjvm.so+0x1196195]  JvmtiDeferredEventQueue::oops_do(OopClosure*, CodeBlobClosure*)+0x45  (jvmtiImpl.cpp:1027)
V  [libjvm.so+0x15e5dd9]  ServiceThread::oops_do_no_frames(OopClosure*, CodeBlobClosure*)+0x59  (serviceThread.cpp:220)
V  [libjvm.so+0x1796ac6]  Thread::oops_do(OopClosure*, CodeBlobClosure*)+0x76  (thread.cpp:431)
V  [libjvm.so+0x19fad72]  ZJavaThreadsIterator::apply(ThreadClosure*)+0x102  (zRootsIterator.cpp:136)
V  [libjvm.so+0x19fb135]  ZRootsIteratorStrongUncolored::apply(ThreadClosure*, NMethodClosure*)+0x35  (zRootsIterator.cpp:96)
V  [libjvm.so+0x1997bed]  ZHeapIterator::push_strong_roots(ZHeapIteratorContext const&)+0x10d  (zHeapIterator.cpp:376)
V  [libjvm.so+0x199a37c]  ZHeapIterator::object_iterate(ObjectClosure*, unsigned int)+0x7c  (zHeapIterator.cpp:388)
V  [libjvm.so+0x199476e]  ZHeap::object_iterate(ObjectClosure*, bool)+0x5e  (zHeap.cpp:297)
V  [libjvm.so+0x11b787c]  VM_HeapIterateOperation::doit()+0x5c  (jvmtiTagMap.cpp:877)

You had to provoke the ObjectMonitor inflate code path via the identify_hash call from the JVMTI tagmap code, while the ServiceThread had a registered deferred event.
Note that the Service_lock is taken inside ServiceThread::oops_do_no_frames.

To more easily provoke the bug I temporarily added a oopstorage-ranked lock to IterateThroughHeapObjectClosure:

diff --git a/src/hotspot/share/prims/jvmtiTagMap.cpp b/src/hotspot/share/prims/jvmtiTagMap.cpp
index 6908e1994ba..a0e031eec31 100644
--- a/src/hotspot/share/prims/jvmtiTagMap.cpp
+++ b/src/hotspot/share/prims/jvmtiTagMap.cpp
@@ -967,6 +967,8 @@ class IterateThroughHeapObjectClosure: public ObjectClosure {
   const jvmtiHeapCallbacks* _callbacks;
   const void* _user_data;
 
+  Mutex _lock;
+
   // accessor functions
   JvmtiTagMap* tag_map() const                     { return _tag_map; }
   int heap_filter() const                          { return _heap_filter; }
@@ -1000,6 +1002,7 @@ class IterateThroughHeapObjectClosure: public ObjectClosure {
     _heap_filter(heap_filter),
     _callbacks(heap_callbacks),
     _user_data(user_data),
+    _lock(Mutex::oopstorage, "Test lock"),
     _iteration_aborted(false)
   {
   }
@@ -1009,6 +1012,10 @@ class IterateThroughHeapObjectClosure: public ObjectClosure {
 
 // invoked for each object in the heap
 void IterateThroughHeapObjectClosure::do_object(oop obj) {
+  {
+    MutexLocker locker(&_lock, Mutex::_no_safepoint_check_flag);
+  }
+
   // check if iteration has been halted
   if (is_iteration_aborted()) return;
 

With this I could consistently get the problem to reproduce within a few minutes. After moving the call to the visitor (IterateThroughHeapObjectClosure) to outside the root iterator I've been able to run the reproducer for a few hours without any asserts.

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

PR Comment: https://git.openjdk.org/jdk/pull/14518#issuecomment-1594566234

From duke at openjdk.org  Fri Jun 16 12:14:04 2023
From: duke at openjdk.org (Brett Okken)
Date: Fri, 16 Jun 2023 12:14:04 GMT
Subject: RFR: 8309622: Re-examine the cache mechanism in BaseLocale [v3]
In-Reply-To: <fCAxvr4_FpMeWhmZdgF2k3CUaPlIESDD0wda2N4haDM=.a238b319-720d-4ee2-b659-81d717a59d37@github.com>
References: <5MqmN4P1TLKDCfXPhKWrH1b2FTgOXmjtKgd1bVXDd_M=.2000f20d-365d-48dc-bc37-45d8bcb9447f@github.com>
 <fCAxvr4_FpMeWhmZdgF2k3CUaPlIESDD0wda2N4haDM=.a238b319-720d-4ee2-b659-81d717a59d37@github.com>
Message-ID: <CYiUcWIBmpqDZBnDtPrS0da8Evu0Xm9VOUOgA1yr5_Q=.a0ac9e38-9f75-4eca-b078-e8f48add366f@github.com>

On Tue, 13 Jun 2023 17:56:57 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> This is stemming from the PR: https://github.com/openjdk/jdk/pull/14211 where aggressive GC can cause NPE in `BaseLocale$Key` class. I refactored the in-house cache with WeakHashMap, and removed the Key class as it is no longer needed (thus the original NPE will no longer be possible). Also with the new JMH test case, it gains some performance improvement:
>> 
>> (w/o fix)
>> 
>> Benchmark                       Mode  Cnt      Score     Error  Units
>> LocaleCache.testForLanguageTag  avgt   20   5781.275 ? 569.580  ns/op
>> LocaleCache.testLocaleOf        avgt   20  62564.079 ? 406.697  ns/op
>> 
>> (w/ fix)
>> Benchmark                       Mode  Cnt      Score     Error  Units
>> LocaleCache.testForLanguageTag  avgt   20   4801.175 ? 371.830  ns/op
>> LocaleCache.testLocaleOf        avgt   20  60394.652 ? 352.471  ns/op
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Addressing review comments

src/java.base/share/classes/sun/util/locale/BaseLocale.java line 175:

> 173:                             LocaleUtils.toLowerString(b.getLanguage()).intern(),
> 174:                             LocaleUtils.toTitleString(b.getScript()).intern(),
> 175:                             LocaleUtils.toUpperString(b.getRegion()).intern(),

don't lines 147 and 148 above already guarantee the language and region have correct case?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14404#discussion_r1232167067

From duke at openjdk.org  Fri Jun 16 12:49:06 2023
From: duke at openjdk.org (Brett Okken)
Date: Fri, 16 Jun 2023 12:49:06 GMT
Subject: RFR: 8309622: Re-examine the cache mechanism in BaseLocale [v3]
In-Reply-To: <fCAxvr4_FpMeWhmZdgF2k3CUaPlIESDD0wda2N4haDM=.a238b319-720d-4ee2-b659-81d717a59d37@github.com>
References: <5MqmN4P1TLKDCfXPhKWrH1b2FTgOXmjtKgd1bVXDd_M=.2000f20d-365d-48dc-bc37-45d8bcb9447f@github.com>
 <fCAxvr4_FpMeWhmZdgF2k3CUaPlIESDD0wda2N4haDM=.a238b319-720d-4ee2-b659-81d717a59d37@github.com>
Message-ID: <SyBtZ_2foARX4ZKuCsOh1sBL8FvFIYNNx6zs_6AcMak=.6ba1413b-7d98-4351-9c29-a6af5b7ab12f@github.com>

On Tue, 13 Jun 2023 17:56:57 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> This is stemming from the PR: https://github.com/openjdk/jdk/pull/14211 where aggressive GC can cause NPE in `BaseLocale$Key` class. I refactored the in-house cache with WeakHashMap, and removed the Key class as it is no longer needed (thus the original NPE will no longer be possible). Also with the new JMH test case, it gains some performance improvement:
>> 
>> (w/o fix)
>> 
>> Benchmark                       Mode  Cnt      Score     Error  Units
>> LocaleCache.testForLanguageTag  avgt   20   5781.275 ? 569.580  ns/op
>> LocaleCache.testLocaleOf        avgt   20  62564.079 ? 406.697  ns/op
>> 
>> (w/ fix)
>> Benchmark                       Mode  Cnt      Score     Error  Units
>> LocaleCache.testForLanguageTag  avgt   20   4801.175 ? 371.830  ns/op
>> LocaleCache.testLocaleOf        avgt   20  60394.652 ? 352.471  ns/op
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Addressing review comments

src/java.base/share/classes/sun/util/locale/BaseLocale.java line 168:

> 166:         // BaseLocale as the key. The returned "normalized" instance
> 167:         // can subsequently be used by the Locale instance which
> 168:         // guarantees the locale components are properly cased/interned.

Is it truly important that the String values are interned, or is the desire simply that all refer to the same "canonical" String instance?
my thought is that managing the canonical String instances could avoid WeakReferences and synchronized map access and just return a new BaseLocale each time.




    public static BaseLocale getInstance(String language, String script,
                                         String region, String variant) {
        if (script == null) {
            script = "";
        } else {
            script = getCanonicalString(script, LocaleUtils::toTitleString);
        }

        if (region == null) {
            region = "";
        } else {
            region = getCanonicalString(region, LocaleUtils::toUpperString);
        }

        if (language == null) {
            language = "";
        } else {
            language = getCanonicalString(language, LocaleUtils::toLowerString);
        }
        
        if (variant == null) {
            variant = "";
        } else {
            variant = getCanonicalString(variant, Function.identity());
        }
        ...
        return new BaseLocale(language, script, region, variant);
    }



    private static final ConcurrentMap<String, String> CANONICALIZED_STRINGS = new ConcurrentHashMap<>();

    static {
        // prime the old iso codes
        CANONICALIZED_STRINGS.put("he", "he");
        CANONICALIZED_STRINGS.put("iw", "iw");
        CANONICALIZED_STRINGS.put("id", "id");
        CANONICALIZED_STRINGS.put("in", "in");
        CANONICALIZED_STRINGS.put("ji", "ji");
        CANONICALIZED_STRINGS.put("yi", "yi");
    }
    
    private static String getCanonicalString(String value, Function<String, String> conversion) {
        String existing = CANONICALIZED_STRINGS.get(value);
        if (existing != null) {
            return existing;
        }

        String converted = conversion.apply(value);
        return CANONICALIZED_STRINGS.merge(converted, converted, (k,v) -> v);
    }

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14404#discussion_r1232205527

From rkennke at openjdk.org  Fri Jun 16 13:02:48 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Fri, 16 Jun 2023 13:02:48 GMT
Subject: RFR: 8305896: Alternative full GC forwarding [v48]
In-Reply-To: <yFs73BPFgB89xCPY4k63X4VTz13N8ELJf1lGQlE6UpA=.85ee4f25-a4ee-41d0-b4c2-ed9ff2cb1bb1@github.com>
References: <yFs73BPFgB89xCPY4k63X4VTz13N8ELJf1lGQlE6UpA=.85ee4f25-a4ee-41d0-b4c2-ed9ff2cb1bb1@github.com>
Message-ID: <aOMTL4ZCyDUYNmJFvk8aSBxctx9NWuB080bT8DBdXb8=.619c1c4b-c43b-4143-b858-3553f790e231@github.com>

> Currently, the full-GC modes of Serial, Shenandoah and G1 GCs are forwarding objects by over-writing the object header with the new object location. Unfortunately, for compact object headers ([JDK-8294992](https://bugs.openjdk.org/browse/JDK-8294992)) this would not work, because the crucial class information is also stored in the header, and we could no longer iterate over objects until the headers would be restored. Also, the preserved-headers tables would grow quite large.
> 
> I propose to use an alternative algorithm for full-GC (sliding-GC) forwarding that uses a special encoding so that the forwarding information fits into the lowest 32 bits of the header.
> 
> It exploits the insight that, with sliding GCs, objects from one region will only ever be forwarded to one of two possible target regions. For this to work, we need to divide the heap into equal-sized regions. This is already the case for Shenandoah and G1, and can easily be overlaid for Serial GC, by assuming either the whole heap as a single region (if it fits) or by using SpaceAlignment-sized virtual regions.
> 
> We also build and maintain a table that has N elements, where N is the number of regions. Each entry is two addresses, which are the start-address of the possible target regions for each source region.
> 
> With this, forwarding information would be encoded like this:
>  - Bits 0 and 1: same as before, we put in '11' to indicate that the object is forwarded.
>  - Bit 2: Used for 'fallback'-forwarding (see below)
>  - Bit 3: Selects the target region 0 or 1. Look up the base address in the table (see above)
>  - Bits 4..31 The number of heap words from the target base address
> 
> This works well for all sliding GCs in Serial, G1 and Shenandoah. The exception is in G1, there is a special mode called 'serial compaction' which acts as a last-last-ditch effort to squeeze more space out of the heap by re-forwarding the tails of the compaction chains. Unfortunately, this breaks the assumption of the sliding-forwarding-table. When that happens, we initialize a fallback table, which is a simple open hash-table, and set the Bit 2 in the forwarding to indicate that we shall look up the forwardee in the fallback-table.
> 
> All the table accesses can be done unsynchronized because:
> - Serial GC is single-threaded anyway
> - In G1 and Shenandoah, GC worker threads divide up the work such that each worker does disjoint sets of regions.
> - G1 serial compaction is single-threaded
> 
> The change introduces a new (experimental) flag -...

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

 - Further templatize Serial GC's adjust_pointers()
 - Merge branch 'master' into JDK-8305896
 - Specialize full-GC loops to get UseAltGCForwarding flag check out of hot paths
 - Remove G1-only assert for fallback forwarding, and comment with explanation
 - Merge branch 'master' into JDK-8305896
 - Replace homegrown FallbackTable with a ResourceHashtable based impl
 - Merge remote-tracking branch 'origin/JDK-8305896' into JDK-8305896
 - Some more @shipilev comments
 - Update src/hotspot/share/gc/shared/slidingForwarding.hpp
   
   Co-authored-by: Aleksey Shipil?v <shipilev at amazon.de>
 - Align fake-heap without GCC warnings (duh)
 - ... and 105 more: https://git.openjdk.org/jdk/compare/b412fc79...524f9c52

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

Changes: https://git.openjdk.org/jdk/pull/13582/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13582&range=47
  Stats: 1407 lines in 40 files changed: 1186 ins; 100 del; 121 mod
  Patch: https://git.openjdk.org/jdk/pull/13582.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13582/head:pull/13582

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

From eosterlund at openjdk.org  Fri Jun 16 13:08:07 2023
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Fri, 16 Jun 2023 13:08:07 GMT
Subject: RFR: 8310194: Generational ZGC: Lock-order asserts in JVMTI
 IterateThroughHeap
In-Reply-To: <JFgqaXsFv8JyuOzQuXC3sioAeiGTZxTiw-4gnX-j6Ok=.6a2ceeb4-b304-46cb-be4e-9816beeb7d6a@github.com>
References: <JFgqaXsFv8JyuOzQuXC3sioAeiGTZxTiw-4gnX-j6Ok=.6a2ceeb4-b304-46cb-be4e-9816beeb7d6a@github.com>
Message-ID: <_VrgqP0X4MnaMbW1Ay3LEZbMoyR7S6lLrUszGXAb6x0=.72792f16-b659-4472-8538-7d39120dbb1c@github.com>

On Fri, 16 Jun 2023 11:52:51 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> Generational ZGC changed the location where the heap object iterator called the visit function. It used to be called when the objects were popped and then followed, but it was changed so that the function where called immediately when the objects are marked. This gave the benefit that the verification code code show exactly what root had a broken object. Unfortunately, this change started to apply non-GC closure during the root iteration. This code lead to lock order issues, just like the one described in the JBS entry.
> 
> This fix moves the visit calls for non-GC closures back to the follow calls.

Looks good.

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

Marked as reviewed by eosterlund (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14518#pullrequestreview-1483470046

From ayang at openjdk.org  Fri Jun 16 13:24:00 2023
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Fri, 16 Jun 2023 13:24:00 GMT
Subject: RFR: 8219357: G1: G1GCPhaseTimes::debug_phase uses unnecessary
 ResourceMark
In-Reply-To: <_VX8z68nagpqV5vSaaHQ43A5soD3aZB1SFR_FRAaRos=.11fb1011-407d-4679-af6b-dadcd6898390@github.com>
References: <_VX8z68nagpqV5vSaaHQ43A5soD3aZB1SFR_FRAaRos=.11fb1011-407d-4679-af6b-dadcd6898390@github.com>
Message-ID: <5mbpmPIMk71RTlYxTUrUWsYiHYxkHHlW9Vn67p2S7S4=.bf53a2ff-275c-4746-b9cb-112b570c4a9e@github.com>

On Fri, 16 Jun 2023 09:35:12 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   please review this removal of an unnecessary `ResourceMark`.
> 
> Testing: local compilation, gha
> 
> Thanks,
>   Thomas

Marked as reviewed by ayang (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/14512#pullrequestreview-1483496844

From aboldtch at openjdk.org  Fri Jun 16 13:50:16 2023
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Fri, 16 Jun 2023 13:50:16 GMT
Subject: RFR: 8310194: Generational ZGC: Lock-order asserts in JVMTI
 IterateThroughHeap
In-Reply-To: <JFgqaXsFv8JyuOzQuXC3sioAeiGTZxTiw-4gnX-j6Ok=.6a2ceeb4-b304-46cb-be4e-9816beeb7d6a@github.com>
References: <JFgqaXsFv8JyuOzQuXC3sioAeiGTZxTiw-4gnX-j6Ok=.6a2ceeb4-b304-46cb-be4e-9816beeb7d6a@github.com>
Message-ID: <MTk9zQjIr9kJhzcQse94MVG2-BG_WK6ImqJg1qELCu8=.cdd154bd-b8f0-4280-bc24-6dacc2204dd6@github.com>

On Fri, 16 Jun 2023 11:52:51 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> Generational ZGC changed the location where the heap object iterator called the visit function. It used to be called when the objects were popped and then followed, but it was changed so that the function where called immediately when the objects are marked. This gave the benefit that the verification code code show exactly what root had a broken object. Unfortunately, this change started to apply non-GC closure during the root iteration. This code lead to lock order issues, just like the one described in the JBS entry.
> 
> This fix moves the visit calls for non-GC closures back to the follow calls.

Looks good.

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

Marked as reviewed by aboldtch (Committer).

PR Review: https://git.openjdk.org/jdk/pull/14518#pullrequestreview-1483552664

From duke at openjdk.org  Fri Jun 16 14:44:00 2023
From: duke at openjdk.org (Ashutosh Mehra)
Date: Fri, 16 Jun 2023 14:44:00 GMT
Subject: RFR: 8310160: Make GC APIs for handling archive heap objects
 agnostic of GC policy
In-Reply-To: <S6B2u9JEc8rz29_HpCadu8vAQaRLqS_8Tj6O57z583w=.e6b981e4-38f8-41eb-8ae6-cf1378ceac10@github.com>
References: <S6B2u9JEc8rz29_HpCadu8vAQaRLqS_8Tj6O57z583w=.e6b981e4-38f8-41eb-8ae6-cf1378ceac10@github.com>
Message-ID: <-g7er2PkT4Ia_s85iSz_Avm78mBou57_LLf72ruvXUU=.cc0f5409-62dc-4b2e-944e-b69a1cd4748b@github.com>

On Fri, 16 Jun 2023 14:26:09 GMT, Ashutosh Mehra <duke at openjdk.org> wrote:

> This PR adds GC APIs to be implemented by all collectors for proper handling of archive heap space. Currently only G1 is updated to use these APIs which just involves renaming the existing G1 APIs.
> In addition to that filemap.cpp is updated to replace calls to `G1CollectedHeap::heap()` with `Universe::heap()` to avoid G1 specific code as much as possible.
> 
> At many places in filemap.cpp heap range is requested from GC. All collectors except ZGC have contiguous heap and set `CollectedHeap::_reserved` to the heap range, so it can be easily exposed to the CDS code. This is done in this patch through `CollectedHeap::reserved` API. But for ZGC the heap can be discontiguous which makes it tricky to expose the heap range.
> Another point to note is that most of the usage for heap range is for logging purpose, but there is one place where it is used for setting the `mapping_offset` in `FileMapInfo::write_region()` based on the heap start. So purely based on the functional requirement, we only need the heap start address, not the range.
> 
> To keep things simple and considering ZGC does not currently support archive heap, i refrained from tackling the issue of discontiguous heap range in this PR.

fyi - @iklam @tschatzl

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

PR Comment: https://git.openjdk.org/jdk/pull/14520#issuecomment-1594808396

From rkennke at openjdk.org  Fri Jun 16 14:59:28 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Fri, 16 Jun 2023 14:59:28 GMT
Subject: RFR: 8305896: Alternative full GC forwarding [v48]
In-Reply-To: <aOMTL4ZCyDUYNmJFvk8aSBxctx9NWuB080bT8DBdXb8=.619c1c4b-c43b-4143-b858-3553f790e231@github.com>
References: <yFs73BPFgB89xCPY4k63X4VTz13N8ELJf1lGQlE6UpA=.85ee4f25-a4ee-41d0-b4c2-ed9ff2cb1bb1@github.com>
 <aOMTL4ZCyDUYNmJFvk8aSBxctx9NWuB080bT8DBdXb8=.619c1c4b-c43b-4143-b858-3553f790e231@github.com>
Message-ID: <FswY84GQZ5PD4Tc5ROFGdf40s9QgHALThNJOBVLwlkc=.ba0d89f4-a179-49b3-ba4c-f0a7de20b826@github.com>

On Fri, 16 Jun 2023 13:02:48 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> Currently, the full-GC modes of Serial, Shenandoah and G1 GCs are forwarding objects by over-writing the object header with the new object location. Unfortunately, for compact object headers ([JDK-8294992](https://bugs.openjdk.org/browse/JDK-8294992)) this would not work, because the crucial class information is also stored in the header, and we could no longer iterate over objects until the headers would be restored. Also, the preserved-headers tables would grow quite large.
>> 
>> I propose to use an alternative algorithm for full-GC (sliding-GC) forwarding that uses a special encoding so that the forwarding information fits into the lowest 32 bits of the header.
>> 
>> It exploits the insight that, with sliding GCs, objects from one region will only ever be forwarded to one of two possible target regions. For this to work, we need to divide the heap into equal-sized regions. This is already the case for Shenandoah and G1, and can easily be overlaid for Serial GC, by assuming either the whole heap as a single region (if it fits) or by using SpaceAlignment-sized virtual regions.
>> 
>> We also build and maintain a table that has N elements, where N is the number of regions. Each entry is two addresses, which are the start-address of the possible target regions for each source region.
>> 
>> With this, forwarding information would be encoded like this:
>>  - Bits 0 and 1: same as before, we put in '11' to indicate that the object is forwarded.
>>  - Bit 2: Used for 'fallback'-forwarding (see below)
>>  - Bit 3: Selects the target region 0 or 1. Look up the base address in the table (see above)
>>  - Bits 4..31 The number of heap words from the target base address
>> 
>> This works well for all sliding GCs in Serial, G1 and Shenandoah. The exception is in G1, there is a special mode called 'serial compaction' which acts as a last-last-ditch effort to squeeze more space out of the heap by re-forwarding the tails of the compaction chains. Unfortunately, this breaks the assumption of the sliding-forwarding-table. When that happens, we initialize a fallback table, which is a simple open hash-table, and set the Bit 2 in the forwarding to indicate that we shall look up the forwardee in the fallback-table.
>> 
>> All the table accesses can be done unsynchronized because:
>> - Serial GC is single-threaded anyway
>> - In G1 and Shenandoah, GC worker threads divide up the work such that each worker does disjoint sets of regions.
>> - G1 serial compaction is single-threaded
>> 
>> The c...
>
> Roman Kennke has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 115 commits:
> 
>  - Further templatize Serial GC's adjust_pointers()
>  - Merge branch 'master' into JDK-8305896
>  - Specialize full-GC loops to get UseAltGCForwarding flag check out of hot paths
>  - Remove G1-only assert for fallback forwarding, and comment with explanation
>  - Merge branch 'master' into JDK-8305896
>  - Replace homegrown FallbackTable with a ResourceHashtable based impl
>  - Merge remote-tracking branch 'origin/JDK-8305896' into JDK-8305896
>  - Some more @shipilev comments
>  - Update src/hotspot/share/gc/shared/slidingForwarding.hpp
>    
>    Co-authored-by: Aleksey Shipil?v <shipilev at amazon.de>
>  - Align fake-heap without GCC warnings (duh)
>  - ... and 105 more: https://git.openjdk.org/jdk/compare/b412fc79...524f9c52

I found one more place where I would need to specialize a loop in MarkSweep::adjust_pointers(). I've run the performance test again and now get these results:

baseline: 379.34ms
noaltfwd: 367.73ms (-3.0%)
altfwd: 435.17ms (+14.7% vs baseline, +18.3% vs noaltfwd)

1. Not sure where the earlier 7% figure came from. I've repeated the experiment a couple of times and the results are very reliable.
2. Yes, that is a 3% improvement. I think I improved inlining a little bit, by moving stuff to places where the templates would be picked up. That's a reliable result, too (but feel free to run your own experiments).

I would prefer to keep the flag and specialized loops. I really don't want users of the legacy (no-compact-headers) path to experience any bad performance or stability surprises. (Especially not when eventually backporting it to 21u or maybe even 17u).

Do we want to move this PR forward, now that we have the jdk22 train open?

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

PR Comment: https://git.openjdk.org/jdk/pull/13582#issuecomment-1594828570

From rkennke at openjdk.org  Fri Jun 16 15:01:45 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Fri, 16 Jun 2023 15:01:45 GMT
Subject: RFR: 8305898: Alternative self-forwarding mechanism [v18]
In-Reply-To: <z4_xbPpS_Wg5DGaFhbEUYfYSGaAJeHvIv54IdSQIQNY=.82c97874-a01d-4e73-8cbf-5112f1eed18a@github.com>
References: <z4_xbPpS_Wg5DGaFhbEUYfYSGaAJeHvIv54IdSQIQNY=.82c97874-a01d-4e73-8cbf-5112f1eed18a@github.com>
Message-ID: <J1o080imdD2iOhhuVO5HWVKnlE5vum-VRr3GYfnwkZE=.917e148a-52ad-446c-b79b-d873506a1d14@github.com>

> Currently, the Serial, Parallel and G1 GCs store a pointer to self into object headers, when compaction fails, to indicate that the object has been looked at, but failed compaction into to-space. This is problematic for compact object headers ([JDK-8294992](https://bugs.openjdk.org/browse/JDK-8294992)) because it would (temporarily) over-write the crucial class information, which we need for heap parsing. I would like to propose an alternative: use the bit #3 (previously biased-locking bit) to indicate that an object is 'self-forwarded'. That preserves the crucial class information in the upper bits of the header until the full header gets restored.

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

 - Merge branch 'JDK-8305896' into JDK-8305898
 - Merge branch 'JDK-8305896' into JDK-8305898
 - Update comment about mark-word layout
 - Merge branch 'JDK-8305896' into JDK-8305898
 - Fix tests on 32bit builds
 - Merge branch 'JDK-8305896' into JDK-8305898
 - Merge branch 'JDK-8305896' into JDK-8305898
 - wqRevert "Rename self-forwarded -> forward-failed"
   
   This reverts commit 4d9713ca239da8e294c63887426bfb97240d3130.
 - Merge branch 'JDK-8305896' into JDK-8305898
 - Merge remote-tracking branch 'origin/JDK-8305898' into JDK-8305898
 - ... and 20 more: https://git.openjdk.org/jdk/compare/524f9c52...3838ac05

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

Changes: https://git.openjdk.org/jdk/pull/13779/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13779&range=17
  Stats: 101 lines in 8 files changed: 85 ins; 2 del; 14 mod
  Patch: https://git.openjdk.org/jdk/pull/13779.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13779/head:pull/13779

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

From naoto at openjdk.org  Fri Jun 16 17:22:04 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 16 Jun 2023 17:22:04 GMT
Subject: RFR: 8309622: Re-examine the cache mechanism in BaseLocale [v3]
In-Reply-To: <SyBtZ_2foARX4ZKuCsOh1sBL8FvFIYNNx6zs_6AcMak=.6ba1413b-7d98-4351-9c29-a6af5b7ab12f@github.com>
References: <5MqmN4P1TLKDCfXPhKWrH1b2FTgOXmjtKgd1bVXDd_M=.2000f20d-365d-48dc-bc37-45d8bcb9447f@github.com>
 <fCAxvr4_FpMeWhmZdgF2k3CUaPlIESDD0wda2N4haDM=.a238b319-720d-4ee2-b659-81d717a59d37@github.com>
 <SyBtZ_2foARX4ZKuCsOh1sBL8FvFIYNNx6zs_6AcMak=.6ba1413b-7d98-4351-9c29-a6af5b7ab12f@github.com>
Message-ID: <fvm7OX2FjbxpRjC340G5rBAxz4qC6Qpbdc6ODFpXf3I=.8d88b6fe-b1d1-4e5b-b510-4dcecb179be5@github.com>

On Fri, 16 Jun 2023 12:46:01 GMT, Brett Okken <duke at openjdk.org> wrote:

>> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Addressing review comments
>
> src/java.base/share/classes/sun/util/locale/BaseLocale.java line 168:
> 
>> 166:         // BaseLocale as the key. The returned "normalized" instance
>> 167:         // can subsequently be used by the Locale instance which
>> 168:         // guarantees the locale components are properly cased/interned.
> 
> Is it truly important that the String values are interned, or is the desire simply that all refer to the same "canonical" String instance?
> my thought is that managing the canonical String instances could avoid WeakReferences and synchronized map access and just return a new BaseLocale each time.
> 
> 
> 
> 
>     public static BaseLocale getInstance(String language, String script,
>                                          String region, String variant) {
>         if (script == null || script.isEmpty()) {
>             script = "";
>         } else {
>             script = getCanonicalString(script, LocaleUtils::toTitleString);
>         }
> 
>         if (region == null || region.isEmpty()) {
>             region = "";
>         } else {
>             region = getCanonicalString(region, LocaleUtils::toUpperString);
>         }
> 
>         if (language == null || language.isEmpty()) {
>             language = "";
>         } else {
>             language = getCanonicalString(language, LocaleUtils::toLowerString);
>         }
>         
>         if (variant == null || variant.isEmpty()) {
>             variant = "";
>         } else {
>             variant = getCanonicalString(variant, Function.identity());
>         }
>         ...
>         return new BaseLocale(language, script, region, variant);
>     }
> 
> 
> 
>     private static final ConcurrentMap<String, String> CANONICALIZED_STRINGS = new ConcurrentHashMap<>();
> 
>     static {
>         // prime the old iso codes
>         CANONICALIZED_STRINGS.put("he", "he");
>         CANONICALIZED_STRINGS.put("iw", "iw");
>         CANONICALIZED_STRINGS.put("id", "id");
>         CANONICALIZED_STRINGS.put("in", "in");
>         CANONICALIZED_STRINGS.put("ji", "ji");
>         CANONICALIZED_STRINGS.put("yi", "yi");
>     }
>     
>     private static String getCanonicalString(String value, Function<String, String> conversion) {
>         String existing = CANONICALIZED_STRINGS.get(value);
>         if (existing != null) {
>             return existing;
>         }
> 
>         String converted = conversion.apply(value);
>         return CANONICALIZED_STRINGS.merge(converted, converted, (k,v) -> v);
>     }

Interning components in a Locale instance (through BaseLocale) is a long standing behavior. Changing it could break apps that might have relied on it (using `==` for comparison)

> src/java.base/share/classes/sun/util/locale/BaseLocale.java line 175:
> 
>> 173:                             LocaleUtils.toLowerString(b.getLanguage()).intern(),
>> 174:                             LocaleUtils.toTitleString(b.getScript()).intern(),
>> 175:                             LocaleUtils.toUpperString(b.getRegion()).intern(),
> 
> don't lines 147 and 148 above already guarantee the language and region have correct case?

147,148 are in `getInstance()` and the BaseLocale key here is created with a constructor, which simply copies the passed arguments. So normalization is needed here

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14404#discussion_r1232528918
PR Review Comment: https://git.openjdk.org/jdk/pull/14404#discussion_r1232528986

From duke at openjdk.org  Fri Jun 16 23:07:09 2023
From: duke at openjdk.org (Brett Okken)
Date: Fri, 16 Jun 2023 23:07:09 GMT
Subject: RFR: 8309622: Re-examine the cache mechanism in BaseLocale [v3]
In-Reply-To: <fvm7OX2FjbxpRjC340G5rBAxz4qC6Qpbdc6ODFpXf3I=.8d88b6fe-b1d1-4e5b-b510-4dcecb179be5@github.com>
References: <5MqmN4P1TLKDCfXPhKWrH1b2FTgOXmjtKgd1bVXDd_M=.2000f20d-365d-48dc-bc37-45d8bcb9447f@github.com>
 <fCAxvr4_FpMeWhmZdgF2k3CUaPlIESDD0wda2N4haDM=.a238b319-720d-4ee2-b659-81d717a59d37@github.com>
 <SyBtZ_2foARX4ZKuCsOh1sBL8FvFIYNNx6zs_6AcMak=.6ba1413b-7d98-4351-9c29-a6af5b7ab12f@github.com>
 <fvm7OX2FjbxpRjC340G5rBAxz4qC6Qpbdc6ODFpXf3I=.8d88b6fe-b1d1-4e5b-b510-4dcecb179be5@github.com>
Message-ID: <kgHbRjygYOWymroVUQRzMTvBORaS1xA1oNntD5JLAC8=.fc94b5c2-7e76-4eea-842e-aa1416c96cc6@github.com>

On Fri, 16 Jun 2023 17:18:33 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> src/java.base/share/classes/sun/util/locale/BaseLocale.java line 168:
>> 
>>> 166:         // BaseLocale as the key. The returned "normalized" instance
>>> 167:         // can subsequently be used by the Locale instance which
>>> 168:         // guarantees the locale components are properly cased/interned.
>> 
>> Is it truly important that the String values are interned, or is the desire simply that all refer to the same "canonical" String instance?
>> my thought is that managing the canonical String instances could avoid WeakReferences and synchronized map access and just return a new BaseLocale each time.
>> 
>> 
>> 
>> 
>>     public static BaseLocale getInstance(String language, String script,
>>                                          String region, String variant) {
>>         if (script == null || script.isEmpty()) {
>>             script = "";
>>         } else {
>>             script = getCanonicalString(script, LocaleUtils::toTitleString);
>>         }
>> 
>>         if (region == null || region.isEmpty()) {
>>             region = "";
>>         } else {
>>             region = getCanonicalString(region, LocaleUtils::toUpperString);
>>         }
>> 
>>         if (language == null || language.isEmpty()) {
>>             language = "";
>>         } else {
>>             language = getCanonicalString(language, LocaleUtils::toLowerString);
>>         }
>>         
>>         if (variant == null || variant.isEmpty()) {
>>             variant = "";
>>         } else {
>>             variant = getCanonicalString(variant, Function.identity());
>>         }
>>         ...
>>         return new BaseLocale(language, script, region, variant);
>>     }
>> 
>> 
>> 
>>     private static final ConcurrentMap<String, String> CANONICALIZED_STRINGS = new ConcurrentHashMap<>();
>> 
>>     static {
>>         // prime the old iso codes
>>         CANONICALIZED_STRINGS.put("he", "he");
>>         CANONICALIZED_STRINGS.put("iw", "iw");
>>         CANONICALIZED_STRINGS.put("id", "id");
>>         CANONICALIZED_STRINGS.put("in", "in");
>>         CANONICALIZED_STRINGS.put("ji", "ji");
>>         CANONICALIZED_STRINGS.put("yi", "yi");
>>     }
>>     
>>     private static String getCanonicalString(String value, Function<String, String> conversion) {
>>         String existing = CANONICALIZED_STRINGS.get(value);
>>         if (existing != null) {
>>             return existing;
>>         }
>> 
>>         String converted = conversion.apply(value);
>>         return CANONICALIZED_STRINGS.merge(converted, converted, (k,v) -> v);...
>
> Interning components in a Locale instance (through BaseLocale) is a long standing behavior. Changing it could break apps that might have relied on it (using `==` for comparison)

as in doing `"en" == locale.getLanguage()`?

In that case, the interned values could still be used as the canonical values, and the CHM can account both for case adjustments and interning (and likely faster than actually calling intern). I am curious how this does with your jmh test:



    private static final ConcurrentMap<String, String> CANONICALIZED_UPPER_STRINGS = new ConcurrentHashMap<>();
    private static final ConcurrentMap<String, String> CANONICALIZED_LOWER_STRINGS = new ConcurrentHashMap<>();
    private static final ConcurrentMap<String, String> CANONICALIZED_TITLE_STRINGS = new ConcurrentHashMap<>();
    private static final ConcurrentMap<String, String> CANONICALIZED_STRINGS = new ConcurrentHashMap<>();

    public static BaseLocale getInstance(String language, String script,
                                         String region, String variant) {
        if (script == null || script.isEmpty()) {
            script = "";
        } else {
            script = getCanonicalString(script, LocaleUtils::toTitleString, CANONICALIZED_TITLE_STRINGS);
        }

        if (region == null || region.isEmpty()) {
            region = "";
        } else {
            region = getCanonicalString(region, LocaleUtils::toUpperString, CANONICALIZED_UPPER_STRINGS);
        }

        if (language == null || language.isEmpty()) {
            language = "";
        } else {
            language = getCanonicalString(language, LocaleUtils::toLowerString, CANONICALIZED_LOWER_STRINGS);
        }

        if (variant == null || variant.isEmpty()) {
            variant = "";
        } else {
            variant = getCanonicalString(variant, Function.identity(), CANONICALIZED_STRINGS);
        }
        ...
        return new BaseLocale(language, script, region, variant);
    }

    private static String getCanonicalString(String value, Function<String, String> conversion, ConcurrentMap<String, String> map) {
        String existing = map.get(value);
        if (existing != null) {
            return existing;
        }

        String converted = conversion.apply(value).intern();
        // put the interned value in, keyed by the interned value
        map.putIfAbsent(converted, converted);

        // also put the interned value in for the given key, if not already present
        // this avoids future needs to apply a conversion to the value
        map.putIfAbsent(value, converted);
        return converted;
    }

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14404#discussion_r1232867251

From duke at openjdk.org  Fri Jun 16 23:42:07 2023
From: duke at openjdk.org (Brett Okken)
Date: Fri, 16 Jun 2023 23:42:07 GMT
Subject: RFR: 8309622: Re-examine the cache mechanism in BaseLocale [v3]
In-Reply-To: <fvm7OX2FjbxpRjC340G5rBAxz4qC6Qpbdc6ODFpXf3I=.8d88b6fe-b1d1-4e5b-b510-4dcecb179be5@github.com>
References: <5MqmN4P1TLKDCfXPhKWrH1b2FTgOXmjtKgd1bVXDd_M=.2000f20d-365d-48dc-bc37-45d8bcb9447f@github.com>
 <fCAxvr4_FpMeWhmZdgF2k3CUaPlIESDD0wda2N4haDM=.a238b319-720d-4ee2-b659-81d717a59d37@github.com>
 <SyBtZ_2foARX4ZKuCsOh1sBL8FvFIYNNx6zs_6AcMak=.6ba1413b-7d98-4351-9c29-a6af5b7ab12f@github.com>
 <fvm7OX2FjbxpRjC340G5rBAxz4qC6Qpbdc6ODFpXf3I=.8d88b6fe-b1d1-4e5b-b510-4dcecb179be5@github.com>
Message-ID: <gWkti9DR72RUYx0_08o08TjJdRAyWEZkQz5EWDkqKqE=.ad60c779-36d8-43b4-be52-5b0a8f72ffb7@github.com>

On Fri, 16 Jun 2023 17:18:38 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> src/java.base/share/classes/sun/util/locale/BaseLocale.java line 175:
>> 
>>> 173:                             LocaleUtils.toLowerString(b.getLanguage()).intern(),
>>> 174:                             LocaleUtils.toTitleString(b.getScript()).intern(),
>>> 175:                             LocaleUtils.toUpperString(b.getRegion()).intern(),
>> 
>> don't lines 147 and 148 above already guarantee the language and region have correct case?
>
> 147,148 are in `getInstance()` and the BaseLocale key here is created with a constructor, which simply copies the passed arguments. So normalization is needed here

perhaps I am missing something, but aren't `language` and `region` being reassigned to the case adjusted values? So the values used to create the "key" BaseLocale instance reflect that case adjustment? (language is again potentially adjusted at line 162 to account for old iso codes, but that never results in the wrong case.)


        language = LocaleUtils.toLowerString(language);
        region = LocaleUtils.toUpperString(region);

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14404#discussion_r1232880865

From kbarrett at openjdk.org  Sat Jun 17 01:00:37 2023
From: kbarrett at openjdk.org (Kim Barrett)
Date: Sat, 17 Jun 2023 01:00:37 GMT
Subject: RFR: 8308643: Incorrect value of 'used' jvmstat counter
Message-ID: <bTpeIXQGfYWEpIqPwA3Qc4BmoiMnTABdNlKnoygb2XI=.4edaf6c5-8931-461f-a724-9d6e2213599b@github.com>

Hi all,

This pull request contains a backport of commit [92167505](https://github.com/openjdk/jdk/commit/92167505b217c0e6074f58f8479be97bc4c776b3) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.

The commit being backported was authored by Kim Barrett on 15 Jun 2023 and was reviewed by Thomas Schatzl and Albert Mingkun Yang.

Thanks!

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

Commit messages:
 - Backport 92167505b217c0e6074f58f8479be97bc4c776b3

Changes: https://git.openjdk.org/jdk21/pull/27/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk21&pr=27&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8308643
  Stats: 150 lines in 5 files changed: 107 ins; 4 del; 39 mod
  Patch: https://git.openjdk.org/jdk21/pull/27.diff
  Fetch: git fetch https://git.openjdk.org/jdk21.git pull/27/head:pull/27

PR: https://git.openjdk.org/jdk21/pull/27

From iklam at openjdk.org  Sat Jun 17 05:11:28 2023
From: iklam at openjdk.org (Ioi Lam)
Date: Sat, 17 Jun 2023 05:11:28 GMT
Subject: RFR: 8310160: Make GC APIs for handling archive heap objects
 agnostic of GC policy
In-Reply-To: <S6B2u9JEc8rz29_HpCadu8vAQaRLqS_8Tj6O57z583w=.e6b981e4-38f8-41eb-8ae6-cf1378ceac10@github.com>
References: <S6B2u9JEc8rz29_HpCadu8vAQaRLqS_8Tj6O57z583w=.e6b981e4-38f8-41eb-8ae6-cf1378ceac10@github.com>
Message-ID: <26zbqrmO2QrCQwnPeiyis8Lguzp2qmrof6glLevCaps=.0c965e37-1f53-4351-977b-c0ca51147af4@github.com>

On Fri, 16 Jun 2023 14:26:09 GMT, Ashutosh Mehra <duke at openjdk.org> wrote:

> This PR adds GC APIs to be implemented by all collectors for proper handling of archive heap space. Currently only G1 is updated to use these APIs which just involves renaming the existing G1 APIs.
> In addition to that filemap.cpp is updated to replace calls to `G1CollectedHeap::heap()` with `Universe::heap()` to avoid G1 specific code as much as possible.
> 
> At many places in filemap.cpp heap range is requested from GC. All collectors except ZGC have contiguous heap and set `CollectedHeap::_reserved` to the heap range, so it can be easily exposed to the CDS code. This is done in this patch through `CollectedHeap::reserved` API. But for ZGC the heap can be discontiguous which makes it tricky to expose the heap range.
> Another point to note is that most of the usage for heap range is for logging purpose, but there is one place where it is used for setting the `mapping_offset` in `FileMapInfo::write_region()` based on the heap start. So purely based on the functional requirement, we only need the heap start address, not the range.
> 
> To keep things simple and considering ZGC does not currently support archive heap, i refrained from tackling the issue of discontiguous heap range in this PR.

src/hotspot/share/cds/filemap.cpp line 2142:

> 2140:                               r->allow_exec());
> 2141:   if (base == nullptr || base != addr) {
> 2142:     handle_failed_mapping();

`handle_failed_mapping()` is called for several reasons where we are not able to use the archive heap:
- mmap failed for the `hp` or `bm` regions
- CRC check failure

So I think the wording of "mapping" is too specific and doesn't cover all cases (and also precludes the possibility of other failures in the future.

Also "handle" could imply a possibility of recovering from the failure, which isn't the case.

I think a more neutral name would be better. Maybe `release_archive_space()` in contrast of `alloc_archive_space` (or even `allocate_archive_space`, as we prefer proper words than short hands).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14520#discussion_r1232963031

From stuefe at openjdk.org  Sat Jun 17 17:51:10 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Sat, 17 Jun 2023 17:51:10 GMT
Subject: RFR: 8310160: Make GC APIs for handling archive heap objects
 agnostic of GC policy
In-Reply-To: <S6B2u9JEc8rz29_HpCadu8vAQaRLqS_8Tj6O57z583w=.e6b981e4-38f8-41eb-8ae6-cf1378ceac10@github.com>
References: <S6B2u9JEc8rz29_HpCadu8vAQaRLqS_8Tj6O57z583w=.e6b981e4-38f8-41eb-8ae6-cf1378ceac10@github.com>
Message-ID: <cBANQnhVoHtOEFWWf0KRoOnD2sdHvv_Wl91Tkeacu7Y=.33e8ad29-2444-4f06-9253-df2e44b18a2c@github.com>

On Fri, 16 Jun 2023 14:26:09 GMT, Ashutosh Mehra <duke at openjdk.org> wrote:

> This PR adds GC APIs to be implemented by all collectors for proper handling of archive heap space. Currently only G1 is updated to use these APIs which just involves renaming the existing G1 APIs.
> In addition to that filemap.cpp is updated to replace calls to `G1CollectedHeap::heap()` with `Universe::heap()` to avoid G1 specific code as much as possible.
> 
> At many places in filemap.cpp heap range is requested from GC. All collectors except ZGC have contiguous heap and set `CollectedHeap::_reserved` to the heap range, so it can be easily exposed to the CDS code. This is done in this patch through `CollectedHeap::reserved` API. But for ZGC the heap can be discontiguous which makes it tricky to expose the heap range.
> Another point to note is that most of the usage for heap range is for logging purpose, but there is one place where it is used for setting the `mapping_offset` in `FileMapInfo::write_region()` based on the heap start. So purely based on the functional requirement, we only need the heap start address, not the range.
> 
> To keep things simple and considering ZGC does not currently support archive heap, i refrained from tackling the issue of discontiguous heap range in this PR.

src/hotspot/share/cds/filemap.cpp line 1570:

> 1568:       assert((mapping_offset >> CompressedOops::shift()) << CompressedOops::shift() == mapping_offset, "must be");
> 1569:     } else {
> 1570:       assert(UseG1GC, "used by G1 only");

Is this assert needed? If yes, it should be guarding the whole HeapShared::is_heap_region() branch, not just this else branch. OTOH we already assert "HeapShared::can_write()", which is a stronger assert.

src/hotspot/share/cds/filemap.cpp line 2097:

> 2095:     assert(heap_range.contains(_mapped_heap_memregion), "must be");
> 2096: 
> 2097:     if (UseG1GC) {

This condition is odd. We only call FileMapInfo::map_heap_region() for G1, right? Maybe just assert at the start of the function for `ArchiveHeapLoader::can_map()` instead?

src/hotspot/share/gc/shared/collectedHeap.hpp line 212:

> 210:   MemRegion reserved() const {
> 211:     return _reserved;
> 212:   }

PSHeap, GenCollectedHeap and Shenandoah each already expose `_reserved` via `reserved_region()`. Can we remove all of them and rename this to `reserved_region()`?

src/hotspot/share/gc/shared/collectedHeap.hpp line 533:

> 531:   // GC policy can take necessary actions to make the archive space usable,
> 532:   // such as inserting filler objects to make it parseable, or updating block offset table.
> 533:   virtual void fixup_archive_space(MemRegion range) { return; }

Small nit about the naming of these callbacks. "fixup_archive_space" implies knowledge about what the collector does, as does "handle_archive_space_failure". But you want to abstract away collector work from CDS. @iklam already remarked on "handle..". 

I see these methods both more as callbacks, and as such they could be named after the point at which they are called, e.g. "on_cds_post_load" and "on_cds_load_error". Or similar. Named after when they are called, but assuming no knowledge of what the collector does at that point, if anything at all.

Up to you. This is very bikesheddy, I'm also fine with the names as they are.

src/hotspot/share/gc/shared/collectedHeap.hpp line 536:

> 534: 
> 535:   // Handle any failure in loading the CDS archive area.
> 536:   virtual void handle_archive_space_failure(MemRegion range) { return; }

For both `fixup_archive_space` and `handle_archive_space_failure`: Why do we need to pass in the MemRegion? The only valid argument in both cases is the MemRegion that had been previously established by a call to `alloc_archive_space`. 

Why not let CollectedHeap remember the MemRegion established by `alloc_archive_space`, thereby also guaranteeing that `alloc_archive_space` can only be called once, and refer to that in the followup calls?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14520#discussion_r1233097531
PR Review Comment: https://git.openjdk.org/jdk/pull/14520#discussion_r1233101564
PR Review Comment: https://git.openjdk.org/jdk/pull/14520#discussion_r1233094909
PR Review Comment: https://git.openjdk.org/jdk/pull/14520#discussion_r1233100361
PR Review Comment: https://git.openjdk.org/jdk/pull/14520#discussion_r1233100119

From stuefe at openjdk.org  Sat Jun 17 17:51:12 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Sat, 17 Jun 2023 17:51:12 GMT
Subject: RFR: 8310160: Make GC APIs for handling archive heap objects
 agnostic of GC policy
In-Reply-To: <26zbqrmO2QrCQwnPeiyis8Lguzp2qmrof6glLevCaps=.0c965e37-1f53-4351-977b-c0ca51147af4@github.com>
References: <S6B2u9JEc8rz29_HpCadu8vAQaRLqS_8Tj6O57z583w=.e6b981e4-38f8-41eb-8ae6-cf1378ceac10@github.com>
 <26zbqrmO2QrCQwnPeiyis8Lguzp2qmrof6glLevCaps=.0c965e37-1f53-4351-977b-c0ca51147af4@github.com>
Message-ID: <CtKt8-8Wq8od9n6wlsu7InmKa29mP14WlwS0LAPv2p8=.2ec00458-32ab-4220-a150-0165c2283452@github.com>

On Sat, 17 Jun 2023 05:08:28 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> I think a more neutral name would be better. Maybe `release_archive_space()` in contrast of `alloc_archive_space` (or even `allocate_archive_space`, as we prefer proper words than short hands).

"on_load_error"?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14520#discussion_r1233100868

From tschatzl at openjdk.org  Mon Jun 19 07:42:13 2023
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Mon, 19 Jun 2023 07:42:13 GMT
Subject: RFR: 8308643: Incorrect value of 'used' jvmstat counter
In-Reply-To: <bTpeIXQGfYWEpIqPwA3Qc4BmoiMnTABdNlKnoygb2XI=.4edaf6c5-8931-461f-a724-9d6e2213599b@github.com>
References: <bTpeIXQGfYWEpIqPwA3Qc4BmoiMnTABdNlKnoygb2XI=.4edaf6c5-8931-461f-a724-9d6e2213599b@github.com>
Message-ID: <Wsl_8LWCAffrXBruqri1LGW3YM1bGXhC7ft6FywnrVE=.605b46ea-52f0-4208-b790-4c13baf9b793@github.com>

On Sat, 17 Jun 2023 00:53:04 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [92167505](https://github.com/openjdk/jdk/commit/92167505b217c0e6074f58f8479be97bc4c776b3) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Kim Barrett on 15 Jun 2023 and was reviewed by Thomas Schatzl and Albert Mingkun Yang.
> 
> Thanks!

Lgtm

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

Marked as reviewed by tschatzl (Reviewer).

PR Review: https://git.openjdk.org/jdk21/pull/27#pullrequestreview-1485593070

From kbarrett at openjdk.org  Mon Jun 19 08:45:19 2023
From: kbarrett at openjdk.org (Kim Barrett)
Date: Mon, 19 Jun 2023 08:45:19 GMT
Subject: Integrated: 8308643: Incorrect value of 'used' jvmstat counter
In-Reply-To: <bTpeIXQGfYWEpIqPwA3Qc4BmoiMnTABdNlKnoygb2XI=.4edaf6c5-8931-461f-a724-9d6e2213599b@github.com>
References: <bTpeIXQGfYWEpIqPwA3Qc4BmoiMnTABdNlKnoygb2XI=.4edaf6c5-8931-461f-a724-9d6e2213599b@github.com>
Message-ID: <RBqpov7xYAegXP4B7FmA1mblpqsZcZ7lzlC_6ZI5F90=.2efd611d-c6e9-4557-b585-f9cdcb1467b8@github.com>

On Sat, 17 Jun 2023 00:53:04 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [92167505](https://github.com/openjdk/jdk/commit/92167505b217c0e6074f58f8479be97bc4c776b3) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Kim Barrett on 15 Jun 2023 and was reviewed by Thomas Schatzl and Albert Mingkun Yang.
> 
> Thanks!

This pull request has now been integrated.

Changeset: ace56237
Author:    Kim Barrett <kbarrett at openjdk.org>
URL:       https://git.openjdk.org/jdk21/commit/ace56237d39eaa67b37456d2af8cf71664815987
Stats:     150 lines in 5 files changed: 107 ins; 4 del; 39 mod

8308643: Incorrect value of 'used' jvmstat counter

Reviewed-by: tschatzl
Backport-of: 92167505b217c0e6074f58f8479be97bc4c776b3

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

PR: https://git.openjdk.org/jdk21/pull/27

From ayang at openjdk.org  Mon Jun 19 11:12:10 2023
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Mon, 19 Jun 2023 11:12:10 GMT
Subject: RFR: 8309960: ParallelGC young collections very slow in
 DelayInducer
In-Reply-To: <mntEDz2bEJF-ZQ5KxaRQ_vkMV4_P7JwrrgBhWsVDtEI=.ddf1c6ab-f90f-48c8-beef-1c78e7c51b9c@github.com>
References: <mntEDz2bEJF-ZQ5KxaRQ_vkMV4_P7JwrrgBhWsVDtEI=.ddf1c6ab-f90f-48c8-beef-1c78e7c51b9c@github.com>
Message-ID: <7Wys075Qe830-ziBlZ3mp-Pwk0m-oYoNHnKz5Ycu_fc=.f391c3b4-0b97-44a9-9d94-e8686a276333@github.com>

On Thu, 15 Jun 2023 12:12:23 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> 8309960: ParallelGC young collections very slow in DelayInducer

Thanks for the review.

Clean backport; merging now.

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

PR Comment: https://git.openjdk.org/jdk21/pull/22#issuecomment-1596986076

From ayang at openjdk.org  Mon Jun 19 11:12:11 2023
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Mon, 19 Jun 2023 11:12:11 GMT
Subject: Integrated: 8309960: ParallelGC young collections very slow in
 DelayInducer
In-Reply-To: <mntEDz2bEJF-ZQ5KxaRQ_vkMV4_P7JwrrgBhWsVDtEI=.ddf1c6ab-f90f-48c8-beef-1c78e7c51b9c@github.com>
References: <mntEDz2bEJF-ZQ5KxaRQ_vkMV4_P7JwrrgBhWsVDtEI=.ddf1c6ab-f90f-48c8-beef-1c78e7c51b9c@github.com>
Message-ID: <gdxG4qRAmOK4E5XXTTHboofqaYnwTcbBJAZvvGV0L2Y=.7c1d0c65-5e3c-4015-a4aa-d2628ffb4dc5@github.com>

On Thu, 15 Jun 2023 12:12:23 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> 8309960: ParallelGC young collections very slow in DelayInducer

This pull request has now been integrated.

Changeset: 4d81b899
Author:    Albert Mingkun Yang <ayang at openjdk.org>
URL:       https://git.openjdk.org/jdk21/commit/4d81b8998ae2e5c02a47264496bb87cc0c18808c
Stats:     8 lines in 1 file changed: 5 ins; 0 del; 3 mod

8309960: ParallelGC young collections very slow in DelayInducer

Reviewed-by: tschatzl

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

PR: https://git.openjdk.org/jdk21/pull/22

From ayang at openjdk.org  Mon Jun 19 12:15:18 2023
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Mon, 19 Jun 2023 12:15:18 GMT
Subject: RFR: 8310311: Serial: move Generation::contribute_scratch to
 DefNewGeneration
Message-ID: <z_diblobapSstXhUETu9N7o35XcJO-3GnNwzW_VrAZs=.e909e3f4-0183-4196-91e0-7d2a56e6c655@github.com>

Simple cleanup to move a method from base-class to  sub-class.

Test: hotspot_gc

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

Commit messages:
 - s1-contribute-scratch

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

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

From duke at openjdk.org  Mon Jun 19 14:56:20 2023
From: duke at openjdk.org (Ashutosh Mehra)
Date: Mon, 19 Jun 2023 14:56:20 GMT
Subject: RFR: 8310160: Make GC APIs for handling archive heap objects
 agnostic of GC policy
In-Reply-To: <cBANQnhVoHtOEFWWf0KRoOnD2sdHvv_Wl91Tkeacu7Y=.33e8ad29-2444-4f06-9253-df2e44b18a2c@github.com>
References: <S6B2u9JEc8rz29_HpCadu8vAQaRLqS_8Tj6O57z583w=.e6b981e4-38f8-41eb-8ae6-cf1378ceac10@github.com>
 <cBANQnhVoHtOEFWWf0KRoOnD2sdHvv_Wl91Tkeacu7Y=.33e8ad29-2444-4f06-9253-df2e44b18a2c@github.com>
Message-ID: <mDGUU9agxcxUjcKnlOis1KnaK2gWBmIanWfVJvNMLn8=.d9bf5fbb-a58e-4b08-a5fd-a101c05df6c8@github.com>

On Sat, 17 Jun 2023 17:21:05 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> This PR adds GC APIs to be implemented by all collectors for proper handling of archive heap space. Currently only G1 is updated to use these APIs which just involves renaming the existing G1 APIs.
>> In addition to that filemap.cpp is updated to replace calls to `G1CollectedHeap::heap()` with `Universe::heap()` to avoid G1 specific code as much as possible.
>> 
>> At many places in filemap.cpp heap range is requested from GC. All collectors except ZGC have contiguous heap and set `CollectedHeap::_reserved` to the heap range, so it can be easily exposed to the CDS code. This is done in this patch through `CollectedHeap::reserved` API. But for ZGC the heap can be discontiguous which makes it tricky to expose the heap range.
>> Another point to note is that most of the usage for heap range is for logging purpose, but there is one place where it is used for setting the `mapping_offset` in `FileMapInfo::write_region()` based on the heap start. So purely based on the functional requirement, we only need the heap start address, not the range.
>> 
>> To keep things simple and considering ZGC does not currently support archive heap, i refrained from tackling the issue of discontiguous heap range in this PR.
>
> src/hotspot/share/cds/filemap.cpp line 1570:
> 
>> 1568:       assert((mapping_offset >> CompressedOops::shift()) << CompressedOops::shift() == mapping_offset, "must be");
>> 1569:     } else {
>> 1570:       assert(UseG1GC, "used by G1 only");
> 
> Is this assert needed? If yes, it should be guarding the whole HeapShared::is_heap_region() branch, not just this else branch. OTOH we already assert "HeapShared::can_write()", which is a stronger assert.

Looking at it again, you are right. I don't think we need this assert. I will remove it.

> src/hotspot/share/cds/filemap.cpp line 2097:
> 
>> 2095:     assert(heap_range.contains(_mapped_heap_memregion), "must be");
>> 2096: 
>> 2097:     if (UseG1GC) {
> 
> This condition is odd. We only call FileMapInfo::map_heap_region() for G1, right? Maybe just assert at the start of the function for `ArchiveHeapLoader::can_map()` instead?

I mixed up my thoughts about the future changes where `FileMapInfo::map_heap_region()` could be called for any collector, not just G1. In that scenario the assert that mapped heap region is at the top of the heap would be true only for G1 (among current set of collectors that support archive heap).
Your point is valid. I can just add an assert `ArchiveHeapLoader::can_map()` at the start.

> src/hotspot/share/gc/shared/collectedHeap.hpp line 212:
> 
>> 210:   MemRegion reserved() const {
>> 211:     return _reserved;
>> 212:   }
> 
> PSHeap, GenCollectedHeap and Shenandoah each already expose `_reserved` via `reserved_region()`. Can we remove all of them and rename this to `reserved_region()`?

ok, I will do that.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14520#discussion_r1234169911
PR Review Comment: https://git.openjdk.org/jdk/pull/14520#discussion_r1234170044
PR Review Comment: https://git.openjdk.org/jdk/pull/14520#discussion_r1234171832

From duke at openjdk.org  Mon Jun 19 16:02:09 2023
From: duke at openjdk.org (Ashutosh Mehra)
Date: Mon, 19 Jun 2023 16:02:09 GMT
Subject: RFR: 8310160: Make GC APIs for handling archive heap objects
 agnostic of GC policy
In-Reply-To: <CtKt8-8Wq8od9n6wlsu7InmKa29mP14WlwS0LAPv2p8=.2ec00458-32ab-4220-a150-0165c2283452@github.com>
References: <S6B2u9JEc8rz29_HpCadu8vAQaRLqS_8Tj6O57z583w=.e6b981e4-38f8-41eb-8ae6-cf1378ceac10@github.com>
 <26zbqrmO2QrCQwnPeiyis8Lguzp2qmrof6glLevCaps=.0c965e37-1f53-4351-977b-c0ca51147af4@github.com>
 <CtKt8-8Wq8od9n6wlsu7InmKa29mP14WlwS0LAPv2p8=.2ec00458-32ab-4220-a150-0165c2283452@github.com>
Message-ID: <IVRp9SSxPmDlKsr1niurKJH-aanJMPxDBZik8rWwOQg=.a266c115-a048-409d-9cb2-c25308a36857@github.com>

On Sat, 17 Jun 2023 17:43:51 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> src/hotspot/share/cds/filemap.cpp line 2142:
>> 
>>> 2140:                               r->allow_exec());
>>> 2141:   if (base == nullptr || base != addr) {
>>> 2142:     handle_failed_mapping();
>> 
>> `handle_failed_mapping()` is called for several reasons where we are not able to use the archive heap:
>> - mmap failed for the `hp` or `bm` regions
>> - CRC check failure
>> 
>> So I think the wording of "mapping" is too specific and doesn't cover all cases (and also precludes the possibility of other failures in the future.
>> 
>> Also "handle" could imply a possibility of recovering from the failure, which isn't the case.
>> 
>> I think a more neutral name would be better. Maybe `release_archive_space()` in contrast of `alloc_archive_space` (or even `allocate_archive_space`, as we prefer proper words than short hands).
>
>> I think a more neutral name would be better. Maybe `release_archive_space()` in contrast of `alloc_archive_space` (or even `allocate_archive_space`, as we prefer proper words than short hands).
> 
> "on_load_error"?

To be honest I don't like these names either and am open for suggestions. I liked @tstuefe's [suggestion](https://github.com/openjdk/jdk/pull/14520/files#r1233100361) for `on_cds_post_load` and `on_cds_load_error` but probably name them `on_archive_heap_post_load` and `on_archive_heap_load_error`.
Also in CDS code "load" is currently associated with the mechanism used by non-G1 collecters to read the archive space into the heap memory and "map" is associated with the G1 collector's mechanism to mmap the archive space. For instance FileMapInfo::map_or_load_heap_region.
Going forward I think we would need to get rid of this distinction, at least in public APIs and just use the term "load". Internally the "loading" may be achieved through IO read or mmap-ing the archive space.
@iklam what do you think?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14520#discussion_r1234240366

From duke at openjdk.org  Mon Jun 19 16:02:11 2023
From: duke at openjdk.org (Ashutosh Mehra)
Date: Mon, 19 Jun 2023 16:02:11 GMT
Subject: RFR: 8310160: Make GC APIs for handling archive heap objects
 agnostic of GC policy
In-Reply-To: <26zbqrmO2QrCQwnPeiyis8Lguzp2qmrof6glLevCaps=.0c965e37-1f53-4351-977b-c0ca51147af4@github.com>
References: <S6B2u9JEc8rz29_HpCadu8vAQaRLqS_8Tj6O57z583w=.e6b981e4-38f8-41eb-8ae6-cf1378ceac10@github.com>
 <26zbqrmO2QrCQwnPeiyis8Lguzp2qmrof6glLevCaps=.0c965e37-1f53-4351-977b-c0ca51147af4@github.com>
Message-ID: <eZyc3v4aAtgonVKYeZb16S2EI_hsVHT2AW23LPWYYXU=.4720b690-e188-4a71-871d-e3a4da5f1cae@github.com>

On Sat, 17 Jun 2023 05:08:28 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> This PR adds GC APIs to be implemented by all collectors for proper handling of archive heap space. Currently only G1 is updated to use these APIs which just involves renaming the existing G1 APIs.
>> In addition to that filemap.cpp is updated to replace calls to `G1CollectedHeap::heap()` with `Universe::heap()` to avoid G1 specific code as much as possible.
>> 
>> At many places in filemap.cpp heap range is requested from GC. All collectors except ZGC have contiguous heap and set `CollectedHeap::_reserved` to the heap range, so it can be easily exposed to the CDS code. This is done in this patch through `CollectedHeap::reserved` API. But for ZGC the heap can be discontiguous which makes it tricky to expose the heap range.
>> Another point to note is that most of the usage for heap range is for logging purpose, but there is one place where it is used for setting the `mapping_offset` in `FileMapInfo::write_region()` based on the heap start. So purely based on the functional requirement, we only need the heap start address, not the range.
>> 
>> To keep things simple and considering ZGC does not currently support archive heap, i refrained from tackling the issue of discontiguous heap range in this PR.
>
> src/hotspot/share/cds/filemap.cpp line 2142:
> 
>> 2140:                               r->allow_exec());
>> 2141:   if (base == nullptr || base != addr) {
>> 2142:     handle_failed_mapping();
> 
> `handle_failed_mapping()` is called for several reasons where we are not able to use the archive heap:
> - mmap failed for the `hp` or `bm` regions
> - CRC check failure
> 
> So I think the wording of "mapping" is too specific and doesn't cover all cases (and also precludes the possibility of other failures in the future.
> 
> Also "handle" could imply a possibility of recovering from the failure, which isn't the case.
> 
> I think a more neutral name would be better. Maybe `release_archive_space()` in contrast of `alloc_archive_space` (or even `allocate_archive_space`, as we prefer proper words than short hands).

I will also update `alloc_archive_space` to `allocate_archive_space`. Thanks @iklam for pointing that out.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14520#discussion_r1234241824

From duke at openjdk.org  Mon Jun 19 16:19:48 2023
From: duke at openjdk.org (Ashutosh Mehra)
Date: Mon, 19 Jun 2023 16:19:48 GMT
Subject: RFR: 8310160: Make GC APIs for handling archive heap objects
 agnostic of GC policy
In-Reply-To: <cBANQnhVoHtOEFWWf0KRoOnD2sdHvv_Wl91Tkeacu7Y=.33e8ad29-2444-4f06-9253-df2e44b18a2c@github.com>
References: <S6B2u9JEc8rz29_HpCadu8vAQaRLqS_8Tj6O57z583w=.e6b981e4-38f8-41eb-8ae6-cf1378ceac10@github.com>
 <cBANQnhVoHtOEFWWf0KRoOnD2sdHvv_Wl91Tkeacu7Y=.33e8ad29-2444-4f06-9253-df2e44b18a2c@github.com>
Message-ID: <ki-C8RULBeYdngV3QsWKyf3qWnN-W5ab1jRjgxiFqbY=.bffbaefb-7682-4a53-bfa9-753ce8754851@github.com>

On Sat, 17 Jun 2023 17:39:10 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> This PR adds GC APIs to be implemented by all collectors for proper handling of archive heap space. Currently only G1 is updated to use these APIs which just involves renaming the existing G1 APIs.
>> In addition to that filemap.cpp is updated to replace calls to `G1CollectedHeap::heap()` with `Universe::heap()` to avoid G1 specific code as much as possible.
>> 
>> At many places in filemap.cpp heap range is requested from GC. All collectors except ZGC have contiguous heap and set `CollectedHeap::_reserved` to the heap range, so it can be easily exposed to the CDS code. This is done in this patch through `CollectedHeap::reserved` API. But for ZGC the heap can be discontiguous which makes it tricky to expose the heap range.
>> Another point to note is that most of the usage for heap range is for logging purpose, but there is one place where it is used for setting the `mapping_offset` in `FileMapInfo::write_region()` based on the heap start. So purely based on the functional requirement, we only need the heap start address, not the range.
>> 
>> To keep things simple and considering ZGC does not currently support archive heap, i refrained from tackling the issue of discontiguous heap range in this PR.
>
> src/hotspot/share/gc/shared/collectedHeap.hpp line 536:
> 
>> 534: 
>> 535:   // Handle any failure in loading the CDS archive area.
>> 536:   virtual void handle_archive_space_failure(MemRegion range) { return; }
> 
> For both `fixup_archive_space` and `handle_archive_space_failure`: Why do we need to pass in the MemRegion? The only valid argument in both cases is the MemRegion that had been previously established by a call to `alloc_archive_space`. 
> 
> Why not let CollectedHeap remember the MemRegion established by `alloc_archive_space`, thereby also guaranteeing that `alloc_archive_space` can only be called once, and refer to that in the followup calls?

I don't see any reason why we can't do that. Only reason could be that we need the MemRegion in FileMapInfo as well, so we end up duplicating the MemRegion in CollectedHeap and FileMapInfo. 
But looking at the uses of `_mapped_heap_memregion` in FileMapInfo.cpp I think cds only needs the start address of the archive space in the heap. Size of the region must be same as the used bytes of `MetaspaceShared::hp` region. So we can ideally replace `_mapped_heap_memregion` with something like`_archive_space_load_address`.
@iklam @tschatzl what is your opinion?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14520#discussion_r1234255520

From duke at openjdk.org  Mon Jun 19 20:06:23 2023
From: duke at openjdk.org (Ashutosh Mehra)
Date: Mon, 19 Jun 2023 20:06:23 GMT
Subject: RFR: 8310160: Make GC APIs for handling archive heap objects
 agnostic of GC policy [v2]
In-Reply-To: <S6B2u9JEc8rz29_HpCadu8vAQaRLqS_8Tj6O57z583w=.e6b981e4-38f8-41eb-8ae6-cf1378ceac10@github.com>
References: <S6B2u9JEc8rz29_HpCadu8vAQaRLqS_8Tj6O57z583w=.e6b981e4-38f8-41eb-8ae6-cf1378ceac10@github.com>
Message-ID: <RPL1CUGmVmd-z_RF_jpEXhw2-c791_nImMoCl7bq8js=.7dd14918-d27e-4007-9e7e-cc5e32c2d9f6@github.com>

> This PR adds GC APIs to be implemented by all collectors for proper handling of archive heap space. Currently only G1 is updated to use these APIs which just involves renaming the existing G1 APIs.
> In addition to that filemap.cpp is updated to replace calls to `G1CollectedHeap::heap()` with `Universe::heap()` to avoid G1 specific code as much as possible.
> 
> At many places in filemap.cpp heap range is requested from GC. All collectors except ZGC have contiguous heap and set `CollectedHeap::_reserved` to the heap range, so it can be easily exposed to the CDS code. This is done in this patch through `CollectedHeap::reserved` API. But for ZGC the heap can be discontiguous which makes it tricky to expose the heap range.
> Another point to note is that most of the usage for heap range is for logging purpose, but there is one place where it is used for setting the `mapping_offset` in `FileMapInfo::write_region()` based on the heap start. So purely based on the functional requirement, we only need the heap start address, not the range.
> 
> To keep things simple and considering ZGC does not currently support archive heap, i refrained from tackling the issue of discontiguous heap range in this PR.

Ashutosh Mehra has updated the pull request incrementally with three additional commits since the last revision:

 - Remove unnecessary assert and condition for UseG1GC
   
   Signed-off-by: Ashutosh Mehra <asmehra at redhat.com>
 - Rename CollectedHeap::reserved() to CollectedHeap::reserved_range()
   
   Signed-off-by: Ashutosh Mehra <asmehra at redhat.com>
 - Rename alloc_archive_space to allocate_archive_space
   
   Signed-off-by: Ashutosh Mehra <asmehra at redhat.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14520/files
  - new: https://git.openjdk.org/jdk/pull/14520/files/889da45e..3c35c53d

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

  Stats: 42 lines in 12 files changed: 0 ins; 6 del; 36 mod
  Patch: https://git.openjdk.org/jdk/pull/14520.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14520/head:pull/14520

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

From duke at openjdk.org  Mon Jun 19 20:06:26 2023
From: duke at openjdk.org (Ashutosh Mehra)
Date: Mon, 19 Jun 2023 20:06:26 GMT
Subject: RFR: 8310160: Make GC APIs for handling archive heap objects
 agnostic of GC policy [v2]
In-Reply-To: <mDGUU9agxcxUjcKnlOis1KnaK2gWBmIanWfVJvNMLn8=.d9bf5fbb-a58e-4b08-a5fd-a101c05df6c8@github.com>
References: <S6B2u9JEc8rz29_HpCadu8vAQaRLqS_8Tj6O57z583w=.e6b981e4-38f8-41eb-8ae6-cf1378ceac10@github.com>
 <cBANQnhVoHtOEFWWf0KRoOnD2sdHvv_Wl91Tkeacu7Y=.33e8ad29-2444-4f06-9253-df2e44b18a2c@github.com>
 <mDGUU9agxcxUjcKnlOis1KnaK2gWBmIanWfVJvNMLn8=.d9bf5fbb-a58e-4b08-a5fd-a101c05df6c8@github.com>
Message-ID: <xBfDuDCtxivPdN-M0uLKvvCWd81XUQoAIIEOT6MmURM=.3950d5a6-ced5-44db-a498-2c9d1645c0ce@github.com>

On Mon, 19 Jun 2023 14:52:06 GMT, Ashutosh Mehra <duke at openjdk.org> wrote:

>> src/hotspot/share/cds/filemap.cpp line 2097:
>> 
>>> 2095:     assert(heap_range.contains(_mapped_heap_memregion), "must be");
>>> 2096: 
>>> 2097:     if (UseG1GC) {
>> 
>> This condition is odd. We only call FileMapInfo::map_heap_region() for G1, right? Maybe just assert at the start of the function for `ArchiveHeapLoader::can_map()` instead?
>
> I mixed up my thoughts about the future changes where `FileMapInfo::map_heap_region()` could be called for any collector, not just G1. In that scenario the assert that mapped heap region is at the top of the heap would be true only for G1 (among current set of collectors that support archive heap).
> Your point is valid. I can just add an assert `ArchiveHeapLoader::can_map()` at the start.

On second thought I think there is no need for `ArchiveHeapLoader::can_map()` either. `map_heap_region()` gets called from `FileMapInfo::map_or_load_heap_region` only if `ArchiveHeapLoader::can_map()` is true.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14520#discussion_r1234430769

From ayang at openjdk.org  Tue Jun 20 09:26:06 2023
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Tue, 20 Jun 2023 09:26:06 GMT
Subject: RFR: 8310160: Make GC APIs for handling archive heap objects
 agnostic of GC policy [v2]
In-Reply-To: <RPL1CUGmVmd-z_RF_jpEXhw2-c791_nImMoCl7bq8js=.7dd14918-d27e-4007-9e7e-cc5e32c2d9f6@github.com>
References: <S6B2u9JEc8rz29_HpCadu8vAQaRLqS_8Tj6O57z583w=.e6b981e4-38f8-41eb-8ae6-cf1378ceac10@github.com>
 <RPL1CUGmVmd-z_RF_jpEXhw2-c791_nImMoCl7bq8js=.7dd14918-d27e-4007-9e7e-cc5e32c2d9f6@github.com>
Message-ID: <i4O6pspEWQDDMqWXmkRTFg8gatSE1s1-Hu3uIEZsB8o=.8649426a-cefb-4560-a0c6-e742d2d7dcc3@github.com>

On Mon, 19 Jun 2023 20:06:23 GMT, Ashutosh Mehra <duke at openjdk.org> wrote:

>> This PR adds GC APIs to be implemented by all collectors for proper handling of archive heap space. Currently only G1 is updated to use these APIs which just involves renaming the existing G1 APIs.
>> In addition to that filemap.cpp is updated to replace calls to `G1CollectedHeap::heap()` with `Universe::heap()` to avoid G1 specific code as much as possible.
>> 
>> At many places in filemap.cpp heap range is requested from GC. All collectors except ZGC have contiguous heap and set `CollectedHeap::_reserved` to the heap range, so it can be easily exposed to the CDS code. This is done in this patch through `CollectedHeap::reserved` API. But for ZGC the heap can be discontiguous which makes it tricky to expose the heap range.
>> Another point to note is that most of the usage for heap range is for logging purpose, but there is one place where it is used for setting the `mapping_offset` in `FileMapInfo::write_region()` based on the heap start. So purely based on the functional requirement, we only need the heap start address, not the range.
>> 
>> To keep things simple and considering ZGC does not currently support archive heap, i refrained from tackling the issue of discontiguous heap range in this PR.
>
> Ashutosh Mehra has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Remove unnecessary assert and condition for UseG1GC
>    
>    Signed-off-by: Ashutosh Mehra <asmehra at redhat.com>
>  - Rename CollectedHeap::reserved() to CollectedHeap::reserved_range()
>    
>    Signed-off-by: Ashutosh Mehra <asmehra at redhat.com>
>  - Rename alloc_archive_space to allocate_archive_space
>    
>    Signed-off-by: Ashutosh Mehra <asmehra at redhat.com>

src/hotspot/share/gc/shared/collectedHeap.hpp line 212:

> 210:   MemRegion reserved_region() const {
> 211:     return _reserved;
> 212:   }

Could you extract out this (a new CollectedHeap API) to its own ticket/PR? (It seems important enough to not be hidden inside a CDS PR.)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14520#discussion_r1234991165

From tschatzl at openjdk.org  Tue Jun 20 09:44:04 2023
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Tue, 20 Jun 2023 09:44:04 GMT
Subject: RFR: 8310311: Serial: move Generation::contribute_scratch to
 DefNewGeneration
In-Reply-To: <z_diblobapSstXhUETu9N7o35XcJO-3GnNwzW_VrAZs=.e909e3f4-0183-4196-91e0-7d2a56e6c655@github.com>
References: <z_diblobapSstXhUETu9N7o35XcJO-3GnNwzW_VrAZs=.e909e3f4-0183-4196-91e0-7d2a56e6c655@github.com>
Message-ID: <FY0dKGlc5xNfOHxiwjJ23h0oDPkC5SZOls5qBXzsUDM=.2e203067-d897-470d-aedb-bf0cdeda9022@github.com>

On Mon, 19 Jun 2023 12:08:46 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple cleanup to move a method from base-class to  sub-class.
> 
> Test: hotspot_gc

I think this cleanup should go further than this.

We know that:
* only young gen can provide scratch
* it is a single scratch space
* the code only ever uses a single scratch space  (see comment in `GenMarkSweep::allocate_stacks`)
* there are only DefNewGeneration and TenuredGeneration anyway (and the framework wouldn't work with an additional intermediate generation too).

So `GenMarkSweep::allocate_stacks` should ask the young gen directly for scratch space (if `GenCollectedHeap::young_gen()` returned a `DefNewGeneration` right away; all callers of that method immediately cast it to `DefNewGeneration` anyway).
This also removes the need for some helpers for the scratch space, like sorting the list (which is always very degenerate anyway).

Kind of useless assertions and comments (in `DefNewGeneration::contribute_scratch`) should be removed.

This change should imho also remove obsolete comments (with "$$$") in the vicinity.

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

PR Review: https://git.openjdk.org/jdk/pull/14540#pullrequestreview-1487741747

From tschatzl at openjdk.org  Tue Jun 20 09:49:14 2023
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Tue, 20 Jun 2023 09:49:14 GMT
Subject: RFR: 8219357: G1: G1GCPhaseTimes::debug_phase uses unnecessary
 ResourceMark
In-Reply-To: <YMmswXyrwEKmFwJ5lbzTLeJHgDaDmXQQAhaakFyRCa8=.37cd0632-e708-4ee3-ac2f-30c0e654c838@github.com>
References: <_VX8z68nagpqV5vSaaHQ43A5soD3aZB1SFR_FRAaRos=.11fb1011-407d-4679-af6b-dadcd6898390@github.com>
 <YMmswXyrwEKmFwJ5lbzTLeJHgDaDmXQQAhaakFyRCa8=.37cd0632-e708-4ee3-ac2f-30c0e654c838@github.com>
Message-ID: <SmtjPKPK0sMQyf5yXA5bJ9TM4zLBJJKmN2u6wohnVAo=.1a32637c-d4fd-425f-8009-0afc494a1b26@github.com>

On Fri, 16 Jun 2023 10:13:25 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Hi all,
>> 
>>   please review this removal of an unnecessary `ResourceMark`.
>> 
>> Testing: local compilation, gha
>> 
>> Thanks,
>>   Thomas
>
> Looks okay, just from the symmetry with `trace_phase` below.

Thanks @shipilev @albertnetymk for your reviews

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

PR Comment: https://git.openjdk.org/jdk/pull/14512#issuecomment-1598460111

From tschatzl at openjdk.org  Tue Jun 20 09:49:16 2023
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Tue, 20 Jun 2023 09:49:16 GMT
Subject: Integrated: 8219357: G1: G1GCPhaseTimes::debug_phase uses unnecessary
 ResourceMark
In-Reply-To: <_VX8z68nagpqV5vSaaHQ43A5soD3aZB1SFR_FRAaRos=.11fb1011-407d-4679-af6b-dadcd6898390@github.com>
References: <_VX8z68nagpqV5vSaaHQ43A5soD3aZB1SFR_FRAaRos=.11fb1011-407d-4679-af6b-dadcd6898390@github.com>
Message-ID: <_g3GxKhnRr1a2ge6vmgD6BXHoSYw9p2GQb5euDAEKgo=.1df69c5d-0549-4a92-b152-3e8412aed3d8@github.com>

On Fri, 16 Jun 2023 09:35:12 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   please review this removal of an unnecessary `ResourceMark`.
> 
> Testing: local compilation, gha
> 
> Thanks,
>   Thomas

This pull request has now been integrated.

Changeset: 9a68ec8b
Author:    Thomas Schatzl <tschatzl at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/9a68ec8bb2116cd166732cc1208cb19b6cd6a64d
Stats:     1 line in 1 file changed: 0 ins; 1 del; 0 mod

8219357: G1: G1GCPhaseTimes::debug_phase uses unnecessary ResourceMark

Reviewed-by: shade, ayang

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

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

From ayang at openjdk.org  Tue Jun 20 09:59:35 2023
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Tue, 20 Jun 2023 09:59:35 GMT
Subject: RFR: 8310354: G1: Annotate G1MMUTracker::when_sec with const
Message-ID: <8m9-PL-wJR35jrDel3faUh5JTcLWqZqW-6bVytOYvU4=.2bf87dec-7067-410e-bb16-70ad32aeed37@github.com>

Simply adding `const` to G1MMUTracker APIs.

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

Commit messages:
 - g1-mmu-const

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

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

From ayang at openjdk.org  Tue Jun 20 10:03:05 2023
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Tue, 20 Jun 2023 10:03:05 GMT
Subject: RFR: 8310311: Serial: move Generation::contribute_scratch to
 DefNewGeneration
In-Reply-To: <FY0dKGlc5xNfOHxiwjJ23h0oDPkC5SZOls5qBXzsUDM=.2e203067-d897-470d-aedb-bf0cdeda9022@github.com>
References: <z_diblobapSstXhUETu9N7o35XcJO-3GnNwzW_VrAZs=.e909e3f4-0183-4196-91e0-7d2a56e6c655@github.com>
 <FY0dKGlc5xNfOHxiwjJ23h0oDPkC5SZOls5qBXzsUDM=.2e203067-d897-470d-aedb-bf0cdeda9022@github.com>
Message-ID: <IyqztU_UYx9khnBpdxz9lQDPQJQ6scowbcv64bac0O4=.e4a8d417-982a-406f-9194-f31270136409@github.com>

On Tue, 20 Jun 2023 09:41:20 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> if GenCollectedHeap::young_gen() returned a DefNewGeneration right away;

I tried that but it affects too much other code, so I went with the current approach.

> This also removes the need for some helpers for the scratch space, like sorting the list (which is always very degenerate anyway).

I was planning to do that in a followup PR. The current PR is mostly a structural-change affecting both young & old-gen, while further cleanup is specific to young-gen, so I decided to not merge them into one PR.

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

PR Comment: https://git.openjdk.org/jdk/pull/14540#issuecomment-1598479994

From rkennke at openjdk.org  Tue Jun 20 11:38:50 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Tue, 20 Jun 2023 11:38:50 GMT
Subject: RFR: 8305896: Alternative full GC forwarding [v49]
In-Reply-To: <yFs73BPFgB89xCPY4k63X4VTz13N8ELJf1lGQlE6UpA=.85ee4f25-a4ee-41d0-b4c2-ed9ff2cb1bb1@github.com>
References: <yFs73BPFgB89xCPY4k63X4VTz13N8ELJf1lGQlE6UpA=.85ee4f25-a4ee-41d0-b4c2-ed9ff2cb1bb1@github.com>
Message-ID: <z_o1jyxUZxga-Cv1DeB_UV8kvX72CuOuivjzcN7ZB7Q=.47eb1e88-4bc7-458e-a155-72936d2d36f4@github.com>

> Currently, the full-GC modes of Serial, Shenandoah and G1 GCs are forwarding objects by over-writing the object header with the new object location. Unfortunately, for compact object headers ([JDK-8294992](https://bugs.openjdk.org/browse/JDK-8294992)) this would not work, because the crucial class information is also stored in the header, and we could no longer iterate over objects until the headers would be restored. Also, the preserved-headers tables would grow quite large.
> 
> I propose to use an alternative algorithm for full-GC (sliding-GC) forwarding that uses a special encoding so that the forwarding information fits into the lowest 32 bits of the header.
> 
> It exploits the insight that, with sliding GCs, objects from one region will only ever be forwarded to one of two possible target regions. For this to work, we need to divide the heap into equal-sized regions. This is already the case for Shenandoah and G1, and can easily be overlaid for Serial GC, by assuming either the whole heap as a single region (if it fits) or by using SpaceAlignment-sized virtual regions.
> 
> We also build and maintain a table that has N elements, where N is the number of regions. Each entry is two addresses, which are the start-address of the possible target regions for each source region.
> 
> With this, forwarding information would be encoded like this:
>  - Bits 0 and 1: same as before, we put in '11' to indicate that the object is forwarded.
>  - Bit 2: Used for 'fallback'-forwarding (see below)
>  - Bit 3: Selects the target region 0 or 1. Look up the base address in the table (see above)
>  - Bits 4..31 The number of heap words from the target base address
> 
> This works well for all sliding GCs in Serial, G1 and Shenandoah. The exception is in G1, there is a special mode called 'serial compaction' which acts as a last-last-ditch effort to squeeze more space out of the heap by re-forwarding the tails of the compaction chains. Unfortunately, this breaks the assumption of the sliding-forwarding-table. When that happens, we initialize a fallback table, which is a simple open hash-table, and set the Bit 2 in the forwarding to indicate that we shall look up the forwardee in the fallback-table.
> 
> All the table accesses can be done unsynchronized because:
> - Serial GC is single-threaded anyway
> - In G1 and Shenandoah, GC worker threads divide up the work such that each worker does disjoint sets of regions.
> - G1 serial compaction is single-threaded
> 
> The change introduces a new (experimental) flag -...

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

  Some @shipilev comments from downstream review

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13582/files
  - new: https://git.openjdk.org/jdk/pull/13582/files/524f9c52..01fc573f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13582&range=48
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13582&range=47-48

  Stats: 339 lines in 22 files changed: 130 ins; 149 del; 60 mod
  Patch: https://git.openjdk.org/jdk/pull/13582.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13582/head:pull/13582

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

From stefank at openjdk.org  Tue Jun 20 13:47:05 2023
From: stefank at openjdk.org (Stefan Karlsson)
Date: Tue, 20 Jun 2023 13:47:05 GMT
Subject: RFR: 8310194: Generational ZGC: Lock-order asserts in JVMTI
 IterateThroughHeap
In-Reply-To: <JFgqaXsFv8JyuOzQuXC3sioAeiGTZxTiw-4gnX-j6Ok=.6a2ceeb4-b304-46cb-be4e-9816beeb7d6a@github.com>
References: <JFgqaXsFv8JyuOzQuXC3sioAeiGTZxTiw-4gnX-j6Ok=.6a2ceeb4-b304-46cb-be4e-9816beeb7d6a@github.com>
Message-ID: <mY-Xje3zO4_r27pB508TxxV5g78fvaXnSOvxOr5-85o=.b0ca6eae-1809-4df1-bcaa-f50b3526f13c@github.com>

On Fri, 16 Jun 2023 11:52:51 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> Generational ZGC changed the location where the heap object iterator called the visit function. It used to be called when the objects were popped and then followed, but it was changed so that the function where called immediately when the objects are marked. This gave the benefit that the verification code code show exactly what root had a broken object. Unfortunately, this change started to apply non-GC closure during the root iteration. This could lead to lock order issues, just like the one described in the JBS entry.
> 
> This fix moves the visit calls for non-GC closures back to the follow calls.

Thanks for reviewing!

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

PR Comment: https://git.openjdk.org/jdk/pull/14518#issuecomment-1598821180

From stefank at openjdk.org  Tue Jun 20 13:50:12 2023
From: stefank at openjdk.org (Stefan Karlsson)
Date: Tue, 20 Jun 2023 13:50:12 GMT
Subject: Integrated: 8310194: Generational ZGC: Lock-order asserts in JVMTI
 IterateThroughHeap
In-Reply-To: <JFgqaXsFv8JyuOzQuXC3sioAeiGTZxTiw-4gnX-j6Ok=.6a2ceeb4-b304-46cb-be4e-9816beeb7d6a@github.com>
References: <JFgqaXsFv8JyuOzQuXC3sioAeiGTZxTiw-4gnX-j6Ok=.6a2ceeb4-b304-46cb-be4e-9816beeb7d6a@github.com>
Message-ID: <YUpS6Ty9EH1ORz6lAZJqlb9vUUEA7vZUZ6aoCpEEqKo=.b97e41f3-108c-4514-9900-f6a112717743@github.com>

On Fri, 16 Jun 2023 11:52:51 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> Generational ZGC changed the location where the heap object iterator called the visit function. It used to be called when the objects were popped and then followed, but it was changed so that the function where called immediately when the objects are marked. This gave the benefit that the verification code code show exactly what root had a broken object. Unfortunately, this change started to apply non-GC closure during the root iteration. This could lead to lock order issues, just like the one described in the JBS entry.
> 
> This fix moves the visit calls for non-GC closures back to the follow calls.

This pull request has now been integrated.

Changeset: 4e4e586d
Author:    Stefan Karlsson <stefank at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4e4e586dac3f4be15a6488a6b72aa9e2cd5d43db
Stats:     203 lines in 5 files changed: 103 ins; 37 del; 63 mod

8310194: Generational ZGC: Lock-order asserts in JVMTI IterateThroughHeap

Reviewed-by: eosterlund, aboldtch

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

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

From duke at openjdk.org  Tue Jun 20 15:02:06 2023
From: duke at openjdk.org (Ashutosh Mehra)
Date: Tue, 20 Jun 2023 15:02:06 GMT
Subject: RFR: 8310160: Make GC APIs for handling archive heap objects
 agnostic of GC policy [v2]
In-Reply-To: <i4O6pspEWQDDMqWXmkRTFg8gatSE1s1-Hu3uIEZsB8o=.8649426a-cefb-4560-a0c6-e742d2d7dcc3@github.com>
References: <S6B2u9JEc8rz29_HpCadu8vAQaRLqS_8Tj6O57z583w=.e6b981e4-38f8-41eb-8ae6-cf1378ceac10@github.com>
 <RPL1CUGmVmd-z_RF_jpEXhw2-c791_nImMoCl7bq8js=.7dd14918-d27e-4007-9e7e-cc5e32c2d9f6@github.com>
 <i4O6pspEWQDDMqWXmkRTFg8gatSE1s1-Hu3uIEZsB8o=.8649426a-cefb-4560-a0c6-e742d2d7dcc3@github.com>
Message-ID: <oBCh7xXPyuN_BljsQ01QX1GCS1fMzKDCZaFWV-JgXP0=.00c6f66e-05c6-4469-bedf-e74479a0da29@github.com>

On Tue, 20 Jun 2023 09:22:46 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Ashutosh Mehra has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - Remove unnecessary assert and condition for UseG1GC
>>    
>>    Signed-off-by: Ashutosh Mehra <asmehra at redhat.com>
>>  - Rename CollectedHeap::reserved() to CollectedHeap::reserved_range()
>>    
>>    Signed-off-by: Ashutosh Mehra <asmehra at redhat.com>
>>  - Rename alloc_archive_space to allocate_archive_space
>>    
>>    Signed-off-by: Ashutosh Mehra <asmehra at redhat.com>
>
> src/hotspot/share/gc/shared/collectedHeap.hpp line 212:
> 
>> 210:   MemRegion reserved_region() const {
>> 211:     return _reserved;
>> 212:   }
> 
> Could you extract out this (a new CollectedHeap API) to its own ticket/PR? (It seems important enough to not be hidden inside a CDS PR.)

Sure. I will open an issue and PR for this.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14520#discussion_r1235401957

From stuefe at openjdk.org  Tue Jun 20 15:05:45 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Tue, 20 Jun 2023 15:05:45 GMT
Subject: RFR: JDK-8310111: Shenandoah wastes memory when running with very
 large page sizes
Message-ID: <g2vZQuNNbJJoSTc2tE8nZhcLf0muaoZLnkuKZEzHoZQ=.88748998-31db-44bb-a45f-d75e46a4247e@github.com>

This proposal changes the reservation of bitmaps and region storage to reduce the wastage associated with running with very large page sizes (e.g. 1GB on x64, 512M on arm64) for both non-THP- and THP-mode.

This patch does:
- introducing the notion of "allowed overdraft factor" - allocations for a given page size are rejected if they would cause more wastage than the factor allows
- if it makes sense, it places mark- and aux-bitmap into a contiguous region to let them share a ginourmous page. E.g. for a heap of 16G, both bitmaps would now share a single GB page.

Examples:

Note: annoyingly, huge page usage does not show up in RSS. I therefore use a script that parses /proc/pid/smaps and counts hugepage usage to count cost for the following examples:

Example 1:

A machine configured with 1G pages (and nothing else). Heap is allocated with 1G pages, the bitmaps fall back to 4K pages because JVM figures 1GB would be wasted:


thomas at starfish$ ./images/jdk/bin/java -Xmx4600m -Xlog:pagesize -XX:+UseShenandoahGC -XX:+UseLargePages
...
[0.028s][info][pagesize] Mark Bitmap: req_size=160M req_page_size=4K base=0x00007f8149fff000 size=160M page_size=4K
[0.028s][info][pagesize] Aux Bitmap: req_size=160M req_page_size=4K base=0x00007f813fffe000 size=160M page_size=4K
[0.028s][info][pagesize] Region Storage: req_size=320K req_page_size=4K base=0x00007f817c06f000 size=320K page_size=4K


Cost before: 8GB. Cost now: 5GB + (2*160M)

Example 2: JVM with 14GB heap: mark and aux bitmap together are large enough to justify another 1G page, so they share it. Notice how we also place the region storage on this page:


thomas at starfish:/shared/projects/openjdk/jdk-jdk/output-release$ ./images/jdk/bin/java -Xmx14g -Xlog:pagesize 
-XX:+UseShenandoahGC -XX:+UseLargePages -cp $REPROS_JAR de.stuefe.repros.Simple
[0.003s][info][pagesize] Heap: req_size=14G req_page_size=1G base=0x0000000480000000 size=14G page_size=1G
[0.003s][info][pagesize] Mark+Aux Bitmap: req_size=896M req_page_size=1G base=0x00007fee00000000 size=1G page_size=1G
[0.003s][info][pagesize] Region Storage: piggy-backing on Mark Bitmap: base=0x00007fee38000000 size=1792
<press key>


Cost before: 17GB. Cost now: 15GB.

>From a bang-for-hugepages-buck multiples of 16GB are a sweet spot here since (on x64 with 1GB pages) since this allows us to put both 512m bitmaps onto a single huge page.

-----------

No test yet, since I wanted to see if people reject this proposal. It does add a bit of complexity. If this is well-received, I'll do some tests.

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

Commit messages:
 - Cowabunga
 - wipwopwip
 - wipwip
 - wip
 - wip
 - start
 - JDK-8310110-Trace-page-sizes

Changes: https://git.openjdk.org/jdk/pull/14559/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14559&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8310111
  Stats: 386 lines in 5 files changed: 327 ins; 27 del; 32 mod
  Patch: https://git.openjdk.org/jdk/pull/14559.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14559/head:pull/14559

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

From stuefe at openjdk.org  Tue Jun 20 15:21:24 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Tue, 20 Jun 2023 15:21:24 GMT
Subject: RFR: JDK-8310111: Shenandoah wastes memory when running with very
 large page sizes [v2]
In-Reply-To: <g2vZQuNNbJJoSTc2tE8nZhcLf0muaoZLnkuKZEzHoZQ=.88748998-31db-44bb-a45f-d75e46a4247e@github.com>
References: <g2vZQuNNbJJoSTc2tE8nZhcLf0muaoZLnkuKZEzHoZQ=.88748998-31db-44bb-a45f-d75e46a4247e@github.com>
Message-ID: <duqC-dtC4Y4EmWO9lT2BcxzKNwQRpR_jgAXGfQmvPts=.2a77f87b-dbad-4466-bc65-76fa87603717@github.com>

> This proposal changes the reservation of bitmaps and region storage to reduce the wastage associated with running with very large page sizes (e.g. 1GB on x64, 512M on arm64) for both non-THP- and THP-mode.
> 
> This patch does:
> - introducing the notion of "allowed overdraft factor" - allocations for a given page size are rejected if they would cause more wastage than the factor allows
> - if it makes sense, it places mark- and aux-bitmap into a contiguous region to let them share a ginourmous page. E.g. for a heap of 16G, both bitmaps would now share a single GB page.
> 
> Examples:
> 
> Note: annoyingly, huge page usage does not show up in RSS. I therefore use a script that parses /proc/pid/smaps and counts hugepage usage to count cost for the following examples:
> 
> Example 1:
> 
> A machine configured with 1G pages (and nothing else). Heap is allocated with 1G pages, the bitmaps fall back to 4K pages because JVM figures 1GB would be wasted:
> 
> 
> thomas at starfish$ ./images/jdk/bin/java -Xmx4600m -Xlog:pagesize -XX:+UseShenandoahGC -XX:+UseLargePages
> ...
> [0.028s][info][pagesize] Mark Bitmap: req_size=160M req_page_size=4K base=0x00007f8149fff000 size=160M page_size=4K
> [0.028s][info][pagesize] Aux Bitmap: req_size=160M req_page_size=4K base=0x00007f813fffe000 size=160M page_size=4K
> [0.028s][info][pagesize] Region Storage: req_size=320K req_page_size=4K base=0x00007f817c06f000 size=320K page_size=4K
> 
> 
> Cost before: 8GB. Cost now: 5GB + (2*160M)
> 
> Example 2: JVM with 14GB heap: mark and aux bitmap together are large enough to justify another 1G page, so they share it. Notice how we also place the region storage on this page:
> 
> 
> thomas at starfish:/shared/projects/openjdk/jdk-jdk/output-release$ ./images/jdk/bin/java -Xmx14g -Xlog:pagesize 
> -XX:+UseShenandoahGC -XX:+UseLargePages -cp $REPROS_JAR de.stuefe.repros.Simple
> [0.003s][info][pagesize] Heap: req_size=14G req_page_size=1G base=0x0000000480000000 size=14G page_size=1G
> [0.003s][info][pagesize] Mark+Aux Bitmap: req_size=896M req_page_size=1G base=0x00007fee00000000 size=1G page_size=1G
> [0.003s][info][pagesize] Region Storage: piggy-backing on Mark Bitmap: base=0x00007fee38000000 size=1792
> <press key>
> 
> 
> Cost before: 17GB. Cost now: 15GB.
> 
> From a bang-for-hugepages-buck multiples of 16GB are a sweet spot here since (on x64 with 1GB pages) since this allows us to put both 512m bitmaps onto a single huge page.
> 
> -----------
> 
> No test yet, since I wanted to see if people reject this proposal. It does add a bit of complexity. If this is well-r...

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

  start

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14559/files
  - new: https://git.openjdk.org/jdk/pull/14559/files/e183a935..525cee1c

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

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

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

From eosterlund at openjdk.org  Tue Jun 20 15:59:45 2023
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Tue, 20 Jun 2023 15:59:45 GMT
Subject: RFR: 8310160: Make GC APIs for handling archive heap objects
 agnostic of GC policy [v2]
In-Reply-To: <RPL1CUGmVmd-z_RF_jpEXhw2-c791_nImMoCl7bq8js=.7dd14918-d27e-4007-9e7e-cc5e32c2d9f6@github.com>
References: <S6B2u9JEc8rz29_HpCadu8vAQaRLqS_8Tj6O57z583w=.e6b981e4-38f8-41eb-8ae6-cf1378ceac10@github.com>
 <RPL1CUGmVmd-z_RF_jpEXhw2-c791_nImMoCl7bq8js=.7dd14918-d27e-4007-9e7e-cc5e32c2d9f6@github.com>
Message-ID: <K5TDkiSBRzpPcce5R2W59kp00leDC24TCEyOf6cJWDw=.09e6e7da-6f16-4487-bd12-3294f58dd6d9@github.com>

On Mon, 19 Jun 2023 20:06:23 GMT, Ashutosh Mehra <duke at openjdk.org> wrote:

>> This PR adds GC APIs to be implemented by all collectors for proper handling of archive heap space. Currently only G1 is updated to use these APIs which just involves renaming the existing G1 APIs.
>> In addition to that filemap.cpp is updated to replace calls to `G1CollectedHeap::heap()` with `Universe::heap()` to avoid G1 specific code as much as possible.
>> 
>> At many places in filemap.cpp heap range is requested from GC. All collectors except ZGC have contiguous heap and set `CollectedHeap::_reserved` to the heap range, so it can be easily exposed to the CDS code. This is done in this patch through `CollectedHeap::reserved` API. But for ZGC the heap can be discontiguous which makes it tricky to expose the heap range.
>> Another point to note is that most of the usage for heap range is for logging purpose, but there is one place where it is used for setting the `mapping_offset` in `FileMapInfo::write_region()` based on the heap start. So purely based on the functional requirement, we only need the heap start address, not the range.
>> 
>> To keep things simple and considering ZGC does not currently support archive heap, i refrained from tackling the issue of discontiguous heap range in this PR.
>
> Ashutosh Mehra has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Remove unnecessary assert and condition for UseG1GC
>    
>    Signed-off-by: Ashutosh Mehra <asmehra at redhat.com>
>  - Rename CollectedHeap::reserved() to CollectedHeap::reserved_range()
>    
>    Signed-off-by: Ashutosh Mehra <asmehra at redhat.com>
>  - Rename alloc_archive_space to allocate_archive_space
>    
>    Signed-off-by: Ashutosh Mehra <asmehra at redhat.com>

It's a bit disappointing for a PR aiming to make heap archiving GC agnostic, to make assumptions about GC internal memory layout, that doesn't apply to all collectors.
We have discussed previously with @iklam an approach where materializing archived objects uses the normal object allocation APIs. That would for real make the heap archiving mechanism GC agnostic. I would rather see that being prototyped, than a not GC agnostic approach that we might throw away right after it gets integrated, in favour of the more GC agnostic approach.

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

Changes requested by eosterlund (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14520#pullrequestreview-1488493149

From iklam at openjdk.org  Tue Jun 20 16:36:11 2023
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 20 Jun 2023 16:36:11 GMT
Subject: RFR: 8310160: Make GC APIs for handling archive heap objects
 agnostic of GC policy [v2]
In-Reply-To: <K5TDkiSBRzpPcce5R2W59kp00leDC24TCEyOf6cJWDw=.09e6e7da-6f16-4487-bd12-3294f58dd6d9@github.com>
References: <S6B2u9JEc8rz29_HpCadu8vAQaRLqS_8Tj6O57z583w=.e6b981e4-38f8-41eb-8ae6-cf1378ceac10@github.com>
 <RPL1CUGmVmd-z_RF_jpEXhw2-c791_nImMoCl7bq8js=.7dd14918-d27e-4007-9e7e-cc5e32c2d9f6@github.com>
 <K5TDkiSBRzpPcce5R2W59kp00leDC24TCEyOf6cJWDw=.09e6e7da-6f16-4487-bd12-3294f58dd6d9@github.com>
Message-ID: <n_PSgRcTGiRx3vV9kisky9gCe0YgBIDcdLhlpfVjaEc=.6ee5d368-809e-4692-8f2a-21ab7bd6face@github.com>

On Tue, 20 Jun 2023 15:56:57 GMT, Erik ?sterlund <eosterlund at openjdk.org> wrote:

> It's a bit disappointing for a PR aiming to make heap archiving GC agnostic, to make assumptions about GC internal memory layout, that doesn't apply to all collectors. We have discussed previously with @iklam an approach where materializing archived objects uses the normal object allocation APIs. That would for real make the heap archiving mechanism GC agnostic. I would rather see that being prototyped, than a not GC agnostic approach that we might throw away right after it gets integrated, in favour of the more GC agnostic approach.

There are a few problems with using the regular heap allocation API to reserve space for the archived objects:

- On G1, if the required (contiguous) space is larger than a single G1 region, it will end up inside a huge region
- If we instead attempt to allocate several blocks, each the size of a regular G1 region, there's no guarantee that these blocks would be contiguous. Fixing the pointers across discontiguous blocks would be messy
- We could allocate one block for each individual archived object. This will be most portable across GCs, but the pointer relocation will be slow. (Also, we have to handle the possibility of collecting in the middle of allocating these blocks)
- If we allocate one or multiple larger blocks, and fill them with the archived objects, we still need a per-GC specific way to fix-up these blocks at the very end. This is what we are doing today with Serial and Parallel:
    - https://github.com/openjdk/jdk/commit/6a573b888d4d3322b9165562f85e1b7b781a5ff1#diff-d53bf148d2758636cb8c6a54595515610a4c52d953e23e7bfdeef1106c14f626
    - https://github.com/openjdk/jdk/commit/234c17e8ff7b9b9713e9fded693381f985d34d2a#diff-b8bae64d029923161d88b761e6b775454924218e5f27f30130610da56d0bbefd

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

PR Comment: https://git.openjdk.org/jdk/pull/14520#issuecomment-1599129994

From iklam at openjdk.org  Tue Jun 20 16:56:06 2023
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 20 Jun 2023 16:56:06 GMT
Subject: RFR: 8310160: Make GC APIs for handling archive heap objects
 agnostic of GC policy [v2]
In-Reply-To: <n_PSgRcTGiRx3vV9kisky9gCe0YgBIDcdLhlpfVjaEc=.6ee5d368-809e-4692-8f2a-21ab7bd6face@github.com>
References: <S6B2u9JEc8rz29_HpCadu8vAQaRLqS_8Tj6O57z583w=.e6b981e4-38f8-41eb-8ae6-cf1378ceac10@github.com>
 <RPL1CUGmVmd-z_RF_jpEXhw2-c791_nImMoCl7bq8js=.7dd14918-d27e-4007-9e7e-cc5e32c2d9f6@github.com>
 <K5TDkiSBRzpPcce5R2W59kp00leDC24TCEyOf6cJWDw=.09e6e7da-6f16-4487-bd12-3294f58dd6d9@github.com>
 <n_PSgRcTGiRx3vV9kisky9gCe0YgBIDcdLhlpfVjaEc=.6ee5d368-809e-4692-8f2a-21ab7bd6face@github.com>
Message-ID: <4v0K9F4sNnyo2wH1A_NZsK2CaOt5X9o6dZDPjCZOsj0=.fe23718a-d00e-4fa7-a821-05e946b770f6@github.com>

On Tue, 20 Jun 2023 16:33:16 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> It's a bit disappointing for a PR aiming to make heap archiving GC agnostic, to make assumptions about GC internal memory layout, that doesn't apply to all collectors.
>> We have discussed previously with @iklam an approach where materializing archived objects uses the normal object allocation APIs. That would for real make the heap archiving mechanism GC agnostic. I would rather see that being prototyped, than a not GC agnostic approach that we might throw away right after it gets integrated, in favour of the more GC agnostic approach.
>
>> It's a bit disappointing for a PR aiming to make heap archiving GC agnostic, to make assumptions about GC internal memory layout, that doesn't apply to all collectors. We have discussed previously with @iklam an approach where materializing archived objects uses the normal object allocation APIs. That would for real make the heap archiving mechanism GC agnostic. I would rather see that being prototyped, than a not GC agnostic approach that we might throw away right after it gets integrated, in favour of the more GC agnostic approach.
> 
> There are a few problems with using the regular heap allocation API to reserve space for the archived objects:
> 
> - On G1, if the required (contiguous) space is larger than a single G1 region, it will end up inside a huge region
> - If we instead attempt to allocate several blocks, each the size of a regular G1 region, there's no guarantee that these blocks would be contiguous. Fixing the pointers across discontiguous blocks would be messy
> - We could allocate one block for each individual archived object. This will be most portable across GCs, but the pointer relocation will be slow. (Also, we have to handle the possibility of collecting in the middle of allocating these blocks)
> - If we allocate one or multiple larger blocks, and fill them with the archived objects, we still need a per-GC specific way to fix-up these blocks at the very end. This is what we are doing today with Serial and Parallel:
>     - https://github.com/openjdk/jdk/commit/6a573b888d4d3322b9165562f85e1b7b781a5ff1#diff-d53bf148d2758636cb8c6a54595515610a4c52d953e23e7bfdeef1106c14f626
>     - https://github.com/openjdk/jdk/commit/234c17e8ff7b9b9713e9fded693381f985d34d2a#diff-b8bae64d029923161d88b761e6b775454924218e5f27f30130610da56d0bbefd

> > It's a bit disappointing for a PR aiming to make heap archiving GC agnostic, to make assumptions about GC internal memory layout, that doesn't apply to all collectors. We have discussed previously with @iklam an approach where materializing archived objects uses the normal object allocation APIs. That would for real make the heap archiving mechanism GC agnostic. I would rather see that being prototyped, than a not GC agnostic approach that we might throw away right after it gets integrated, in favour of the more GC agnostic approach.
> 
> There are a few problems with using the regular heap allocation API to reserve space for the archived objects:
> 
> * On G1, if the required (contiguous) space is larger than a single G1 region, it will end up inside a huge region
> * If we instead attempt to allocate several blocks, each the size of a regular G1 region, there's no guarantee that these blocks would be contiguous. Fixing the pointers across discontiguous blocks would be messy
> * We could allocate one block for each individual archived object. This will be most portable across GCs, but the pointer relocation will be slow. (Also, we have to handle the possibility of collecting in the middle of allocating these blocks)
> * If we allocate one or multiple larger blocks, and fill them with the archived objects, we still need a per-GC specific way to fix-up these blocks at the very end. This is what we are doing today with Serial and Parallel:
>   
>   * [6a573b8#diff-d53bf148d2758636cb8c6a54595515610a4c52d953e23e7bfdeef1106c14f626](https://github.com/openjdk/jdk/commit/6a573b888d4d3322b9165562f85e1b7b781a5ff1#diff-d53bf148d2758636cb8c6a54595515610a4c52d953e23e7bfdeef1106c14f626)
>   * [234c17e#diff-b8bae64d029923161d88b761e6b775454924218e5f27f30130610da56d0bbefd](https://github.com/openjdk/jdk/commit/234c17e8ff7b9b9713e9fded693381f985d34d2a#diff-b8bae64d029923161d88b761e6b775454924218e5f27f30130610da56d0bbefd)

In the future, the Leyden project may prefer to have a "permanent" section of the archived objects that are never collected/moved. That would require more collector-specific code.

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

PR Comment: https://git.openjdk.org/jdk/pull/14520#issuecomment-1599161985

From zgu at openjdk.org  Tue Jun 20 19:43:12 2023
From: zgu at openjdk.org (Zhengyu Gu)
Date: Tue, 20 Jun 2023 19:43:12 GMT
Subject: RFR: 8310037: Parallel/Serial: Space Counters classes leak helper
 instances [v2]
In-Reply-To: <v5EM3GD2Dbf460iEoOuM2UpMaYPMKGyylAR5VTbmQUc=.8e49c33b-50d3-45ca-8073-c0fe1a4f1adb@github.com>
References: <HZhfPsRC9Imnoeyr5oQFxRTy9YkvMHqizuGTws83IeY=.710793c8-c2b5-4a72-b8b8-7d2e56c8123f@github.com>
 <v5EM3GD2Dbf460iEoOuM2UpMaYPMKGyylAR5VTbmQUc=.8e49c33b-50d3-45ca-8073-c0fe1a4f1adb@github.com>
Message-ID: <36iRHxNc4wyrR1yrSayxlxUqJCfW7-pMZ5zqEZppH9k=.9857bccb-d502-4d30-afcb-07fd5868ded9@github.com>

On Thu, 15 Jun 2023 14:26:25 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

>> Please review this small fix for memory leak.
>
> Zhengyu Gu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   tschatzl's suggestion

Since we never deallocate counters, there is no point to fix this.

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

PR Comment: https://git.openjdk.org/jdk/pull/14472#issuecomment-1599398579

From zgu at openjdk.org  Tue Jun 20 19:43:13 2023
From: zgu at openjdk.org (Zhengyu Gu)
Date: Tue, 20 Jun 2023 19:43:13 GMT
Subject: Withdrawn: 8310037: Parallel/Serial: Space Counters classes leak
 helper instances
In-Reply-To: <HZhfPsRC9Imnoeyr5oQFxRTy9YkvMHqizuGTws83IeY=.710793c8-c2b5-4a72-b8b8-7d2e56c8123f@github.com>
References: <HZhfPsRC9Imnoeyr5oQFxRTy9YkvMHqizuGTws83IeY=.710793c8-c2b5-4a72-b8b8-7d2e56c8123f@github.com>
Message-ID: <pYeMXnu7GB7hLhTD5EbRmxxKKdknsUdM2jFTMdxHg7s=.49088d8c-461e-419e-877c-72dc79e9c092@github.com>

On Wed, 14 Jun 2023 16:14:15 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> Please review this small fix for memory leak.

This pull request has been closed without being integrated.

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

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

From coleenp at openjdk.org  Wed Jun 21 12:23:03 2023
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 21 Jun 2023 12:23:03 GMT
Subject: RFR: 8310537: Fix -Wconversion warnings in gcUtil.hpp
Message-ID: <xV6v7cynLr5GxJd41ONnB2SJDevxjimriC7BwvJPETc=.336c5b56-7541-42f8-ad94-d07b925c45b1@github.com>

Please review small changes to fix -Wconversion warnings in gc code.  See CR for details.
Tested with tier1 on Oracle platforms.

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

Commit messages:
 - simple fix

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

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

From ayang at openjdk.org  Wed Jun 21 12:28:07 2023
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Wed, 21 Jun 2023 12:28:07 GMT
Subject: RFR: 8310537: Fix -Wconversion warnings in gcUtil.hpp
In-Reply-To: <xV6v7cynLr5GxJd41ONnB2SJDevxjimriC7BwvJPETc=.336c5b56-7541-42f8-ad94-d07b925c45b1@github.com>
References: <xV6v7cynLr5GxJd41ONnB2SJDevxjimriC7BwvJPETc=.336c5b56-7541-42f8-ad94-d07b925c45b1@github.com>
Message-ID: <MJGKCbBqToievR02loD5Bv2Le4TUKk4-sVzZdV-HDa4=.35ad9406-36f9-4c24-ae89-88e8640eeb23@github.com>

On Wed, 21 Jun 2023 12:16:54 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Please review small changes to fix -Wconversion warnings in gc code.  See CR for details.
> Tested with tier1 on Oracle platforms.

Marked as reviewed by ayang (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/14585#pullrequestreview-1490607437

From coleenp at openjdk.org  Wed Jun 21 12:32:03 2023
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 21 Jun 2023 12:32:03 GMT
Subject: RFR: 8310537: Fix -Wconversion warnings in gcUtil.hpp
In-Reply-To: <xV6v7cynLr5GxJd41ONnB2SJDevxjimriC7BwvJPETc=.336c5b56-7541-42f8-ad94-d07b925c45b1@github.com>
References: <xV6v7cynLr5GxJd41ONnB2SJDevxjimriC7BwvJPETc=.336c5b56-7541-42f8-ad94-d07b925c45b1@github.com>
Message-ID: <nveC5C6d-ciQ6THtaf-NtchRJzvjuschQzOq5odVlQ8=.42bafceb-3ad6-40f0-978d-39261ec82a41@github.com>

On Wed, 21 Jun 2023 12:16:54 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Please review small changes to fix -Wconversion warnings in gc code.  See CR for details.
> Tested with tier1 on Oracle platforms.

Thanks Albert.

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

PR Comment: https://git.openjdk.org/jdk/pull/14585#issuecomment-1600745723

From ayang at openjdk.org  Wed Jun 21 13:40:43 2023
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Wed, 21 Jun 2023 13:40:43 GMT
Subject: RFR: 8310541: G1: Remove redundant check in
 G1Policy::need_to_start_conc_mark
Message-ID: <MBQ_rNMGnCnDdotCVqOeBeWRjommUy7wpBvnY7Jo7lo=.69c2328f-254a-44ce-b0a3-38fa4a5a29ff@github.com>

Simple removing a redundant check, which has already been covered in the early-return part.

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

Commit messages:
 - g1-state-redundant

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

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

From tschatzl at openjdk.org  Wed Jun 21 15:17:08 2023
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Wed, 21 Jun 2023 15:17:08 GMT
Subject: RFR: 8310540: G1: Verification should use raw oop decode functions
Message-ID: <90UMk1ZjKfYXOlndOgFxkwLiWqlXjHZVgmBgBE4K6y8=.cbc0c301-2b4c-4825-a7d2-893891291650@github.com>

Hi all,

  please review this PR that changes a `CompressedOops::decode_not_null` to a `decode_raw_not_null`. The reason is that doing so allows the method to proceed to print better debugging information compared to the failing assert in `decode_not_null`.

Testing: gha, local compilation

Thanks,
  Thomas

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

Commit messages:
 - initial version

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

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

From tschatzl at openjdk.org  Wed Jun 21 15:17:21 2023
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Wed, 21 Jun 2023 15:17:21 GMT
Subject: RFR: 8310541: G1: Remove redundant check in
 G1Policy::need_to_start_conc_mark
In-Reply-To: <MBQ_rNMGnCnDdotCVqOeBeWRjommUy7wpBvnY7Jo7lo=.69c2328f-254a-44ce-b0a3-38fa4a5a29ff@github.com>
References: <MBQ_rNMGnCnDdotCVqOeBeWRjommUy7wpBvnY7Jo7lo=.69c2328f-254a-44ce-b0a3-38fa4a5a29ff@github.com>
Message-ID: <_Ee-_AjoHCsLmXhpxjB5h0ZVTaloxd5tt3uHqQp2qu8=.8052644d-61ac-4bdc-81df-253d8cf2ea42@github.com>

On Wed, 21 Jun 2023 13:24:58 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple removing a redundant check, which has already been covered in the early-return part.

lgtm.

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

Marked as reviewed by tschatzl (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14588#pullrequestreview-1491038393

From duke at openjdk.org  Wed Jun 21 15:26:07 2023
From: duke at openjdk.org (Ashutosh Mehra)
Date: Wed, 21 Jun 2023 15:26:07 GMT
Subject: RFR: 8310160: Make GC APIs for handling archive heap objects
 agnostic of GC policy [v2]
In-Reply-To: <RPL1CUGmVmd-z_RF_jpEXhw2-c791_nImMoCl7bq8js=.7dd14918-d27e-4007-9e7e-cc5e32c2d9f6@github.com>
References: <S6B2u9JEc8rz29_HpCadu8vAQaRLqS_8Tj6O57z583w=.e6b981e4-38f8-41eb-8ae6-cf1378ceac10@github.com>
 <RPL1CUGmVmd-z_RF_jpEXhw2-c791_nImMoCl7bq8js=.7dd14918-d27e-4007-9e7e-cc5e32c2d9f6@github.com>
Message-ID: <duPcmY8YGvWUGt_yH2wyK_EChc495PuTPimzPxRmBto=.ec391438-7d1b-4ca9-8fcd-b6ab0befa8ea@github.com>

On Mon, 19 Jun 2023 20:06:23 GMT, Ashutosh Mehra <duke at openjdk.org> wrote:

>> This PR adds GC APIs to be implemented by all collectors for proper handling of archive heap space. Currently only G1 is updated to use these APIs which just involves renaming the existing G1 APIs.
>> In addition to that filemap.cpp is updated to replace calls to `G1CollectedHeap::heap()` with `Universe::heap()` to avoid G1 specific code as much as possible.
>> 
>> At many places in filemap.cpp heap range is requested from GC. All collectors except ZGC have contiguous heap and set `CollectedHeap::_reserved` to the heap range, so it can be easily exposed to the CDS code. This is done in this patch through `CollectedHeap::reserved` API. But for ZGC the heap can be discontiguous which makes it tricky to expose the heap range.
>> Another point to note is that most of the usage for heap range is for logging purpose, but there is one place where it is used for setting the `mapping_offset` in `FileMapInfo::write_region()` based on the heap start. So purely based on the functional requirement, we only need the heap start address, not the range.
>> 
>> To keep things simple and considering ZGC does not currently support archive heap, i refrained from tackling the issue of discontiguous heap range in this PR.
>
> Ashutosh Mehra has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Remove unnecessary assert and condition for UseG1GC
>    
>    Signed-off-by: Ashutosh Mehra <asmehra at redhat.com>
>  - Rename CollectedHeap::reserved() to CollectedHeap::reserved_range()
>    
>    Signed-off-by: Ashutosh Mehra <asmehra at redhat.com>
>  - Rename alloc_archive_space to allocate_archive_space
>    
>    Signed-off-by: Ashutosh Mehra <asmehra at redhat.com>

My whole idea behind this is to have common GC APIs that the CDS can use to manage archive heap. As long as collector internals are properly abstracted out and hidden behind the APIs, CDS wouldn't need to worry about what the individual collectors do internally.
I agree the ideal scenario would be to use object allocation APIs but considering the issues @iklam pointed out, it doesn't look like a viable approach. @fisk do you agree with this assessment? Do you have any other alternative approach in mind?

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

PR Comment: https://git.openjdk.org/jdk/pull/14520#issuecomment-1601049487

From tschatzl at openjdk.org  Wed Jun 21 15:28:49 2023
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Wed, 21 Jun 2023 15:28:49 GMT
Subject: RFR: 8308633: Increase precision of timestamps in g1 log
Message-ID: <Zw0BH-of_aBpCEV5YJwiQBvKxRgab-NBYh6_9Yo5uVc=.200ecd00-5d9f-4f0e-a6c3-13e87445dcd1@github.com>

Hi all,

  please review this improvement adding a digit to log timestamp to improve output. On modern machines, for some pauses, this can lead to sub-phase timings not adding up, and during development, extra work to evaluate different options.
Also that rounding error starts to matter for e.g. pauses < a few ms. 

I am aware that there is a duplication of the timestamp format in the files, and this change did not improve that as this would be a different issue. Not sure where to put such a global constant though, any suggestions?

Testing: gha, looking at log files

Thanks,
  Thomas

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

Commit messages:
 - initial version, add digit to timestamps in logs

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

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

From tschatzl at openjdk.org  Wed Jun 21 15:29:07 2023
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Wed, 21 Jun 2023 15:29:07 GMT
Subject: RFR: 8310354: G1: Annotate G1MMUTracker::when_sec with const
In-Reply-To: <8m9-PL-wJR35jrDel3faUh5JTcLWqZqW-6bVytOYvU4=.2bf87dec-7067-410e-bb16-70ad32aeed37@github.com>
References: <8m9-PL-wJR35jrDel3faUh5JTcLWqZqW-6bVytOYvU4=.2bf87dec-7067-410e-bb16-70ad32aeed37@github.com>
Message-ID: <8NBBhzw0fTQaNQWLMGgT6E05TC3_DBRJcigfWaQkSno=.f3d7ca80-8efc-4a04-8702-0f5eeeab4fab@github.com>

On Tue, 20 Jun 2023 09:52:43 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simply adding `const` to G1MMUTracker APIs.

lgtm

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

Marked as reviewed by tschatzl (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14554#pullrequestreview-1491073236

From stuefe at openjdk.org  Wed Jun 21 18:18:06 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Wed, 21 Jun 2023 18:18:06 GMT
Subject: RFR: 8310160: Make GC APIs for handling archive heap objects
 agnostic of GC policy [v2]
In-Reply-To: <duPcmY8YGvWUGt_yH2wyK_EChc495PuTPimzPxRmBto=.ec391438-7d1b-4ca9-8fcd-b6ab0befa8ea@github.com>
References: <S6B2u9JEc8rz29_HpCadu8vAQaRLqS_8Tj6O57z583w=.e6b981e4-38f8-41eb-8ae6-cf1378ceac10@github.com>
 <RPL1CUGmVmd-z_RF_jpEXhw2-c791_nImMoCl7bq8js=.7dd14918-d27e-4007-9e7e-cc5e32c2d9f6@github.com>
 <duPcmY8YGvWUGt_yH2wyK_EChc495PuTPimzPxRmBto=.ec391438-7d1b-4ca9-8fcd-b6ab0befa8ea@github.com>
Message-ID: <Fpe8glogoxni2Wi7p7n1BLOLZ5Tiif2iBQ_m9_kiHek=.e2e73960-6c29-491d-9278-5e940b04b023@github.com>

On Wed, 21 Jun 2023 15:23:28 GMT, Ashutosh Mehra <duke at openjdk.org> wrote:

> My whole idea behind this is to have common GC APIs that the CDS can use to manage archive heap. As long as collector internals are properly abstracted out and hidden behind the APIs, CDS wouldn't need to worry about what the individual collectors do internally.
> I agree the ideal scenario would be to use object allocation APIs but considering the issues @iklam pointed out, it doesn't look like a viable approach. @fisk do you agree with this assessment? Do you have any other alternative approach in mind?

I agree, that this is still an improvement and worth doing unless Erik has a better idea.

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

PR Comment: https://git.openjdk.org/jdk/pull/14520#issuecomment-1601353017

From aboldtch at openjdk.org  Thu Jun 22 10:13:02 2023
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Thu, 22 Jun 2023 10:13:02 GMT
Subject: RFR: 8310537: Fix -Wconversion warnings in gcUtil.hpp
In-Reply-To: <xV6v7cynLr5GxJd41ONnB2SJDevxjimriC7BwvJPETc=.336c5b56-7541-42f8-ad94-d07b925c45b1@github.com>
References: <xV6v7cynLr5GxJd41ONnB2SJDevxjimriC7BwvJPETc=.336c5b56-7541-42f8-ad94-d07b925c45b1@github.com>
Message-ID: <AYiLuvdpiQ1K6gAhNn6GfGU8T2R0n-v_xWv0qYGfeHI=.6d93e932-8060-4fb5-949b-4827a1a7061d@github.com>

On Wed, 21 Jun 2023 12:16:54 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Please review small changes to fix -Wconversion warnings in gc code.  See CR for details.
> Tested with tier1 on Oracle platforms.

src/hotspot/share/gc/shared/gcUtil.cpp line 89:

> 87:   // Now update the deviation and the padded average.
> 88:   float new_avg = average();
> 89:   float new_dev = compute_adaptive_average((float)fabsd(new_sample - new_avg),

Is JDK-6302670 still relevant, and/or are there other reasons we avoid `cmath`? This could just be `fabsf`

src/hotspot/share/gc/shared/gcUtil.cpp line 122:

> 120:   _sum_xy = _sum_xy + x * y;
> 121:   _mean_x.sample((float)x);
> 122:   _mean_y.sample((float)y);

If this narrowed more than some small epsilon the behaviour would be strange. Seems like the actual interface here should be to sample float precision `x` and `y`.  (`void LinearLeastSquareFit::update(float x, float y)`)

I have no objection for doing it this way, just an observation of `LinearLeastSquareFit`

I know from my own experiments with `-Wconversions` that we have many areas where it is the interface that seems wrong. (Sometimes moving from int -> long -> int -> long, just to fit different subcomponent interfaces)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14585#discussion_r1238307791
PR Review Comment: https://git.openjdk.org/jdk/pull/14585#discussion_r1238306747

From coleenp at openjdk.org  Thu Jun 22 12:11:14 2023
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 22 Jun 2023 12:11:14 GMT
Subject: RFR: 8310537: Fix -Wconversion warnings in gcUtil.hpp
In-Reply-To: <AYiLuvdpiQ1K6gAhNn6GfGU8T2R0n-v_xWv0qYGfeHI=.6d93e932-8060-4fb5-949b-4827a1a7061d@github.com>
References: <xV6v7cynLr5GxJd41ONnB2SJDevxjimriC7BwvJPETc=.336c5b56-7541-42f8-ad94-d07b925c45b1@github.com>
 <AYiLuvdpiQ1K6gAhNn6GfGU8T2R0n-v_xWv0qYGfeHI=.6d93e932-8060-4fb5-949b-4827a1a7061d@github.com>
Message-ID: <F4e3241ODVCLBBijUZE_jomXt9qkx_Q1SNiRj4gDOH8=.127fbbec-4569-43f2-86c6-7dc25be58ddf@github.com>

On Thu, 22 Jun 2023 10:06:22 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> Please review small changes to fix -Wconversion warnings in gc code.  See CR for details.
>> Tested with tier1 on Oracle platforms.
>
> src/hotspot/share/gc/shared/gcUtil.cpp line 122:
> 
>> 120:   _sum_xy = _sum_xy + x * y;
>> 121:   _mean_x.sample((float)x);
>> 122:   _mean_y.sample((float)y);
> 
> If this narrowed more than some small epsilon the behaviour would be strange. Seems like the actual interface here should be to sample float precision `x` and `y`.  (`void LinearLeastSquareFit::update(float x, float y)`)
> 
> I have no objection for doing it this way, just an observation of `LinearLeastSquareFit`
> 
> I know from my own experiments with `-Wconversions` that we have many areas where it is the interface that seems wrong. (Sometimes moving from int -> long -> int -> long, just to fit different subcomponent interfaces)

Oh you've had experiences with -Wconversions? Thank you, I can ask you questions. I've tried to fix the interface when possible to be more precise with int types. In this case, it was float so not as sure if this is the right thing to do.  I'm not sure I understand your comment.  LinearLeastSquare fit seems determined to take double, and AdaptiveWeightedAverage uses float. I'm not sure how to change this to make it safer.  My usual strategy would be to make the AdaptiveWeightedAverage take double but then the fall out from that would be more than I can deal with.  What do you think?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14585#discussion_r1238435189

From coleenp at openjdk.org  Thu Jun 22 12:23:07 2023
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 22 Jun 2023 12:23:07 GMT
Subject: RFR: 8310537: Fix -Wconversion warnings in gcUtil.hpp
In-Reply-To: <AYiLuvdpiQ1K6gAhNn6GfGU8T2R0n-v_xWv0qYGfeHI=.6d93e932-8060-4fb5-949b-4827a1a7061d@github.com>
References: <xV6v7cynLr5GxJd41ONnB2SJDevxjimriC7BwvJPETc=.336c5b56-7541-42f8-ad94-d07b925c45b1@github.com>
 <AYiLuvdpiQ1K6gAhNn6GfGU8T2R0n-v_xWv0qYGfeHI=.6d93e932-8060-4fb5-949b-4827a1a7061d@github.com>
Message-ID: <jpWMF_WGgD-vJEYXBVZN4uRHEJ4TgXxbkXyqIpHSwto=.4cfa7924-18ac-4783-a032-aa732b3e94b2@github.com>

On Thu, 22 Jun 2023 10:07:17 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> Please review small changes to fix -Wconversion warnings in gc code.  See CR for details.
>> Tested with tier1 on Oracle platforms.
>
> src/hotspot/share/gc/shared/gcUtil.cpp line 89:
> 
>> 87:   // Now update the deviation and the padded average.
>> 88:   float new_avg = average();
>> 89:   float new_dev = compute_adaptive_average((float)fabsd(new_sample - new_avg),
> 
> Is JDK-6302670 still relevant, and/or are there other reasons we avoid `cmath`? This could just be `fabsf`

JDK-630267 does not seem relevant.  We should clean that up (or maybe at least the comment).  I changed these occurrences to fabs.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14585#discussion_r1238448332

From aboldtch at openjdk.org  Thu Jun 22 12:32:04 2023
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Thu, 22 Jun 2023 12:32:04 GMT
Subject: RFR: 8310537: Fix -Wconversion warnings in gcUtil.hpp
In-Reply-To: <F4e3241ODVCLBBijUZE_jomXt9qkx_Q1SNiRj4gDOH8=.127fbbec-4569-43f2-86c6-7dc25be58ddf@github.com>
References: <xV6v7cynLr5GxJd41ONnB2SJDevxjimriC7BwvJPETc=.336c5b56-7541-42f8-ad94-d07b925c45b1@github.com>
 <AYiLuvdpiQ1K6gAhNn6GfGU8T2R0n-v_xWv0qYGfeHI=.6d93e932-8060-4fb5-949b-4827a1a7061d@github.com>
 <F4e3241ODVCLBBijUZE_jomXt9qkx_Q1SNiRj4gDOH8=.127fbbec-4569-43f2-86c6-7dc25be58ddf@github.com>
Message-ID: <EnjEYgH4zBhkUumjop-u6R8NmyI46dKlm452NbkUs-g=.546ad4ec-8a59-453a-b4cd-e1c7c9d15823@github.com>

On Thu, 22 Jun 2023 12:08:08 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> src/hotspot/share/gc/shared/gcUtil.cpp line 122:
>> 
>>> 120:   _sum_xy = _sum_xy + x * y;
>>> 121:   _mean_x.sample((float)x);
>>> 122:   _mean_y.sample((float)y);
>> 
>> If this narrowed more than some small epsilon the behaviour would be strange. Seems like the actual interface here should be to sample float precision `x` and `y`.  (`void LinearLeastSquareFit::update(float x, float y)`)
>> 
>> I have no objection for doing it this way, just an observation of `LinearLeastSquareFit`
>> 
>> I know from my own experiments with `-Wconversions` that we have many areas where it is the interface that seems wrong. (Sometimes moving from int -> long -> int -> long, just to fit different subcomponent interfaces)
>
> Oh you've had experiences with -Wconversions? Thank you, I can ask you questions. I've tried to fix the interface when possible to be more precise with int types. In this case, it was float so not as sure if this is the right thing to do.  I'm not sure I understand your comment.  LinearLeastSquare fit seems determined to take double, and AdaptiveWeightedAverage uses float. I'm not sure how to change this to make it safer.  My usual strategy would be to make the AdaptiveWeightedAverage take double but then the fall out from that would be more than I can deal with.  What do you think?

What I mean is that we are doing a least square fit on a bunch of datapoints. The algorithm requires the mean, sum and sum of squares. If the datapoints truly required double precision or magnitude then storing the sum and sum of square in a double will overflow and/or be inaccurate. 

AdaptiveWeightedAverage having a float interface strengthens the case that the samples should be floats, as the running mean should never overflow or underflow the samples `min sample ? mean sample ? max sample`, (may lose precision, but if the samples are float precision, it seems resonable that the mean also have this precision)

It was not about safety but about having the interface express the capabilities of the class. It can sample float x,y points and provide a least square fit linear function`y(x)`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14585#discussion_r1238454835

From aboldtch at openjdk.org  Thu Jun 22 12:32:04 2023
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Thu, 22 Jun 2023 12:32:04 GMT
Subject: RFR: 8310537: Fix -Wconversion warnings in gcUtil.hpp
In-Reply-To: <EnjEYgH4zBhkUumjop-u6R8NmyI46dKlm452NbkUs-g=.546ad4ec-8a59-453a-b4cd-e1c7c9d15823@github.com>
References: <xV6v7cynLr5GxJd41ONnB2SJDevxjimriC7BwvJPETc=.336c5b56-7541-42f8-ad94-d07b925c45b1@github.com>
 <AYiLuvdpiQ1K6gAhNn6GfGU8T2R0n-v_xWv0qYGfeHI=.6d93e932-8060-4fb5-949b-4827a1a7061d@github.com>
 <F4e3241ODVCLBBijUZE_jomXt9qkx_Q1SNiRj4gDOH8=.127fbbec-4569-43f2-86c6-7dc25be58ddf@github.com>
 <EnjEYgH4zBhkUumjop-u6R8NmyI46dKlm452NbkUs-g=.546ad4ec-8a59-453a-b4cd-e1c7c9d15823@github.com>
Message-ID: <yzdTnNZLIK31iEEIxpbw6uEI34Mch9Q-kjn9cegoDGg=.bdee86c2-de4c-4729-adf6-47322705b9bf@github.com>

On Thu, 22 Jun 2023 12:25:53 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> Oh you've had experiences with -Wconversions? Thank you, I can ask you questions. I've tried to fix the interface when possible to be more precise with int types. In this case, it was float so not as sure if this is the right thing to do.  I'm not sure I understand your comment.  LinearLeastSquare fit seems determined to take double, and AdaptiveWeightedAverage uses float. I'm not sure how to change this to make it safer.  My usual strategy would be to make the AdaptiveWeightedAverage take double but then the fall out from that would be more than I can deal with.  What do you think?
>
> What I mean is that we are doing a least square fit on a bunch of datapoints. The algorithm requires the mean, sum and sum of squares. If the datapoints truly required double precision or magnitude then storing the sum and sum of square in a double will overflow and/or be inaccurate. 
> 
> AdaptiveWeightedAverage having a float interface strengthens the case that the samples should be floats, as the running mean should never overflow or underflow the samples `min sample ? mean sample ? max sample`, (may lose precision, but if the samples are float precision, it seems resonable that the mean also have this precision)
> 
> It was not about safety but about having the interface express the capabilities of the class. It can sample float x,y points and provide a least square fit linear function`y(x)`

At least that is my interpretation when I ever see intermediate sums use a type with more bits of information than the samples/parts. But maybe that was never the intent.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14585#discussion_r1238458225

From coleenp at openjdk.org  Thu Jun 22 12:56:20 2023
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 22 Jun 2023 12:56:20 GMT
Subject: RFR: 8310537: Fix -Wconversion warnings in gcUtil.hpp [v2]
In-Reply-To: <xV6v7cynLr5GxJd41ONnB2SJDevxjimriC7BwvJPETc=.336c5b56-7541-42f8-ad94-d07b925c45b1@github.com>
References: <xV6v7cynLr5GxJd41ONnB2SJDevxjimriC7BwvJPETc=.336c5b56-7541-42f8-ad94-d07b925c45b1@github.com>
Message-ID: <0qXEeb-sxa8aDd-UUb8JS78M8kq5jmubgD4vrHYdLgM=.4dfb3fea-9d41-4696-a2b5-bbe24ef6c267@github.com>

> Please review small changes to fix -Wconversion warnings in gc code.  See CR for details.
> Tested with tier1 on Oracle platforms.

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

  Use fabs instead of casting.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14585/files
  - new: https://git.openjdk.org/jdk/pull/14585/files/cf267363..f4133e65

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

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

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

From ayang at openjdk.org  Thu Jun 22 13:52:04 2023
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Thu, 22 Jun 2023 13:52:04 GMT
Subject: RFR: 8308633: Increase precision of timestamps in g1 log
In-Reply-To: <Zw0BH-of_aBpCEV5YJwiQBvKxRgab-NBYh6_9Yo5uVc=.200ecd00-5d9f-4f0e-a6c3-13e87445dcd1@github.com>
References: <Zw0BH-of_aBpCEV5YJwiQBvKxRgab-NBYh6_9Yo5uVc=.200ecd00-5d9f-4f0e-a6c3-13e87445dcd1@github.com>
Message-ID: <FWO63vqTzWXcGoT8Z4rXVAeAtoCc0BJmygT4nddwsPM=.8491601c-11ad-4eaa-9fd8-e0b4799ea9c5@github.com>

On Wed, 21 Jun 2023 15:19:41 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   please review this improvement adding a digit to log timestamp to improve output. On modern machines, for some pauses, this can lead to sub-phase timings not adding up, and during development, extra work to evaluate different options.
> Also that rounding error starts to matter for e.g. pauses < a few ms. 
> 
> I am aware that there is a duplication of the timestamp format in the files, and this change did not improve that as this would be a different issue. Not sure where to put such a global constant though, any suggestions?
> 
> Testing: gha, looking at log files
> 
> Thanks,
>   Thomas

Marked as reviewed by ayang (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/14594#pullrequestreview-1493245098

From ayang at openjdk.org  Thu Jun 22 14:01:02 2023
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Thu, 22 Jun 2023 14:01:02 GMT
Subject: RFR: 8310540: G1: Verification should use raw oop decode functions
In-Reply-To: <90UMk1ZjKfYXOlndOgFxkwLiWqlXjHZVgmBgBE4K6y8=.cbc0c301-2b4c-4825-a7d2-893891291650@github.com>
References: <90UMk1ZjKfYXOlndOgFxkwLiWqlXjHZVgmBgBE4K6y8=.cbc0c301-2b4c-4825-a7d2-893891291650@github.com>
Message-ID: <pWThcCR2n3SACWGKmoyWUvnTHRju8l8SWqXSX72FFqc=.d7dc2196-3056-4d7e-9739-2a63571ddb2c@github.com>

On Wed, 21 Jun 2023 15:10:22 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   please review this PR that changes a `CompressedOops::decode_not_null` to a `decode_raw_not_null`. The reason is that doing so allows the method to proceed to print better debugging information compared to the failing assert in `decode_not_null`.
> 
> Testing: gha, local compilation
> 
> Thanks,
>   Thomas

Marked as reviewed by ayang (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/14592#pullrequestreview-1493265903

From coleenp at openjdk.org  Thu Jun 22 15:56:32 2023
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 22 Jun 2023 15:56:32 GMT
Subject: RFR: 8310537: Fix -Wconversion warnings in gcUtil.hpp [v3]
In-Reply-To: <xV6v7cynLr5GxJd41ONnB2SJDevxjimriC7BwvJPETc=.336c5b56-7541-42f8-ad94-d07b925c45b1@github.com>
References: <xV6v7cynLr5GxJd41ONnB2SJDevxjimriC7BwvJPETc=.336c5b56-7541-42f8-ad94-d07b925c45b1@github.com>
Message-ID: <SKNYd11KlB1HB4pFTULQjmU-AkmoKQSdb7DDaDCC9RE=.87a8e139-4f88-4277-8584-0f8ca10c9d4e@github.com>

> Please review small changes to fix -Wconversion warnings in gc code.  See CR for details.
> Tested with tier1 on Oracle platforms.

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

  Add a comment about the float conversion.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14585/files
  - new: https://git.openjdk.org/jdk/pull/14585/files/f4133e65..01d75316

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

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

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

From coleenp at openjdk.org  Thu Jun 22 15:56:32 2023
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 22 Jun 2023 15:56:32 GMT
Subject: RFR: 8310537: Fix -Wconversion warnings in gcUtil.hpp [v3]
In-Reply-To: <yzdTnNZLIK31iEEIxpbw6uEI34Mch9Q-kjn9cegoDGg=.bdee86c2-de4c-4729-adf6-47322705b9bf@github.com>
References: <xV6v7cynLr5GxJd41ONnB2SJDevxjimriC7BwvJPETc=.336c5b56-7541-42f8-ad94-d07b925c45b1@github.com>
 <AYiLuvdpiQ1K6gAhNn6GfGU8T2R0n-v_xWv0qYGfeHI=.6d93e932-8060-4fb5-949b-4827a1a7061d@github.com>
 <F4e3241ODVCLBBijUZE_jomXt9qkx_Q1SNiRj4gDOH8=.127fbbec-4569-43f2-86c6-7dc25be58ddf@github.com>
 <EnjEYgH4zBhkUumjop-u6R8NmyI46dKlm452NbkUs-g=.546ad4ec-8a59-453a-b4cd-e1c7c9d15823@github.com>
 <yzdTnNZLIK31iEEIxpbw6uEI34Mch9Q-kjn9cegoDGg=.bdee86c2-de4c-4729-adf6-47322705b9bf@github.com>
Message-ID: <YILuoxChgdH_nVVi1Rykmgq7J2qEVt7QumEealUL-pY=.c9f30bcf-a989-4620-a5ab-beafbebafbd1@github.com>

On Thu, 22 Jun 2023 12:28:51 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> What I mean is that we are doing a least square fit on a bunch of datapoints. The algorithm requires the mean, sum and sum of squares. If the datapoints truly required double precision or magnitude then storing the sum and sum of square in a double will overflow and/or be inaccurate. 
>> 
>> AdaptiveWeightedAverage having a float interface strengthens the case that the samples should be floats, as the running mean should never overflow or underflow the samples `min sample ? mean sample ? max sample`, (may lose precision, but if the samples are float precision, it seems resonable that the mean also have this precision)
>> 
>> It was not about safety but about having the interface express the capabilities of the class. It can sample float x,y points and provide a least square fit linear function`y(x)`
>
> At least that is my interpretation when I ever see intermediate sums use a type with more bits of information than the samples/parts. But maybe that was never the intent.

I tried changing update to take floats but there are callers that cast unsigned ints to double to call this function, so they get -Wconversion messages.  Since this seems to not lose precision, I added a comment and suggest further cleanup in this area.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14585#discussion_r1238727112

From tschatzl at openjdk.org  Fri Jun 23 09:42:21 2023
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Fri, 23 Jun 2023 09:42:21 GMT
Subject: RFR: 8308633: Increase precision of timestamps in g1 log [v2]
In-Reply-To: <Zw0BH-of_aBpCEV5YJwiQBvKxRgab-NBYh6_9Yo5uVc=.200ecd00-5d9f-4f0e-a6c3-13e87445dcd1@github.com>
References: <Zw0BH-of_aBpCEV5YJwiQBvKxRgab-NBYh6_9Yo5uVc=.200ecd00-5d9f-4f0e-a6c3-13e87445dcd1@github.com>
Message-ID: <yxv0ayclDNvqm5XoMaHwsIvpongvZw7h7O95LUMGhZ4=.357c2627-3682-4aab-82aa-753adaca0f6c@github.com>

> Hi all,
> 
>   please review this improvement adding a digit to log timestamp to improve output. On modern machines, for some pauses, this can lead to sub-phase timings not adding up, and during development, extra work to evaluate different options.
> Also that rounding error starts to matter for e.g. pauses < a few ms. 
> 
> I am aware that there is a duplication of the timestamp format in the files, and this change did not improve that as this would be a different issue. Not sure where to put such a global constant though, any suggestions?
> 
> Testing: gha, looking at log files
> 
> Thanks,
>   Thomas

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

  Fix gtests

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14594/files
  - new: https://git.openjdk.org/jdk/pull/14594/files/b843f5b0..c311c530

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

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

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

From aboldtch at openjdk.org  Fri Jun 23 14:02:09 2023
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Fri, 23 Jun 2023 14:02:09 GMT
Subject: RFR: 8310537: Fix -Wconversion warnings in gcUtil.hpp [v3]
In-Reply-To: <SKNYd11KlB1HB4pFTULQjmU-AkmoKQSdb7DDaDCC9RE=.87a8e139-4f88-4277-8584-0f8ca10c9d4e@github.com>
References: <xV6v7cynLr5GxJd41ONnB2SJDevxjimriC7BwvJPETc=.336c5b56-7541-42f8-ad94-d07b925c45b1@github.com>
 <SKNYd11KlB1HB4pFTULQjmU-AkmoKQSdb7DDaDCC9RE=.87a8e139-4f88-4277-8584-0f8ca10c9d4e@github.com>
Message-ID: <h0tvE9X1uW1RsHXDNSC7gLwSgLXW5CBt1L_C7hq-aw4=.ad03da10-95e6-43c7-b2c0-a15f977a97ca@github.com>

On Thu, 22 Jun 2023 15:56:32 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Please review small changes to fix -Wconversion warnings in gc code.  See CR for details.
>> Tested with tier1 on Oracle platforms.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add a comment about the float conversion.

Marked as reviewed by aboldtch (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/14585#pullrequestreview-1495206697

From coleenp at openjdk.org  Fri Jun 23 16:00:16 2023
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 23 Jun 2023 16:00:16 GMT
Subject: RFR: 8310537: Fix -Wconversion warnings in gcUtil.hpp [v3]
In-Reply-To: <SKNYd11KlB1HB4pFTULQjmU-AkmoKQSdb7DDaDCC9RE=.87a8e139-4f88-4277-8584-0f8ca10c9d4e@github.com>
References: <xV6v7cynLr5GxJd41ONnB2SJDevxjimriC7BwvJPETc=.336c5b56-7541-42f8-ad94-d07b925c45b1@github.com>
 <SKNYd11KlB1HB4pFTULQjmU-AkmoKQSdb7DDaDCC9RE=.87a8e139-4f88-4277-8584-0f8ca10c9d4e@github.com>
Message-ID: <rbgwPVe-76K_ohmVyhmuS3t_37mXFF-9PpxwtP23bRQ=.2fd722c5-7ffb-4556-9776-4feaf69ff052@github.com>

On Thu, 22 Jun 2023 15:56:32 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Please review small changes to fix -Wconversion warnings in gc code.  See CR for details.
>> Tested with tier1 on Oracle platforms.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add a comment about the float conversion.

Thanks Axel and for your help.

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

PR Comment: https://git.openjdk.org/jdk/pull/14585#issuecomment-1604481063

From coleenp at openjdk.org  Fri Jun 23 16:00:16 2023
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 23 Jun 2023 16:00:16 GMT
Subject: Integrated: 8310537: Fix -Wconversion warnings in gcUtil.hpp
In-Reply-To: <xV6v7cynLr5GxJd41ONnB2SJDevxjimriC7BwvJPETc=.336c5b56-7541-42f8-ad94-d07b925c45b1@github.com>
References: <xV6v7cynLr5GxJd41ONnB2SJDevxjimriC7BwvJPETc=.336c5b56-7541-42f8-ad94-d07b925c45b1@github.com>
Message-ID: <5AhBQTOCtKbzhI_BMXt6nMY99SdL1MyCzA5DF5XqQSE=.13be0d75-00ab-4f9d-a0ee-eaa4a280a0f6@github.com>

On Wed, 21 Jun 2023 12:16:54 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Please review small changes to fix -Wconversion warnings in gc code.  See CR for details.
> Tested with tier1 on Oracle platforms.

This pull request has now been integrated.

Changeset: d91d0d30
Author:    Coleen Phillimore <coleenp at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d91d0d3011b878e47b937981896fed0b2be30362
Stats:     20 lines in 5 files changed: 0 ins; 0 del; 20 mod

8310537: Fix -Wconversion warnings in gcUtil.hpp

Reviewed-by: ayang, aboldtch

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

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

From iklam at openjdk.org  Fri Jun 23 19:43:08 2023
From: iklam at openjdk.org (Ioi Lam)
Date: Fri, 23 Jun 2023 19:43:08 GMT
Subject: RFR: 8310160: Make GC APIs for handling archive heap objects
 agnostic of GC policy [v2]
In-Reply-To: <K5TDkiSBRzpPcce5R2W59kp00leDC24TCEyOf6cJWDw=.09e6e7da-6f16-4487-bd12-3294f58dd6d9@github.com>
References: <S6B2u9JEc8rz29_HpCadu8vAQaRLqS_8Tj6O57z583w=.e6b981e4-38f8-41eb-8ae6-cf1378ceac10@github.com>
 <RPL1CUGmVmd-z_RF_jpEXhw2-c791_nImMoCl7bq8js=.7dd14918-d27e-4007-9e7e-cc5e32c2d9f6@github.com>
 <K5TDkiSBRzpPcce5R2W59kp00leDC24TCEyOf6cJWDw=.09e6e7da-6f16-4487-bd12-3294f58dd6d9@github.com>
Message-ID: <vYnrCnkJ38BmT2o_zQjxHVreEJMGdD4Op5lI-3OxK3c=.9dfdc00d-738b-4e8a-882b-20fab2ab3292@github.com>

On Tue, 20 Jun 2023 15:56:57 GMT, Erik ?sterlund <eosterlund at openjdk.org> wrote:

>> Ashutosh Mehra has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - Remove unnecessary assert and condition for UseG1GC
>>    
>>    Signed-off-by: Ashutosh Mehra <asmehra at redhat.com>
>>  - Rename CollectedHeap::reserved() to CollectedHeap::reserved_range()
>>    
>>    Signed-off-by: Ashutosh Mehra <asmehra at redhat.com>
>>  - Rename alloc_archive_space to allocate_archive_space
>>    
>>    Signed-off-by: Ashutosh Mehra <asmehra at redhat.com>
>
> It's a bit disappointing for a PR aiming to make heap archiving GC agnostic, to make assumptions about GC internal memory layout, that doesn't apply to all collectors.
> We have discussed previously with @iklam an approach where materializing archived objects uses the normal object allocation APIs. That would for real make the heap archiving mechanism GC agnostic. I would rather see that being prototyped, than a not GC agnostic approach that we might throw away right after it gets integrated, in favour of the more GC agnostic approach.

Based on discussion with @fisk, I created an RFE for investigating his idea. Please see https://bugs.openjdk.org/browse/JDK-8310823

It seems quite promising to me, and will greatly reduce (or eliminate) the interface between CDS and the collectors.

I would like to keep the current performance as possible, so I am leaning towards having an API for CDS to tell the collector about preferred location of the archived objects, to allow mmap'ing and reduce/avoid relocation. But such an hinting API will be much smaller than the ones proposed by this PR.

(We'd also need an reverse API for the collector to tell CDS what the preferred address would be, during CDS dump time).

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

PR Comment: https://git.openjdk.org/jdk/pull/14520#issuecomment-1604793890

From kbarrett at openjdk.org  Fri Jun 23 22:32:01 2023
From: kbarrett at openjdk.org (Kim Barrett)
Date: Fri, 23 Jun 2023 22:32:01 GMT
Subject: RFR: 8310541: G1: Remove redundant check in
 G1Policy::need_to_start_conc_mark
In-Reply-To: <MBQ_rNMGnCnDdotCVqOeBeWRjommUy7wpBvnY7Jo7lo=.69c2328f-254a-44ce-b0a3-38fa4a5a29ff@github.com>
References: <MBQ_rNMGnCnDdotCVqOeBeWRjommUy7wpBvnY7Jo7lo=.69c2328f-254a-44ce-b0a3-38fa4a5a29ff@github.com>
Message-ID: <bPpxOqdjelOKGb9fbwHdYbdpnQjalIe8bQ95G0do24A=.7815831c-2587-47eb-bd5b-d52c6ad2bbd5@github.com>

On Wed, 21 Jun 2023 13:24:58 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple removing a redundant check, which has already been covered in the early-return part.

Looks good.

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

Marked as reviewed by kbarrett (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14588#pullrequestreview-1496133393

From kbarrett at openjdk.org  Fri Jun 23 22:37:01 2023
From: kbarrett at openjdk.org (Kim Barrett)
Date: Fri, 23 Jun 2023 22:37:01 GMT
Subject: RFR: 8310354: G1: Annotate G1MMUTracker::when_sec with const
In-Reply-To: <8m9-PL-wJR35jrDel3faUh5JTcLWqZqW-6bVytOYvU4=.2bf87dec-7067-410e-bb16-70ad32aeed37@github.com>
References: <8m9-PL-wJR35jrDel3faUh5JTcLWqZqW-6bVytOYvU4=.2bf87dec-7067-410e-bb16-70ad32aeed37@github.com>
Message-ID: <An16TGOwnqX4lUADcetpCO_-GWu5C8sJ7pWc2uvnz2M=.080bb9ac-9b90-42b5-b08a-7a117967fac4@github.com>

On Tue, 20 Jun 2023 09:52:43 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simply adding `const` to G1MMUTracker APIs.

Looks good.

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

Marked as reviewed by kbarrett (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14554#pullrequestreview-1496137671

From kbarrett at openjdk.org  Fri Jun 23 22:41:13 2023
From: kbarrett at openjdk.org (Kim Barrett)
Date: Fri, 23 Jun 2023 22:41:13 GMT
Subject: RFR: 8308633: Increase precision of timestamps in g1 log [v2]
In-Reply-To: <yxv0ayclDNvqm5XoMaHwsIvpongvZw7h7O95LUMGhZ4=.357c2627-3682-4aab-82aa-753adaca0f6c@github.com>
References: <Zw0BH-of_aBpCEV5YJwiQBvKxRgab-NBYh6_9Yo5uVc=.200ecd00-5d9f-4f0e-a6c3-13e87445dcd1@github.com>
 <yxv0ayclDNvqm5XoMaHwsIvpongvZw7h7O95LUMGhZ4=.357c2627-3682-4aab-82aa-753adaca0f6c@github.com>
Message-ID: <6grIQj8RnS9fXswmMy1lNvS9oOaL-vEQ8wbKzaq73iA=.da6f3227-959a-4b31-bc67-588c72641715@github.com>

On Fri, 23 Jun 2023 09:42:21 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Hi all,
>> 
>>   please review this improvement adding a digit to log timestamp to improve output. On modern machines, for some pauses, this can lead to sub-phase timings not adding up, and during development, extra work to evaluate different options.
>> Also that rounding error starts to matter for e.g. pauses < a few ms. 
>> 
>> I am aware that there is a duplication of the timestamp format in the files, and this change did not improve that as this would be a different issue. Not sure where to put such a global constant though, any suggestions?
>> 
>> Testing: gha, looking at log files
>> 
>> Thanks,
>>   Thomas
>
> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix gtests

Looks good.

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

Marked as reviewed by kbarrett (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14594#pullrequestreview-1496142613

From kbarrett at openjdk.org  Fri Jun 23 22:42:04 2023
From: kbarrett at openjdk.org (Kim Barrett)
Date: Fri, 23 Jun 2023 22:42:04 GMT
Subject: RFR: 8310540: G1: Verification should use raw oop decode functions
In-Reply-To: <90UMk1ZjKfYXOlndOgFxkwLiWqlXjHZVgmBgBE4K6y8=.cbc0c301-2b4c-4825-a7d2-893891291650@github.com>
References: <90UMk1ZjKfYXOlndOgFxkwLiWqlXjHZVgmBgBE4K6y8=.cbc0c301-2b4c-4825-a7d2-893891291650@github.com>
Message-ID: <QULSS0wc3T_ci_-jIkpmsyK8fjiPD-QP435SdnmiF9g=.bcd0fb31-6178-4bc3-a872-38f6cd627932@github.com>

On Wed, 21 Jun 2023 15:10:22 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   please review this PR that changes a `CompressedOops::decode_not_null` to a `decode_raw_not_null`. The reason is that doing so allows the method to proceed to print better debugging information compared to the failing assert in `decode_not_null`.
> 
> Testing: gha, local compilation
> 
> Thanks,
>   Thomas

Looks good.

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

Marked as reviewed by kbarrett (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14592#pullrequestreview-1496143583

From azafari at openjdk.org  Mon Jun 26 07:39:09 2023
From: azafari at openjdk.org (Afshin Zafari)
Date: Mon, 26 Jun 2023 07:39:09 GMT
Subject: RFR: 8281455: Change JVM options with small ranges from 64 to 32
 bits, for gc_globals.hpp [v3]
In-Reply-To: <cr1iWZjlPNM3NP67c0HF4kZNYZ5qoaChx5BpC_frh90=.e390b436-4aa2-484c-81fc-364557839f06@github.com>
References: <PUZ-VNLsAs748dp0p0fknfkp6VxzSZRvBXp3cJvheko=.101c475e-a097-47ee-8ead-3464def85d7a@github.com>
 <Oq3b-RXjrUQa3je7gtFx5yp03T9Pqqsofb5c4Mmz4Pg=.53e4b5ec-d377-415f-95e4-27d8210ee8e9@github.com>
 <cr1iWZjlPNM3NP67c0HF4kZNYZ5qoaChx5BpC_frh90=.e390b436-4aa2-484c-81fc-364557839f06@github.com>
Message-ID: <ndexkt-n5fC4soFz7EiaFxZ2_nDLrxpB9BDB80uZ7aQ=.48033463-66f4-425b-bc4a-b3b4ce0039fa@github.com>

On Fri, 9 Jun 2023 08:30:39 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   review comments applied
>
> src/hotspot/share/gc/shared/gcOverheadChecker.cpp line 98:
> 
>> 96:     } else if (print_gc_overhead_limit_would_be_exceeded) {
>> 97:       assert(_gc_overhead_limit_count > 0, "Should not be printing");
>> 98:       log_trace(gc, ergo)("GC would exceed overhead limit of %u %% %d consecutive time(s)",
> 
> An extra space has been added before "%%"; please remove.

Fixed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14259#discussion_r1241755495

From azafari at openjdk.org  Mon Jun 26 07:45:05 2023
From: azafari at openjdk.org (Afshin Zafari)
Date: Mon, 26 Jun 2023 07:45:05 GMT
Subject: RFR: 8281455: Change JVM options with small ranges from 64 to 32
 bits, for gc_globals.hpp [v3]
In-Reply-To: <9qzT9Lt7ecfEB269kxrMEJe55tgNk5ZrE3mqLUCLQ1o=.79188521-ba30-4c80-954f-f989b955510e@github.com>
References: <PUZ-VNLsAs748dp0p0fknfkp6VxzSZRvBXp3cJvheko=.101c475e-a097-47ee-8ead-3464def85d7a@github.com>
 <Oq3b-RXjrUQa3je7gtFx5yp03T9Pqqsofb5c4Mmz4Pg=.53e4b5ec-d377-415f-95e4-27d8210ee8e9@github.com>
 <cr1iWZjlPNM3NP67c0HF4kZNYZ5qoaChx5BpC_frh90=.e390b436-4aa2-484c-81fc-364557839f06@github.com>
 <9qzT9Lt7ecfEB269kxrMEJe55tgNk5ZrE3mqLUCLQ1o=.79188521-ba30-4c80-954f-f989b955510e@github.com>
Message-ID: <POZGzmk52RZso1cGMHjj7lxFI0Wj7-mhW5SaS4TL_Uw=.94d8d2ab-ba76-4107-8ba5-6769827537c3@github.com>

On Fri, 9 Jun 2023 14:13:20 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> src/hotspot/share/gc/shared/gc_globals.hpp line 688:
>> 
>>> 686:           "Number of entries we will try to leave on the stack "            \
>>> 687:           "during parallel gc")                                             \
>>> 688:           range(0, SIZE_MAX)                                                \
>> 
>> This is a large increase in the max on 64bit platforms.
>
> Yes, you should revert the change from max_juint to SIZE_MAX.  Is the change to size_t a cleanup to remove a cast?

Reverted back to original.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14259#discussion_r1241763202

From tschatzl at openjdk.org  Mon Jun 26 07:52:19 2023
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Mon, 26 Jun 2023 07:52:19 GMT
Subject: RFR: 8310540: G1: Verification should use raw oop decode functions
In-Reply-To: <pWThcCR2n3SACWGKmoyWUvnTHRju8l8SWqXSX72FFqc=.d7dc2196-3056-4d7e-9739-2a63571ddb2c@github.com>
References: <90UMk1ZjKfYXOlndOgFxkwLiWqlXjHZVgmBgBE4K6y8=.cbc0c301-2b4c-4825-a7d2-893891291650@github.com>
 <pWThcCR2n3SACWGKmoyWUvnTHRju8l8SWqXSX72FFqc=.d7dc2196-3056-4d7e-9739-2a63571ddb2c@github.com>
Message-ID: <0aKCl8-dNLJRVWSklGkuZpsWgUIxq2KCHuqr8Ovg_-c=.9411a058-42c9-41db-97dc-97073fabbc59@github.com>

On Thu, 22 Jun 2023 13:58:06 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Hi all,
>> 
>>   please review this PR that changes a `CompressedOops::decode_not_null` to a `decode_raw_not_null`. The reason is that doing so allows the method to proceed to print better debugging information compared to the failing assert in `decode_not_null`.
>> 
>> Testing: gha, local compilation
>> 
>> Thanks,
>>   Thomas
>
> Marked as reviewed by ayang (Reviewer).

Thanks @albertnetymk @kimbarrett for your reviews

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

PR Comment: https://git.openjdk.org/jdk/pull/14592#issuecomment-1606902741

From tschatzl at openjdk.org  Mon Jun 26 07:52:20 2023
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Mon, 26 Jun 2023 07:52:20 GMT
Subject: Integrated: 8310540: G1: Verification should use raw oop decode
 functions
In-Reply-To: <90UMk1ZjKfYXOlndOgFxkwLiWqlXjHZVgmBgBE4K6y8=.cbc0c301-2b4c-4825-a7d2-893891291650@github.com>
References: <90UMk1ZjKfYXOlndOgFxkwLiWqlXjHZVgmBgBE4K6y8=.cbc0c301-2b4c-4825-a7d2-893891291650@github.com>
Message-ID: <Ix2Q3p7I3HrPFZbryoS9NPDRmw_G-2blL7raHf9lwfQ=.28e1038d-3e97-4bfe-b2ee-0e5ed49a59bb@github.com>

On Wed, 21 Jun 2023 15:10:22 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   please review this PR that changes a `CompressedOops::decode_not_null` to a `decode_raw_not_null`. The reason is that doing so allows the method to proceed to print better debugging information compared to the failing assert in `decode_not_null`.
> 
> Testing: gha, local compilation
> 
> Thanks,
>   Thomas

This pull request has now been integrated.

Changeset: 93970946
Author:    Thomas Schatzl <tschatzl at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/9397094692ca840b1ac0c5b43edb895f8a397510
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8310540: G1: Verification should use raw oop decode functions

Reviewed-by: ayang, kbarrett

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

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

From tschatzl at openjdk.org  Mon Jun 26 07:54:12 2023
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Mon, 26 Jun 2023 07:54:12 GMT
Subject: RFR: 8308633: Increase precision of timestamps in g1 log [v2]
In-Reply-To: <FWO63vqTzWXcGoT8Z4rXVAeAtoCc0BJmygT4nddwsPM=.8491601c-11ad-4eaa-9fd8-e0b4799ea9c5@github.com>
References: <Zw0BH-of_aBpCEV5YJwiQBvKxRgab-NBYh6_9Yo5uVc=.200ecd00-5d9f-4f0e-a6c3-13e87445dcd1@github.com>
 <FWO63vqTzWXcGoT8Z4rXVAeAtoCc0BJmygT4nddwsPM=.8491601c-11ad-4eaa-9fd8-e0b4799ea9c5@github.com>
Message-ID: <5QKiIHzyJ5XFWxH5mFRZaRNq44eu0mwiHsDgRpoitzU=.0fb9775b-978a-4151-b1f0-a21722203aac@github.com>

On Thu, 22 Jun 2023 13:49:07 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix gtests
>
> Marked as reviewed by ayang (Reviewer).

Thanks @albertnetymk @kimbarrett  for your reviews

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

PR Comment: https://git.openjdk.org/jdk/pull/14594#issuecomment-1606903342

From tschatzl at openjdk.org  Mon Jun 26 07:54:14 2023
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Mon, 26 Jun 2023 07:54:14 GMT
Subject: Integrated: 8308633: Increase precision of timestamps in g1 log
In-Reply-To: <Zw0BH-of_aBpCEV5YJwiQBvKxRgab-NBYh6_9Yo5uVc=.200ecd00-5d9f-4f0e-a6c3-13e87445dcd1@github.com>
References: <Zw0BH-of_aBpCEV5YJwiQBvKxRgab-NBYh6_9Yo5uVc=.200ecd00-5d9f-4f0e-a6c3-13e87445dcd1@github.com>
Message-ID: <5JrPv6-zXSbGhdRW1Lst6lg-eVNLD2C7_OKnTb6HFmU=.c8cbd795-5b62-448a-b7b5-4404237124ea@github.com>

On Wed, 21 Jun 2023 15:19:41 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   please review this improvement adding a digit to log timestamp to improve output. On modern machines, for some pauses, this can lead to sub-phase timings not adding up, and during development, extra work to evaluate different options.
> Also that rounding error starts to matter for e.g. pauses < a few ms. 
> 
> I am aware that there is a duplication of the timestamp format in the files, and this change did not improve that as this would be a different issue. Not sure where to put such a global constant though, any suggestions?
> 
> Testing: gha, looking at log files
> 
> Thanks,
>   Thomas

This pull request has now been integrated.

Changeset: c23794f8
Author:    Thomas Schatzl <tschatzl at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c23794f88270c121bf99fdf297fdfde53072e3b6
Stats:     13 lines in 4 files changed: 3 ins; 0 del; 10 mod

8308633: Increase precision of timestamps in g1 log

Reviewed-by: ayang, kbarrett

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

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

From tschatzl at openjdk.org  Mon Jun 26 10:21:12 2023
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Mon, 26 Jun 2023 10:21:12 GMT
Subject: RFR: 8140326: G1: Consider putting regions where evacuation failed
 into next collection set [v6]
In-Reply-To: <mmq6sEkAicO7Mc5FKkk5tcRVJDU6qtjYoyySho56F80=.aea5db50-0ec5-4e27-944e-2750af3d0bd7@github.com>
References: <mmq6sEkAicO7Mc5FKkk5tcRVJDU6qtjYoyySho56F80=.aea5db50-0ec5-4e27-944e-2750af3d0bd7@github.com>
Message-ID: <y40IwH73VtKykT-naUHOxF200W416N6flAktzEAUGtY=.bbe5f7d5-cf5a-4d72-8d24-b4b25697e38d@github.com>

> This change adds management of retained regions, i.e. trying to evacuate evacuation failed regions asap.
> 
> The advantage is that evacuation failed regions do not need to wait until the next marking to be cleaned out; as they are often very sparsely occupied (often being eden regions), this occupies a lot of space, potentially causing additional evacuation failures later on.
> Another use of this change will be region pinning, which are basically evacuation failed regions that can not be reclaimed as long as they are pinned - however as soon as they are unpinned, they should be reclaimed for the same reasons as well.
> 
> It consists of several behavioral changes:
> 
> During garbage collection:
> 
> ... in the Evacuation phase:
> * always collect dirty cards into evacuation failed regions proactively. In tests, the amount of cards/live objects per evacuation failed region is typically very small. Dirty cards are always put into the global refinement buffer immediately, assuming that we will keep most if not all evacuation failed regions.
> 
> ... during Post Evacuation 2/Free Collection Set phase:
> * determine whether the region will be retained (kept for "immediate" evacuation) or not. Highly occupied regions are assumed to stay (mostly) live at least until the next marking, so do not bother with them.
> 
> These "retained" regions are collected in a new "from retained" set in the collection set candidates and managed separately from "from marking" regions. Having the "from retained" and "from marking" sets separate in the collection set candidates is easier to manage than to use a single list and the picking stuff from it. Particularly wrt to making sure that mixed gcs preferentially pick from the "from marking" list first, then second from the "from retained" list.
> 
> ... determining the collection set during the pause:
>   * during gc, the collection set is preferentially (first) populated with regions from the "from marking" candidates (these are the important regions to get cleaned out), second from the "from retained" list.
>   * g1 reserves up to 20% of max gc pause time for retained regions as optional candidates (this is a random number) to make sure that these are cleared out asap to free memory. There is also a minimum number of regions to take from the retained regions list.
> 
> During marking
> 
> ... changes to marking proper
> * retained regions will not be marked through during concurrent mark, i.e. they are considered outside of the snapshot. So they are added to the "root regio...

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

  ayang review:
  - do not add retained regions time during base time calculation when finalizing young gen
  - add marking state (tams, bitmap, live bytes) verification at the end of a concurrent start pause (with -XX:+VerifyAfterGC)

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14220/files
  - new: https://git.openjdk.org/jdk/pull/14220/files/53350858..2bb1fdaa

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

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

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

From tschatzl at openjdk.org  Mon Jun 26 10:34:06 2023
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Mon, 26 Jun 2023 10:34:06 GMT
Subject: RFR: 8140326: G1: Consider putting regions where evacuation failed
 into next collection set [v6]
In-Reply-To: <y40IwH73VtKykT-naUHOxF200W416N6flAktzEAUGtY=.bbe5f7d5-cf5a-4d72-8d24-b4b25697e38d@github.com>
References: <mmq6sEkAicO7Mc5FKkk5tcRVJDU6qtjYoyySho56F80=.aea5db50-0ec5-4e27-944e-2750af3d0bd7@github.com>
 <y40IwH73VtKykT-naUHOxF200W416N6flAktzEAUGtY=.bbe5f7d5-cf5a-4d72-8d24-b4b25697e38d@github.com>
Message-ID: <UpcWrrP1XNtFwYlKm4KFg2NFNfxyJVHoY8K31PHs4X4=.3a028d4c-aeed-4bae-8b88-e96e0cb1081b@github.com>

On Mon, 26 Jun 2023 10:21:12 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> This change adds management of retained regions, i.e. trying to evacuate evacuation failed regions asap.
>> 
>> The advantage is that evacuation failed regions do not need to wait until the next marking to be cleaned out; as they are often very sparsely occupied (often being eden regions), this occupies a lot of space, potentially causing additional evacuation failures later on.
>> Another use of this change will be region pinning, which are basically evacuation failed regions that can not be reclaimed as long as they are pinned - however as soon as they are unpinned, they should be reclaimed for the same reasons as well.
>> 
>> It consists of several behavioral changes:
>> 
>> During garbage collection:
>> 
>> ... in the Evacuation phase:
>> * always collect dirty cards into evacuation failed regions proactively. In tests, the amount of cards/live objects per evacuation failed region is typically very small. Dirty cards are always put into the global refinement buffer immediately, assuming that we will keep most if not all evacuation failed regions.
>> 
>> ... during Post Evacuation 2/Free Collection Set phase:
>> * determine whether the region will be retained (kept for "immediate" evacuation) or not. Highly occupied regions are assumed to stay (mostly) live at least until the next marking, so do not bother with them.
>> 
>> These "retained" regions are collected in a new "from retained" set in the collection set candidates and managed separately from "from marking" regions. Having the "from retained" and "from marking" sets separate in the collection set candidates is easier to manage than to use a single list and the picking stuff from it. Particularly wrt to making sure that mixed gcs preferentially pick from the "from marking" list first, then second from the "from retained" list.
>> 
>> ... determining the collection set during the pause:
>>   * during gc, the collection set is preferentially (first) populated with regions from the "from marking" candidates (these are the important regions to get cleaned out), second from the "from retained" list.
>>   * g1 reserves up to 20% of max gc pause time for retained regions as optional candidates (this is a random number) to make sure that these are cleared out asap to free memory. There is also a minimum number of regions to take from the retained regions list.
>> 
>> During marking
>> 
>> ... changes to marking proper
>> * retained regions will not be marked through during concurrent mark, i.e. they are considered outside of ...
>
> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:
> 
>   ayang review:
>   - do not add retained regions time during base time calculation when finalizing young gen
>   - add marking state (tams, bitmap, live bytes) verification at the end of a concurrent start pause (with -XX:+VerifyAfterGC)

During review, @albertnetymk found that there is a bug in base time calculation when finalizing the young generation: it added retained regions time, which is wrong. Evacuating retained regions is optional and should not count there.

There has also been the question why the policy to take retained regions is different from old regions: as described earlier, retained regions are considered fairly optional to take, and any retained region that one takes is better than the current handling. It is also very hard to come up with a good policy that subsumes both from-marking regions and retained regions; this change does not even attempt that. The current policy for retained regions uses magic constants at this time based on experience that while we want these regions be fairly optional, we still want to account for them when determining eden size somewhat.

Then there has been the question about `ClearRetainedRegionData` again and what marking expects at mark start for particular regions:
* regions that are not going to be marked through need `tams` at `bottom()`, no marks on the bitmap and their `liveness` value zero.
* regions that are going to be marked through need `tams` at `top()`, and either no marks on the bitmap and their `liveness` value zero OR marks on the bitmap and their `liveness` value correspond to the total size of the marked objects. This is the case for evacuation failed regions that are not retained (or, _before_ this change, all evacuation failed regions). There is now some code to verify that during `VerifyAfterGC`.

This verification passed tier 1-5 without any special flag and with all verification (before/during/after including this new verification) on plus `G1EvacuationFailureALot` enabled.

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

PR Comment: https://git.openjdk.org/jdk/pull/14220#issuecomment-1607177624

From rkennke at openjdk.org  Mon Jun 26 11:05:49 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Mon, 26 Jun 2023 11:05:49 GMT
Subject: RFR: 8305896: Alternative full GC forwarding [v50]
In-Reply-To: <yFs73BPFgB89xCPY4k63X4VTz13N8ELJf1lGQlE6UpA=.85ee4f25-a4ee-41d0-b4c2-ed9ff2cb1bb1@github.com>
References: <yFs73BPFgB89xCPY4k63X4VTz13N8ELJf1lGQlE6UpA=.85ee4f25-a4ee-41d0-b4c2-ed9ff2cb1bb1@github.com>
Message-ID: <ovTiZwWAxkNV2QXxUEJYqDJuByICykp3suDcWgvn_w0=.2650cdbf-c874-4db3-a915-02f2956e7a52@github.com>

> Currently, the full-GC modes of Serial, Shenandoah and G1 GCs are forwarding objects by over-writing the object header with the new object location. Unfortunately, for compact object headers ([JDK-8294992](https://bugs.openjdk.org/browse/JDK-8294992)) this would not work, because the crucial class information is also stored in the header, and we could no longer iterate over objects until the headers would be restored. Also, the preserved-headers tables would grow quite large.
> 
> I propose to use an alternative algorithm for full-GC (sliding-GC) forwarding that uses a special encoding so that the forwarding information fits into the lowest 32 bits of the header.
> 
> It exploits the insight that, with sliding GCs, objects from one region will only ever be forwarded to one of two possible target regions. For this to work, we need to divide the heap into equal-sized regions. This is already the case for Shenandoah and G1, and can easily be overlaid for Serial GC, by assuming either the whole heap as a single region (if it fits) or by using SpaceAlignment-sized virtual regions.
> 
> We also build and maintain a table that has N elements, where N is the number of regions. Each entry is two addresses, which are the start-address of the possible target regions for each source region.
> 
> With this, forwarding information would be encoded like this:
>  - Bits 0 and 1: same as before, we put in '11' to indicate that the object is forwarded.
>  - Bit 2: Used for 'fallback'-forwarding (see below)
>  - Bit 3: Selects the target region 0 or 1. Look up the base address in the table (see above)
>  - Bits 4..31 The number of heap words from the target base address
> 
> This works well for all sliding GCs in Serial, G1 and Shenandoah. The exception is in G1, there is a special mode called 'serial compaction' which acts as a last-last-ditch effort to squeeze more space out of the heap by re-forwarding the tails of the compaction chains. Unfortunately, this breaks the assumption of the sliding-forwarding-table. When that happens, we initialize a fallback table, which is a simple open hash-table, and set the Bit 2 in the forwarding to indicate that we shall look up the forwardee in the fallback-table.
> 
> All the table accesses can be done unsynchronized because:
> - Serial GC is single-threaded anyway
> - In G1 and Shenandoah, GC worker threads divide up the work such that each worker does disjoint sets of regions.
> - G1 serial compaction is single-threaded
> 
> The change introduces a new (experimental) flag -...

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

  Various cleanups

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13582/files
  - new: https://git.openjdk.org/jdk/pull/13582/files/01fc573f..34831781

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13582&range=49
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13582&range=48-49

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

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

From azafari at openjdk.org  Mon Jun 26 11:46:21 2023
From: azafari at openjdk.org (Afshin Zafari)
Date: Mon, 26 Jun 2023 11:46:21 GMT
Subject: RFR: 8281455: Change JVM options with small ranges from 64 to 32
 bits, for gc_globals.hpp [v4]
In-Reply-To: <PUZ-VNLsAs748dp0p0fknfkp6VxzSZRvBXp3cJvheko=.101c475e-a097-47ee-8ead-3464def85d7a@github.com>
References: <PUZ-VNLsAs748dp0p0fknfkp6VxzSZRvBXp3cJvheko=.101c475e-a097-47ee-8ead-3464def85d7a@github.com>
Message-ID: <AUBL2o3VbTCh1_fXm4UsZd5NkiHw3TFuA9wURgQjBFQ=.e5044dc3-4302-4ec7-b7ee-75bc3ba60fb3@github.com>

> The `uintx/intx` options whose ranges are small enough are changed to `uint/int`, otherwise gcc complains 
> when `-Wconversion` is used in build.
> Their uses in printf formats are changed accordingly.
> 
> ### Tests
> Locally hotspot:tier1 tested on linux-x64
> mach5 tiers 1-4 on Linux and Windows 64bits platforms passed.

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

  review comments applied.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14259/files
  - new: https://git.openjdk.org/jdk/pull/14259/files/97577d9d..cbe66aca

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

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

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

From ayang at openjdk.org  Mon Jun 26 12:16:05 2023
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Mon, 26 Jun 2023 12:16:05 GMT
Subject: RFR: 8310541: G1: Remove redundant check in
 G1Policy::need_to_start_conc_mark
In-Reply-To: <MBQ_rNMGnCnDdotCVqOeBeWRjommUy7wpBvnY7Jo7lo=.69c2328f-254a-44ce-b0a3-38fa4a5a29ff@github.com>
References: <MBQ_rNMGnCnDdotCVqOeBeWRjommUy7wpBvnY7Jo7lo=.69c2328f-254a-44ce-b0a3-38fa4a5a29ff@github.com>
Message-ID: <q4LOrvh5Nl7BoOs_E2HscvtSYrvVmLrRs1B-OitgYpA=.0d8c0bdb-ba2c-4b8a-ade1-f080a34417a7@github.com>

On Wed, 21 Jun 2023 13:24:58 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple removing a redundant check, which has already been covered in the early-return part.

Thanks for the review.

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

PR Comment: https://git.openjdk.org/jdk/pull/14588#issuecomment-1607343888

From ayang at openjdk.org  Mon Jun 26 12:17:16 2023
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Mon, 26 Jun 2023 12:17:16 GMT
Subject: RFR: 8310354: G1: Annotate G1MMUTracker::when_sec with const
In-Reply-To: <8m9-PL-wJR35jrDel3faUh5JTcLWqZqW-6bVytOYvU4=.2bf87dec-7067-410e-bb16-70ad32aeed37@github.com>
References: <8m9-PL-wJR35jrDel3faUh5JTcLWqZqW-6bVytOYvU4=.2bf87dec-7067-410e-bb16-70ad32aeed37@github.com>
Message-ID: <PL8o0VDvvsz12MSD6UYQ2-a8Hd-L3rnKpj0mRAfVlwM=.e0072572-5318-48c6-b85d-26b06cae4ea7@github.com>

On Tue, 20 Jun 2023 09:52:43 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simply adding `const` to G1MMUTracker APIs.

Thanks for the review.

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

PR Comment: https://git.openjdk.org/jdk/pull/14554#issuecomment-1607343300

From ayang at openjdk.org  Mon Jun 26 12:17:17 2023
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Mon, 26 Jun 2023 12:17:17 GMT
Subject: Integrated: 8310354: G1: Annotate G1MMUTracker::when_sec with const
In-Reply-To: <8m9-PL-wJR35jrDel3faUh5JTcLWqZqW-6bVytOYvU4=.2bf87dec-7067-410e-bb16-70ad32aeed37@github.com>
References: <8m9-PL-wJR35jrDel3faUh5JTcLWqZqW-6bVytOYvU4=.2bf87dec-7067-410e-bb16-70ad32aeed37@github.com>
Message-ID: <YRsrmsxkLm7AgMMtjnjZfd2hj7cGkJdgLGemF_6sDuc=.7122bc1c-35f9-455d-8f5b-bcf025c1323a@github.com>

On Tue, 20 Jun 2023 09:52:43 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simply adding `const` to G1MMUTracker APIs.

This pull request has now been integrated.

Changeset: 5271f4de
Author:    Albert Mingkun Yang <ayang at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/5271f4def68a7ad5003c597c60db29fbe9e2742b
Stats:     8 lines in 2 files changed: 0 ins; 0 del; 8 mod

8310354: G1: Annotate G1MMUTracker::when_sec with const

Reviewed-by: tschatzl, kbarrett

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

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

From ayang at openjdk.org  Mon Jun 26 12:19:11 2023
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Mon, 26 Jun 2023 12:19:11 GMT
Subject: Integrated: 8310541: G1: Remove redundant check in
 G1Policy::need_to_start_conc_mark
In-Reply-To: <MBQ_rNMGnCnDdotCVqOeBeWRjommUy7wpBvnY7Jo7lo=.69c2328f-254a-44ce-b0a3-38fa4a5a29ff@github.com>
References: <MBQ_rNMGnCnDdotCVqOeBeWRjommUy7wpBvnY7Jo7lo=.69c2328f-254a-44ce-b0a3-38fa4a5a29ff@github.com>
Message-ID: <35sbOvQSzjHB-Tr3t1FLITVeYDLiFyghVxwh_nOWjTA=.52493f36-ae20-4e43-8526-9b1efe2be0fc@github.com>

On Wed, 21 Jun 2023 13:24:58 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple removing a redundant check, which has already been covered in the early-return part.

This pull request has now been integrated.

Changeset: c1c5bd0f
Author:    Albert Mingkun Yang <ayang at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c1c5bd0faf7e1db1b43d4c7a0b53d4d5e91d8585
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8310541: G1: Remove redundant check in G1Policy::need_to_start_conc_mark

Reviewed-by: tschatzl, kbarrett

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

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

From coleenp at openjdk.org  Mon Jun 26 13:32:12 2023
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 26 Jun 2023 13:32:12 GMT
Subject: RFR: 8281455: Change JVM options with small ranges from 64 to 32
 bits, for gc_globals.hpp [v2]
In-Reply-To: <u779K6r5ZiaojL_5nNXp8op9iL4sgkBj72iY0mw550I=.70e615dc-8b83-4ae5-9b09-d501565907bc@github.com>
References: <PUZ-VNLsAs748dp0p0fknfkp6VxzSZRvBXp3cJvheko=.101c475e-a097-47ee-8ead-3464def85d7a@github.com>
 <XMUVdBeWfiSjnXl3nWjC0Ew01rxKBb_dCV7f8EFtdwE=.4d42e4d6-ea04-46a2-9019-cf895c271290@github.com>
 <lqB8iLQvOz8mpMo2103eL3NNQ_5jSfVg4Aq-Y-YicyU=.c9d3b7e4-bfc0-4e3d-a5ab-7f41ebfee510@github.com>
 <_ZMPXReZSPE3pSM3xX0DEFb9e-LrJejAz1Q_aJ8-uJA=.26fd29f8-9199-43ef-80cc-7af62bd2612b@github.com>
 <WO9m9pV9iW-THVCIYBOA_oUM-cgptz_JBTO_8XN-j_U=.69f0b579-6b5e-4180-ab2c-223c7cb2b8f1@github.com>
 <u779K6r5ZiaojL_5nNXp8op9iL4sgkBj72iY0mw550I=.70e615dc-8b83-4ae5-9b09-d501565907bc@github.com>
Message-ID: <ByxPRRXMKw0U-Rk6x045-bsNcFC6sDP9YbUdSl0U83I=.c940edb4-a228-4289-9ecd-910780363410@github.com>

On Fri, 9 Jun 2023 14:30:00 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> I'm not seeing such a block?  Neither in the current version nor in several recent versions.  And I didn't
>> find `__USE_MISC` anywhere in the JDK.  I did find what it's for and where it's supposed to come from:
>> https://stackoverflow.com/questions/10231885/what-is-use-misc-macro-used-for
>
> I was curious and found it in /usr/include/x86_64-linux-gnu/sys/types.h on ubuntu. I guess it needs cleanup because it might not be defined with USE_MISC?  There are too many int type names to choose from for int.  Why does it say "Old compatibility names for C types."? Should we even be using uint ? I don't see it in https://en.cppreference.com/w/cpp/language/types - should we prefer "unsigned"?

This NEEDS_CLEANUP block shouldn't be part of this change.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14259#discussion_r1242196453

From azafari at openjdk.org  Mon Jun 26 14:03:10 2023
From: azafari at openjdk.org (Afshin Zafari)
Date: Mon, 26 Jun 2023 14:03:10 GMT
Subject: RFR: 8281455: Change JVM options with small ranges from 64 to 32
 bits, for gc_globals.hpp [v3]
In-Reply-To: <cr1iWZjlPNM3NP67c0HF4kZNYZ5qoaChx5BpC_frh90=.e390b436-4aa2-484c-81fc-364557839f06@github.com>
References: <PUZ-VNLsAs748dp0p0fknfkp6VxzSZRvBXp3cJvheko=.101c475e-a097-47ee-8ead-3464def85d7a@github.com>
 <Oq3b-RXjrUQa3je7gtFx5yp03T9Pqqsofb5c4Mmz4Pg=.53e4b5ec-d377-415f-95e4-27d8210ee8e9@github.com>
 <cr1iWZjlPNM3NP67c0HF4kZNYZ5qoaChx5BpC_frh90=.e390b436-4aa2-484c-81fc-364557839f06@github.com>
Message-ID: <o2dvIcWRPwX8zo3c58gZeHSTXz4fmtwIVUAUYdqs2hw=.d9481297-01ab-4e34-8c5c-0b417baf27aa@github.com>

On Fri, 9 Jun 2023 08:54:50 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   review comments applied
>
> src/hotspot/share/gc/g1/g1ConcurrentMark.cpp line 2311:
> 
>> 2309:   size_t target_size;
>> 2310:   if (partially) {
>> 2311:     target_size = MIN2((size_t)_task_queue->max_elems()/3, GCDrainStackTargetSize);
> 
> I was hoping max_elems() wouldn't need a cast.  Fixing that seems like it might be one of those long
> and more complicated threads I was referring to earlier.

The `max_elems()` return `uint` and the cast is needed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14259#discussion_r1242251737

From ayang at openjdk.org  Mon Jun 26 19:53:03 2023
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Mon, 26 Jun 2023 19:53:03 GMT
Subject: RFR: 8047998: Abort the vm if MaxNewSize is not the same as
 NewSize when MaxHeapSize is the same as InitialHeapSize
In-Reply-To: <8_SgxgkFwp1aLE3vSYWZgUZDEUP46s2388Iprrd3YZo=.96913f43-9388-475d-935c-3ac54ed58ba2@github.com>
References: <x0XiQ_v_hgW3zTJeni10F93buDr224ALn-oqzJeH0j8=.48b829a2-dd45-48d1-bbdd-3cfb3037ebea@github.com>
 <WDxLZeT7k2Etw31d_BTVnG8HXfiHxrrWtavbKX5X51c=.69ea4c1d-ea2a-48a5-9362-6d887d05b4b6@github.com>
 <72Ws56U5CQtUvtu54vhJGMRbfO87GRq5yNgIAUkhsYo=.eab80189-566f-4625-a6b6-2216f801c44e@github.com>
 <8_SgxgkFwp1aLE3vSYWZgUZDEUP46s2388Iprrd3YZo=.96913f43-9388-475d-935c-3ac54ed58ba2@github.com>
Message-ID: <gu1E9VxujEqqHWikG0ud7RW1f7JczDdo7ndITXAaqnc=.ee8d6ccc-2da9-4060-aecf-274f450a680b@github.com>

On Sun, 11 Jun 2023 07:57:01 GMT, Guoxiong Li <gli at openjdk.org> wrote:

>>> The condition MaxHeapSize == InitialHeapSize is often meet
>> 
>> True, but additionally specifying both `NewSize` and `MaxNewSize` is uncommon, IMO.
>> 
>>> I do worry that such exiting may break some current online systems
>> 
>> Actually, I think it's desirable to fail loudly if the JVM cmd flags contain errors. Hard to say whether this is an error or not, but debugging suboptimal performance (from incorrect heap/generation-size) is much harder. Therefore, notifying developers at jvm-startup when cmd flags can't be satisfied might be appreciated. Again, this setup should be rare.
>> 
>> (I agree this is subjective.)
>
> @albertnetymk Thanks for creating the CSR. It may be good to mark it as `PROPOSED` now.

@lgxbslgx The CSR has been approved.

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

PR Comment: https://git.openjdk.org/jdk/pull/13876#issuecomment-1608134833

From stefank at openjdk.org  Tue Jun 27 08:28:18 2023
From: stefank at openjdk.org (Stefan Karlsson)
Date: Tue, 27 Jun 2023 08:28:18 GMT
Subject: [jdk21] RFR: 8310194: Generational ZGC: Lock-order asserts in JVMTI
 IterateThroughHeap
Message-ID: <gxtzLC2-3xlVQQNto46VGZPOjc8MD-Rp2yrrkleRjsY=.ac10e0bc-ce9e-4718-b8e7-e6aa63e326c6@github.com>

8310194: Generational ZGC: Lock-order asserts in JVMTI IterateThroughHeap

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

Commit messages:
 - Backport 4e4e586dac3f4be15a6488a6b72aa9e2cd5d43db

Changes: https://git.openjdk.org/jdk21/pull/69/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk21&pr=69&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8310194
  Stats: 203 lines in 5 files changed: 103 ins; 37 del; 63 mod
  Patch: https://git.openjdk.org/jdk21/pull/69.diff
  Fetch: git fetch https://git.openjdk.org/jdk21.git pull/69/head:pull/69

PR: https://git.openjdk.org/jdk21/pull/69

From ayang at openjdk.org  Tue Jun 27 12:06:21 2023
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Tue, 27 Jun 2023 12:06:21 GMT
Subject: RFR: 8310946: G1: Refactor G1Policy::next_gc_should_be_mixed
Message-ID: <tHoboYNg5KG5PVM-R8-jquLd-xcSrTjuCFVsnC_WUSQ=.f0868b14-53d0-4958-8ae1-b3235493dc56@github.com>

Simple restructuring around `next_gc_should_be_mixed`.

(After such refactoring, I also tend to think this predicate makes more sense in the caller context, i.e. `bool is_next_gc_mixed = has_marking_candidates();`. For example, one of the call site even asserts `assert(!candidates()->has_more_marking_candidates(),`. Ofc, this is rather subjective.)

Test: hotspot_gc

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

Commit messages:
 - g1-next-mixed

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

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

From tschatzl at openjdk.org  Tue Jun 27 13:58:17 2023
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Tue, 27 Jun 2023 13:58:17 GMT
Subject: RFR: 8281455: Change JVM options with small ranges from 64 to 32
 bits, for gc_globals.hpp [v4]
In-Reply-To: <AUBL2o3VbTCh1_fXm4UsZd5NkiHw3TFuA9wURgQjBFQ=.e5044dc3-4302-4ec7-b7ee-75bc3ba60fb3@github.com>
References: <PUZ-VNLsAs748dp0p0fknfkp6VxzSZRvBXp3cJvheko=.101c475e-a097-47ee-8ead-3464def85d7a@github.com>
 <AUBL2o3VbTCh1_fXm4UsZd5NkiHw3TFuA9wURgQjBFQ=.e5044dc3-4302-4ec7-b7ee-75bc3ba60fb3@github.com>
Message-ID: <qE5RUARFsSAI66KmqZBifY3kwVvGkkAHjolMiIVC8Lk=.2bce876f-023c-4aad-8336-a8aa378273c5@github.com>

On Mon, 26 Jun 2023 11:46:21 GMT, Afshin Zafari <azafari at openjdk.org> wrote:

>> The `uintx/intx` options whose ranges are small enough are changed to `uint/int`, otherwise gcc complains 
>> when `-Wconversion` is used in build.
>> Their uses in printf formats are changed accordingly.
>> 
>> ### Tests
>> Locally hotspot:tier1 tested on linux-x64
>> mach5 tiers 1-4 on Linux and Windows 64bits platforms passed.
>
> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review comments applied.

Lgtm, it's a step forward to cleaning up the gc_globals.hpp types/ranges.

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

Marked as reviewed by tschatzl (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14259#pullrequestreview-1500949561

From ayang at openjdk.org  Tue Jun 27 14:08:12 2023
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Tue, 27 Jun 2023 14:08:12 GMT
Subject: [jdk21] RFR: 8310194: Generational ZGC: Lock-order asserts in
 JVMTI IterateThroughHeap
In-Reply-To: <gxtzLC2-3xlVQQNto46VGZPOjc8MD-Rp2yrrkleRjsY=.ac10e0bc-ce9e-4718-b8e7-e6aa63e326c6@github.com>
References: <gxtzLC2-3xlVQQNto46VGZPOjc8MD-Rp2yrrkleRjsY=.ac10e0bc-ce9e-4718-b8e7-e6aa63e326c6@github.com>
Message-ID: <AYdwcWLS5P-p336ka1Xz_sXm_oClIVEhBX6h_WoZeBk=.3ff32a4c-a17d-423e-a504-55e7e4c523ef@github.com>

On Tue, 27 Jun 2023 08:20:27 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> 8310194: Generational ZGC: Lock-order asserts in JVMTI IterateThroughHeap

Marked as reviewed by ayang (Reviewer).

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

PR Review: https://git.openjdk.org/jdk21/pull/69#pullrequestreview-1500972097

From coleenp at openjdk.org  Tue Jun 27 15:49:08 2023
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 27 Jun 2023 15:49:08 GMT
Subject: RFR: 8281455: Change JVM options with small ranges from 64 to 32
 bits, for gc_globals.hpp [v4]
In-Reply-To: <AUBL2o3VbTCh1_fXm4UsZd5NkiHw3TFuA9wURgQjBFQ=.e5044dc3-4302-4ec7-b7ee-75bc3ba60fb3@github.com>
References: <PUZ-VNLsAs748dp0p0fknfkp6VxzSZRvBXp3cJvheko=.101c475e-a097-47ee-8ead-3464def85d7a@github.com>
 <AUBL2o3VbTCh1_fXm4UsZd5NkiHw3TFuA9wURgQjBFQ=.e5044dc3-4302-4ec7-b7ee-75bc3ba60fb3@github.com>
Message-ID: <P_FdbRQA7OH8QEkxIWQezPLuL5PZluYWBABaBuCDMGw=.294e0c2f-9917-4327-afdd-e689e6dd1c24@github.com>

On Mon, 26 Jun 2023 11:46:21 GMT, Afshin Zafari <azafari at openjdk.org> wrote:

>> The `uintx/intx` options whose ranges are small enough are changed to `uint/int`, otherwise gcc complains 
>> when `-Wconversion` is used in build.
>> Their uses in printf formats are changed accordingly.
>> 
>> ### Tests
>> Locally hotspot:tier1 tested on linux-x64
>> mach5 tiers 1-4 on Linux and Windows 64bits platforms passed.
>
> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review comments applied.

This looks good and definitely a step forward.

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

Marked as reviewed by coleenp (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14259#pullrequestreview-1501297079

From azafari at openjdk.org  Tue Jun 27 15:58:18 2023
From: azafari at openjdk.org (Afshin Zafari)
Date: Tue, 27 Jun 2023 15:58:18 GMT
Subject: RFR: 8281455: Change JVM options with small ranges from 64 to 32
 bits, for gc_globals.hpp [v4]
In-Reply-To: <AUBL2o3VbTCh1_fXm4UsZd5NkiHw3TFuA9wURgQjBFQ=.e5044dc3-4302-4ec7-b7ee-75bc3ba60fb3@github.com>
References: <PUZ-VNLsAs748dp0p0fknfkp6VxzSZRvBXp3cJvheko=.101c475e-a097-47ee-8ead-3464def85d7a@github.com>
 <AUBL2o3VbTCh1_fXm4UsZd5NkiHw3TFuA9wURgQjBFQ=.e5044dc3-4302-4ec7-b7ee-75bc3ba60fb3@github.com>
Message-ID: <qudRozZoxI3R9z9UFqYqjXETxdfveP2Lxp4Oocla0EI=.5a703b95-eac2-4e39-8b61-43184f053d69@github.com>

On Mon, 26 Jun 2023 11:46:21 GMT, Afshin Zafari <azafari at openjdk.org> wrote:

>> The `uintx/intx` options whose ranges are small enough are changed to `uint/int`, otherwise gcc complains 
>> when `-Wconversion` is used in build.
>> Their uses in printf formats are changed accordingly.
>> 
>> ### Tests
>> Locally hotspot:tier1 tested on linux-x64
>> mach5 tiers 1-4 on Linux and Windows 64bits platforms passed.
>
> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review comments applied.

Thank you Coleen, Kim, Thomas and Amit for your comments and reviewing this PR.

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

PR Comment: https://git.openjdk.org/jdk/pull/14259#issuecomment-1609796995

From azafari at openjdk.org  Tue Jun 27 15:58:20 2023
From: azafari at openjdk.org (Afshin Zafari)
Date: Tue, 27 Jun 2023 15:58:20 GMT
Subject: Integrated: 8281455: Change JVM options with small ranges from 64 to
 32 bits, for gc_globals.hpp
In-Reply-To: <PUZ-VNLsAs748dp0p0fknfkp6VxzSZRvBXp3cJvheko=.101c475e-a097-47ee-8ead-3464def85d7a@github.com>
References: <PUZ-VNLsAs748dp0p0fknfkp6VxzSZRvBXp3cJvheko=.101c475e-a097-47ee-8ead-3464def85d7a@github.com>
Message-ID: <OqCmMpJRW49vMNPp1vK-XSVvS5oPxN-MsxTn6Kqq6xk=.b4571d7d-6a09-4092-ac6b-b71801a05204@github.com>

On Thu, 1 Jun 2023 11:15:48 GMT, Afshin Zafari <azafari at openjdk.org> wrote:

> The `uintx/intx` options whose ranges are small enough are changed to `uint/int`, otherwise gcc complains 
> when `-Wconversion` is used in build.
> Their uses in printf formats are changed accordingly.
> 
> ### Tests
> Locally hotspot:tier1 tested on linux-x64
> mach5 tiers 1-4 on Linux and Windows 64bits platforms passed.

This pull request has now been integrated.

Changeset: 7ce967a1
Author:    Afshin Zafari <azafari at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/7ce967a10c62d300a11906c1d71def33f4f57719
Stats:     59 lines in 10 files changed: 0 ins; 1 del; 58 mod

8281455: Change JVM options with small ranges from 64 to 32 bits, for gc_globals.hpp

Reviewed-by: tschatzl, coleenp

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

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

From stefank at openjdk.org  Wed Jun 28 07:38:13 2023
From: stefank at openjdk.org (Stefan Karlsson)
Date: Wed, 28 Jun 2023 07:38:13 GMT
Subject: [jdk21] RFR: 8310194: Generational ZGC: Lock-order asserts in
 JVMTI IterateThroughHeap
In-Reply-To: <gxtzLC2-3xlVQQNto46VGZPOjc8MD-Rp2yrrkleRjsY=.ac10e0bc-ce9e-4718-b8e7-e6aa63e326c6@github.com>
References: <gxtzLC2-3xlVQQNto46VGZPOjc8MD-Rp2yrrkleRjsY=.ac10e0bc-ce9e-4718-b8e7-e6aa63e326c6@github.com>
Message-ID: <oKel8PBtBtLPcP4TTm4Ur5OeWEA8qZkGKaJp54cW5q8=.1ebcaa15-2181-449f-8783-b1956b5f4235@github.com>

On Tue, 27 Jun 2023 08:20:27 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> 8310194: Generational ZGC: Lock-order asserts in JVMTI IterateThroughHeap

Thanks for the review!

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

PR Comment: https://git.openjdk.org/jdk21/pull/69#issuecomment-1610915771

From stefank at openjdk.org  Wed Jun 28 07:38:14 2023
From: stefank at openjdk.org (Stefan Karlsson)
Date: Wed, 28 Jun 2023 07:38:14 GMT
Subject: [jdk21] Integrated: 8310194: Generational ZGC: Lock-order asserts in
 JVMTI IterateThroughHeap
In-Reply-To: <gxtzLC2-3xlVQQNto46VGZPOjc8MD-Rp2yrrkleRjsY=.ac10e0bc-ce9e-4718-b8e7-e6aa63e326c6@github.com>
References: <gxtzLC2-3xlVQQNto46VGZPOjc8MD-Rp2yrrkleRjsY=.ac10e0bc-ce9e-4718-b8e7-e6aa63e326c6@github.com>
Message-ID: <qbpfEMMqthg49vSh5lqsDkKmNdrtIG1YKb8Eq29wLH8=.4038de94-fcf6-4fe6-ae7f-d829d5e7e730@github.com>

On Tue, 27 Jun 2023 08:20:27 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> 8310194: Generational ZGC: Lock-order asserts in JVMTI IterateThroughHeap

This pull request has now been integrated.

Changeset: 0903c8dd
Author:    Stefan Karlsson <stefank at openjdk.org>
URL:       https://git.openjdk.org/jdk21/commit/0903c8dd602a63f6f6ae7be6cb6ed4ddabbdb0d7
Stats:     203 lines in 5 files changed: 103 ins; 37 del; 63 mod

8310194: Generational ZGC: Lock-order asserts in JVMTI IterateThroughHeap

Reviewed-by: ayang
Backport-of: 4e4e586dac3f4be15a6488a6b72aa9e2cd5d43db

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

PR: https://git.openjdk.org/jdk21/pull/69

From shade at openjdk.org  Wed Jun 28 10:26:08 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 28 Jun 2023 10:26:08 GMT
Subject: RFR: 8310939: [c1] The visibility of write-volatile requires
 membar_volatile instead of membar
In-Reply-To: <NUKzWI7J5q7CrCcBo0dnv1VmOcqGc17Y-iijzBSICwk=.b8ad83f3-621d-41d4-863a-c67817308061@github.com>
References: <NUKzWI7J5q7CrCcBo0dnv1VmOcqGc17Y-iijzBSICwk=.b8ad83f3-621d-41d4-863a-c67817308061@github.com>
Message-ID: <0EzfvxXA6lnz5NpmSeX4ruJ4FoaZEuWPSw0HYlStFPI=.634b8f75-cb7f-4353-909b-400cdc7bcfe5@github.com>

On Tue, 27 Jun 2023 12:46:14 GMT, SUN Guoyun <duke at openjdk.org> wrote:

> For c1 now, a volatile write case:
> 
> membar_release // LoadStore | StoreStore
> write volatile
> membar
> 
> Just like c2, here `membar` should be defined `membar_volatile` clearly, then for risc-v, ppc and loongarch can use StoreLoad for `membar_volatile` for better performance.
> 
> Testing:
> GHA testing
> jtreg tier1-3 for loongarch64

We need to be really careful about this, because we had the issues with inconsistent barrier schemes in C1 and C2:
https://bugs.openjdk.org/browse/JDK-8179954

Modern jcstress is able to run tests with one side compiled by C1 and another one compiled by C2, exactly to catch these things. So I suggest you get at least one clean jcstress run with this patch, at least on AArch64 (with both `-UseLSE` and `+UseLSE`).

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

PR Comment: https://git.openjdk.org/jdk/pull/14677#issuecomment-1611151505

From tschatzl at openjdk.org  Wed Jun 28 11:44:05 2023
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Wed, 28 Jun 2023 11:44:05 GMT
Subject: RFR: 8310946: G1: Refactor G1Policy::next_gc_should_be_mixed
In-Reply-To: <tHoboYNg5KG5PVM-R8-jquLd-xcSrTjuCFVsnC_WUSQ=.f0868b14-53d0-4958-8ae1-b3235493dc56@github.com>
References: <tHoboYNg5KG5PVM-R8-jquLd-xcSrTjuCFVsnC_WUSQ=.f0868b14-53d0-4958-8ae1-b3235493dc56@github.com>
Message-ID: <9YVROjx79trIXHkxfQw4LHpj4MnJh2q8CMFn1KCSPIE=.59fa59ac-c0f1-4904-b943-f5fa058a931c@github.com>

On Tue, 27 Jun 2023 11:58:34 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple restructuring around `next_gc_should_be_mixed`.
> 
> (After such refactoring, I also tend to think this predicate makes more sense in the caller context, i.e. `bool is_next_gc_mixed = has_marking_candidates();`. For example, one of the call site even asserts `assert(!candidates()->has_more_marking_candidates(),`. Ofc, this is rather subjective.)
> 
> Test: hotspot_gc

Marked as reviewed by tschatzl (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/14673#pullrequestreview-1502895373

From duke at openjdk.org  Thu Jun 29 03:14:35 2023
From: duke at openjdk.org (SUN Guoyun)
Date: Thu, 29 Jun 2023 03:14:35 GMT
Subject: RFR: 8310939: [c1] The visibility of write-volatile requires
 membar_volatile instead of membar
In-Reply-To: <0EzfvxXA6lnz5NpmSeX4ruJ4FoaZEuWPSw0HYlStFPI=.634b8f75-cb7f-4353-909b-400cdc7bcfe5@github.com>
References: <NUKzWI7J5q7CrCcBo0dnv1VmOcqGc17Y-iijzBSICwk=.b8ad83f3-621d-41d4-863a-c67817308061@github.com>
 <0EzfvxXA6lnz5NpmSeX4ruJ4FoaZEuWPSw0HYlStFPI=.634b8f75-cb7f-4353-909b-400cdc7bcfe5@github.com>
Message-ID: <OBJ_iEhFWoQuuaK482XT164KF6hrlRB5R5cbvUXT-fw=.a47b5c8a-d302-4675-b216-d273e806b3c4@github.com>

On Wed, 28 Jun 2023 10:22:57 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> For c1 now, a volatile write case:
>> 
>> membar_release // LoadStore | StoreStore
>> write volatile
>> membar
>> 
>> Just like c2, here `membar` should be defined `membar_volatile` clearly, then for risc-v, ppc and loongarch can use StoreLoad for `membar_volatile` for better performance.
>> 
>> Testing:
>> GHA testing
>> jtreg tier1-3 for loongarch64
>
> We need to be really careful about this, because we had the issues with inconsistent barrier schemes in C1 and C2:
> https://bugs.openjdk.org/browse/JDK-8179954
> 
> Modern jcstress is able to run tests with one side compiled by C1 and another one compiled by C2, exactly to catch these things. So I suggest you get at least one clean jcstress run with this patch, at least on AArch64 (with both `-UseLSE` and `+UseLSE`).

@shipilev thanks for the reminder.   After the patch for AArch64, we also can see

  STLR #1 -> [x] | STLR #1 -> [y]

  DMB | DMB
  LDR [y] -> r1 | LDR [x] -> r1
  DMB LD | DMB LD
  
 On AArch64, Assembler::AnyAny and Assembler::StoreLoad also be defined ISH, so not found regression. And this patch can not cause regression on X86 and S390, because also used same instruction in membar() and membar_volatile().

I had run jcstress `org.openjdk.jcstress.samples.jmm.basic.BasicJMM_07_Consensus` on AArch64 and LoongArch64, and result is

`(Results: 102 planned; 102 passed, 0 failed, 0 soft errs, 0 hard errs)`

But I am not sure for risc-v, ppc. Maybe please @RealFYang @TheRealMDoerr help to confirm this patch.

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

PR Comment: https://git.openjdk.org/jdk/pull/14677#issuecomment-1612350131

From naoto at openjdk.org  Thu Jun 29 19:28:05 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 29 Jun 2023 19:28:05 GMT
Subject: RFR: 8309622: Re-examine the cache mechanism in BaseLocale [v4]
In-Reply-To: <5MqmN4P1TLKDCfXPhKWrH1b2FTgOXmjtKgd1bVXDd_M=.2000f20d-365d-48dc-bc37-45d8bcb9447f@github.com>
References: <5MqmN4P1TLKDCfXPhKWrH1b2FTgOXmjtKgd1bVXDd_M=.2000f20d-365d-48dc-bc37-45d8bcb9447f@github.com>
Message-ID: <_8ueUfakl3XtyZ-dDW36gd-fUokkoChbmBDqHvkSNDg=.ee46d7e2-8a11-4190-984e-31bb506d856a@github.com>

> This is stemming from the PR: https://github.com/openjdk/jdk/pull/14211 where aggressive GC can cause NPE in `BaseLocale$Key` class. I refactored the in-house cache with WeakHashMap, and removed the Key class as it is no longer needed (thus the original NPE will no longer be possible). Also with the new JMH test case, it gains some performance improvement:
> 
> (w/o fix)
> 
> Benchmark                       Mode  Cnt      Score     Error  Units
> LocaleCache.testForLanguageTag  avgt   20   5781.275 ? 569.580  ns/op
> LocaleCache.testLocaleOf        avgt   20  62564.079 ? 406.697  ns/op
> 
> (w/ fix)
> Benchmark                       Mode  Cnt      Score     Error  Units
> LocaleCache.testForLanguageTag  avgt   20   4801.175 ? 371.830  ns/op
> LocaleCache.testLocaleOf        avgt   20  60394.652 ? 352.471  ns/op

Naoto Sato 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 14 additional commits since the last revision:

 - Merge branch 'pull/14684' into JDK-8309622-Cache-BaseLocale
 - Use ReferencedKeyMap in place for LocaleObjectCache
 - Merge branch 'pull/14684' into JDK-8309622-Cache-BaseLocale
 - Addressing review comments
 - Addressing comments (test grouping, synchronization), minor optimization on loop lookup
 - minor comment fix
 - equals/hash fix, constructor simplification
 - Removed Key
 - minor fixup
 - Use WeakHashMap
 - ... and 4 more: https://git.openjdk.org/jdk/compare/8c52462a...870ec1fe

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14404/files
  - new: https://git.openjdk.org/jdk/pull/14404/files/ac6ea421..870ec1fe

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

  Stats: 39769 lines in 1438 files changed: 16937 ins; 14906 del; 7926 mod
  Patch: https://git.openjdk.org/jdk/pull/14404.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14404/head:pull/14404

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

From mdoerr at openjdk.org  Thu Jun 29 20:50:02 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Thu, 29 Jun 2023 20:50:02 GMT
Subject: RFR: 8310939: [c1] The visibility of write-volatile requires
 membar_volatile instead of membar
In-Reply-To: <NUKzWI7J5q7CrCcBo0dnv1VmOcqGc17Y-iijzBSICwk=.b8ad83f3-621d-41d4-863a-c67817308061@github.com>
References: <NUKzWI7J5q7CrCcBo0dnv1VmOcqGc17Y-iijzBSICwk=.b8ad83f3-621d-41d4-863a-c67817308061@github.com>
Message-ID: <a3Bapx06mGykqqwudviKz9FcZv5bhdLMdwdNGVylBB4=.fcd91e0e-ed9f-49bb-95ec-cad9ec64c725@github.com>

On Tue, 27 Jun 2023 12:46:14 GMT, SUN Guoyun <duke at openjdk.org> wrote:

> For c1 now, a volatile write case:
> 
> membar_release // LoadStore | StoreStore
> write volatile
> membar
> 
> Just like c2, here `membar` should be defined `membar_volatile` clearly, then for risc-v, ppc and loongarch can use StoreLoad for `membar_volatile` for better performance.
> 
> Testing:
> GHA testing
> jtreg tier1-3 for loongarch64

This doesn't change anything for PPC64 for the following reasons:
1. `support_IRIW_for_not_multiple_copy_atomic_cpu` is true
2. StoreLoad = fence = sync = membar_volatile
I wonder if a performance improvement can be measured on any other platform. I guess StoreLoad is typically so slow that other orderings don't matter?

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

PR Comment: https://git.openjdk.org/jdk/pull/14677#issuecomment-1613789870

From duke at openjdk.org  Fri Jun 30 01:30:53 2023
From: duke at openjdk.org (SUN Guoyun)
Date: Fri, 30 Jun 2023 01:30:53 GMT
Subject: RFR: 8310939: [c1] The visibility of write-volatile requires
 membar_volatile instead of membar
In-Reply-To: <NUKzWI7J5q7CrCcBo0dnv1VmOcqGc17Y-iijzBSICwk=.b8ad83f3-621d-41d4-863a-c67817308061@github.com>
References: <NUKzWI7J5q7CrCcBo0dnv1VmOcqGc17Y-iijzBSICwk=.b8ad83f3-621d-41d4-863a-c67817308061@github.com>
Message-ID: <B_o2_1Ywo1ywLP_-Y2gAKY5asjPUYPLGwr0FlF6-9OA=.d48bb3f2-257b-4bf6-92b7-88c8921954a1@github.com>

On Tue, 27 Jun 2023 12:46:14 GMT, SUN Guoyun <duke at openjdk.org> wrote:

> For c1 now, a volatile write case:
> 
> membar_release // LoadStore | StoreStore
> write volatile
> membar
> 
> Just like c2, here `membar` should be defined `membar_volatile` clearly, then for risc-v, ppc and loongarch can use StoreLoad for `membar_volatile` for better performance.
> 
> Testing:
> GHA testing
> jtreg tier1-3 for loongarch64

OK, thanks @TheRealIMDoerr for the confirm. This PR has performance advantages on LoongArch, because there are special StoreLoad instructions and full barrier instructions on LA, and the performance is different.

dbar 0x10 // Wait for earlier read-write (RW) operations complete before subsequent read-write (RW) operations
dbar 0x19 // Wait for earlier write (W) operations to complete before subsequent read (R) operations

Maybe I should write a performance test case for this PR.

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

PR Comment: https://git.openjdk.org/jdk/pull/14677#issuecomment-1613989958

From stuefe at openjdk.org  Fri Jun 30 07:13:53 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 30 Jun 2023 07:13:53 GMT
Subject: RFR: JDK-8310111: Shenandoah wastes memory when running with very
 large page sizes [v2]
In-Reply-To: <duqC-dtC4Y4EmWO9lT2BcxzKNwQRpR_jgAXGfQmvPts=.2a77f87b-dbad-4466-bc65-76fa87603717@github.com>
References: <g2vZQuNNbJJoSTc2tE8nZhcLf0muaoZLnkuKZEzHoZQ=.88748998-31db-44bb-a45f-d75e46a4247e@github.com>
 <duqC-dtC4Y4EmWO9lT2BcxzKNwQRpR_jgAXGfQmvPts=.2a77f87b-dbad-4466-bc65-76fa87603717@github.com>
Message-ID: <XMfbmirmHOH8w5Tm9Kmn9SeM83VJ3opamQapYsMRcqc=.57249c07-0a74-4a5c-aef1-3882fd3dcd1b@github.com>

On Tue, 20 Jun 2023 15:21:24 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> This proposal changes the reservation of bitmaps and region storage to reduce the wastage associated with running with very large page sizes (e.g. 1GB on x64, 512M on arm64) for both non-THP- and THP-mode.
>> 
>> This patch does:
>> - introducing the notion of "allowed overdraft factor" - allocations for a given page size are rejected if they would cause more wastage than the factor allows
>> - if it makes sense, it places mark- and aux-bitmap into a contiguous region to let them share a ginourmous page. E.g. for a heap of 16G, both bitmaps would now share a single GB page.
>> 
>> Examples:
>> 
>> Note: annoyingly, huge page usage does not show up in RSS. I therefore use a script that parses /proc/pid/smaps and counts hugepage usage to count cost for the following examples:
>> 
>> Example 1:
>> 
>> A machine configured with 1G pages (and nothing else). Heap is allocated with 1G pages, the bitmaps fall back to 4K pages because JVM figures 1GB would be wasted:
>> 
>> 
>> thomas at starfish$ ./images/jdk/bin/java -Xmx4600m -Xlog:pagesize -XX:+UseShenandoahGC -XX:+UseLargePages
>> ...
>> [0.028s][info][pagesize] Mark Bitmap: req_size=160M req_page_size=4K base=0x00007f8149fff000 size=160M page_size=4K
>> [0.028s][info][pagesize] Aux Bitmap: req_size=160M req_page_size=4K base=0x00007f813fffe000 size=160M page_size=4K
>> [0.028s][info][pagesize] Region Storage: req_size=320K req_page_size=4K base=0x00007f817c06f000 size=320K page_size=4K
>> 
>> 
>> Cost before: 8GB. Cost now: 5GB + (2*160M)
>> 
>> Example 2: JVM with 14GB heap: mark and aux bitmap together are large enough to justify another 1G page, so they share it. Notice how we also place the region storage on this page:
>> 
>> 
>> thomas at starfish:/shared/projects/openjdk/jdk-jdk/output-release$ ./images/jdk/bin/java -Xmx14g -Xlog:pagesize 
>> -XX:+UseShenandoahGC -XX:+UseLargePages -cp $REPROS_JAR de.stuefe.repros.Simple
>> [0.003s][info][pagesize] Heap: req_size=14G req_page_size=1G base=0x0000000480000000 size=14G page_size=1G
>> [0.003s][info][pagesize] Mark+Aux Bitmap: req_size=896M req_page_size=1G base=0x00007fee00000000 size=1G page_size=1G
>> [0.003s][info][pagesize] Region Storage: piggy-backing on Mark Bitmap: base=0x00007fee38000000 size=1792
>> <press key>
>> 
>> 
>> Cost before: 17GB. Cost now: 15GB.
>> 
>> From a bang-for-hugepages-buck multiples of 16GB are a sweet spot here since (on x64 with 1GB pages) since this allows us to put both 512m bitmaps onto a single huge page.
>> 
>> -----------
>> 
>> No test yet, since I wanted to se...
>
> Thomas Stuefe has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:
> 
>   start

@shipilev @rkennke do you have opinions or advice on this?

The patch is a bit complex, and most of the complexity stems from letting mark and aux bitmaps share one page if the page is gigantic enough. If I had retained them as individual reservations, things would be simpler.

Ability to share a page may enable us, in some situations, to use large pages where otherwise we would fall back to small pages. For example, let's say I run with a 16G heap. Each bitmap costs 512M. With page sharing, I can use a single GB page for both bitmaps, otherwise, I would have to fall back to use 2M or 4K pages.

Opinions?

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

PR Comment: https://git.openjdk.org/jdk/pull/14559#issuecomment-1614228862

From kbarrett at openjdk.org  Fri Jun 30 07:21:53 2023
From: kbarrett at openjdk.org (Kim Barrett)
Date: Fri, 30 Jun 2023 07:21:53 GMT
Subject: RFR: 8310946: G1: Refactor G1Policy::next_gc_should_be_mixed
In-Reply-To: <tHoboYNg5KG5PVM-R8-jquLd-xcSrTjuCFVsnC_WUSQ=.f0868b14-53d0-4958-8ae1-b3235493dc56@github.com>
References: <tHoboYNg5KG5PVM-R8-jquLd-xcSrTjuCFVsnC_WUSQ=.f0868b14-53d0-4958-8ae1-b3235493dc56@github.com>
Message-ID: <OgCw1VyiMPQEZCAXLHJklI4cuvFI8vtgrvizgBUSFG8=.b8f02aa1-dfa7-4f73-8c0c-fe8ebea74807@github.com>

On Tue, 27 Jun 2023 11:58:34 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple restructuring around `next_gc_should_be_mixed`.
> 
> (After such refactoring, I also tend to think this predicate makes more sense in the caller context, i.e. `bool is_next_gc_mixed = has_marking_candidates();`. For example, one of the call site even asserts `assert(!candidates()->has_more_marking_candidates(),`. Ofc, this is rather subjective.)
> 
> Test: hotspot_gc

Looks good.

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

Marked as reviewed by kbarrett (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14673#pullrequestreview-1506647322

From mbaesken at openjdk.org  Fri Jun 30 08:19:08 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 30 Jun 2023 08:19:08 GMT
Subject: RFR: JDK-8311026: Some G1 specific tests do not set -XX:+UseG1GC
Message-ID: <oUHMIq8zmo_V85u0_aClADgteBsHEZCfLhk9rj-KPeU=.64545793-07de-454d-8b32-23774bd2c095@github.com>

Most G1 tests set -XX:+UseG1GC, but a few (e.g. gc/g1/TestVerificationInConcurrentCycle.java) miss that.
This is usually just fine and no problem because G1 is the default anyway.
However in some cases, where a custom JVM changes the default GC, those tests start to fail which is not really necessary.

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

Commit messages:
 - JDK-8311026

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

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

From sspitsyn at openjdk.org  Fri Jun 30 08:29:07 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 30 Jun 2023 08:29:07 GMT
Subject: RFR: JDK-8311026: Some G1 specific tests do not set -XX:+UseG1GC
In-Reply-To: <oUHMIq8zmo_V85u0_aClADgteBsHEZCfLhk9rj-KPeU=.64545793-07de-454d-8b32-23774bd2c095@github.com>
References: <oUHMIq8zmo_V85u0_aClADgteBsHEZCfLhk9rj-KPeU=.64545793-07de-454d-8b32-23774bd2c095@github.com>
Message-ID: <LGmN3wvMUvN2AbrxPjvxO7Cz1XEqohu3yTnGzlCYIw0=.e73fc551-8bba-4705-bd91-cba2c1c4b478@github.com>

On Fri, 30 Jun 2023 08:11:47 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Most G1 tests set -XX:+UseG1GC, but a few (e.g. gc/g1/TestVerificationInConcurrentCycle.java) miss that.
> This is usually just fine and no problem because G1 is the default anyway.
> However in some cases, where a custom JVM changes the default GC, those tests start to fail which is not really necessary.

Looks good.
Thanks,
Serguei

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

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14722#pullrequestreview-1506747461

From tschatzl at openjdk.org  Fri Jun 30 08:44:05 2023
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Fri, 30 Jun 2023 08:44:05 GMT
Subject: RFR: 8140326: G1: Consider putting regions where evacuation failed
 into next collection set [v7]
In-Reply-To: <mmq6sEkAicO7Mc5FKkk5tcRVJDU6qtjYoyySho56F80=.aea5db50-0ec5-4e27-944e-2750af3d0bd7@github.com>
References: <mmq6sEkAicO7Mc5FKkk5tcRVJDU6qtjYoyySho56F80=.aea5db50-0ec5-4e27-944e-2750af3d0bd7@github.com>
Message-ID: <UIXbZUlCoPGm2H_VYdGUG9m_lOxCOZLGTGy2vygs6cU=.4622377c-65bf-47a0-999b-f8550f626179@github.com>

> This change adds management of retained regions, i.e. trying to evacuate evacuation failed regions asap.
> 
> The advantage is that evacuation failed regions do not need to wait until the next marking to be cleaned out; as they are often very sparsely occupied (often being eden regions), this occupies a lot of space, potentially causing additional evacuation failures later on.
> Another use of this change will be region pinning, which are basically evacuation failed regions that can not be reclaimed as long as they are pinned - however as soon as they are unpinned, they should be reclaimed for the same reasons as well.
> 
> It consists of several behavioral changes:
> 
> During garbage collection:
> 
> ... in the Evacuation phase:
> * always collect dirty cards into evacuation failed regions proactively. In tests, the amount of cards/live objects per evacuation failed region is typically very small. Dirty cards are always put into the global refinement buffer immediately, assuming that we will keep most if not all evacuation failed regions.
> 
> ... during Post Evacuation 2/Free Collection Set phase:
> * determine whether the region will be retained (kept for "immediate" evacuation) or not. Highly occupied regions are assumed to stay (mostly) live at least until the next marking, so do not bother with them.
> 
> These "retained" regions are collected in a new "from retained" set in the collection set candidates and managed separately from "from marking" regions. Having the "from retained" and "from marking" sets separate in the collection set candidates is easier to manage than to use a single list and the picking stuff from it. Particularly wrt to making sure that mixed gcs preferentially pick from the "from marking" list first, then second from the "from retained" list.
> 
> ... determining the collection set during the pause:
>   * during gc, the collection set is preferentially (first) populated with regions from the "from marking" candidates (these are the important regions to get cleaned out), second from the "from retained" list.
>   * g1 reserves up to 20% of max gc pause time for retained regions as optional candidates (this is a random number) to make sure that these are cleared out asap to free memory. There is also a minimum number of regions to take from the retained regions list.
> 
> During marking
> 
> ... changes to marking proper
> * retained regions will not be marked through during concurrent mark, i.e. they are considered outside of the snapshot. So they are added to the "root regio...

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

  ayang review3
  - More documentation
  - some renames
  - also exclude collection set regions from initial TAMS update as it is likely they will not fail evacuation

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14220/files
  - new: https://git.openjdk.org/jdk/pull/14220/files/2bb1fdaa..901edcbd

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

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

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

From shade at openjdk.org  Fri Jun 30 09:40:54 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 30 Jun 2023 09:40:54 GMT
Subject: RFR: JDK-8310111: Shenandoah wastes memory when running with very
 large page sizes [v2]
In-Reply-To: <duqC-dtC4Y4EmWO9lT2BcxzKNwQRpR_jgAXGfQmvPts=.2a77f87b-dbad-4466-bc65-76fa87603717@github.com>
References: <g2vZQuNNbJJoSTc2tE8nZhcLf0muaoZLnkuKZEzHoZQ=.88748998-31db-44bb-a45f-d75e46a4247e@github.com>
 <duqC-dtC4Y4EmWO9lT2BcxzKNwQRpR_jgAXGfQmvPts=.2a77f87b-dbad-4466-bc65-76fa87603717@github.com>
Message-ID: <9VcU06wFPIalVme8zJA9m1pYS2xfBcVa9AaFqF8vYGU=.52a2e784-c327-411d-b948-450982655a51@github.com>

On Tue, 20 Jun 2023 15:21:24 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> This proposal changes the reservation of bitmaps and region storage to reduce the wastage associated with running with very large page sizes (e.g. 1GB on x64, 512M on arm64) for both non-THP- and THP-mode.
>> 
>> This patch does:
>> - introducing the notion of "allowed overdraft factor" - allocations for a given page size are rejected if they would cause more wastage than the factor allows
>> - if it makes sense, it places mark- and aux-bitmap into a contiguous region to let them share a ginourmous page. E.g. for a heap of 16G, both bitmaps would now share a single GB page.
>> 
>> Examples:
>> 
>> Note: annoyingly, huge page usage does not show up in RSS. I therefore use a script that parses /proc/pid/smaps and counts hugepage usage to count cost for the following examples:
>> 
>> Example 1:
>> 
>> A machine configured with 1G pages (and nothing else). Heap is allocated with 1G pages, the bitmaps fall back to 4K pages because JVM figures 1GB would be wasted:
>> 
>> 
>> thomas at starfish$ ./images/jdk/bin/java -Xmx4600m -Xlog:pagesize -XX:+UseShenandoahGC -XX:+UseLargePages
>> ...
>> [0.028s][info][pagesize] Mark Bitmap: req_size=160M req_page_size=4K base=0x00007f8149fff000 size=160M page_size=4K
>> [0.028s][info][pagesize] Aux Bitmap: req_size=160M req_page_size=4K base=0x00007f813fffe000 size=160M page_size=4K
>> [0.028s][info][pagesize] Region Storage: req_size=320K req_page_size=4K base=0x00007f817c06f000 size=320K page_size=4K
>> 
>> 
>> Cost before: 8GB. Cost now: 5GB + (2*160M)
>> 
>> Example 2: JVM with 14GB heap: mark and aux bitmap together are large enough to justify another 1G page, so they share it. Notice how we also place the region storage on this page:
>> 
>> 
>> thomas at starfish:/shared/projects/openjdk/jdk-jdk/output-release$ ./images/jdk/bin/java -Xmx14g -Xlog:pagesize 
>> -XX:+UseShenandoahGC -XX:+UseLargePages -cp $REPROS_JAR de.stuefe.repros.Simple
>> [0.003s][info][pagesize] Heap: req_size=14G req_page_size=1G base=0x0000000480000000 size=14G page_size=1G
>> [0.003s][info][pagesize] Mark+Aux Bitmap: req_size=896M req_page_size=1G base=0x00007fee00000000 size=1G page_size=1G
>> [0.003s][info][pagesize] Region Storage: piggy-backing on Mark Bitmap: base=0x00007fee38000000 size=1792
>> <press key>
>> 
>> 
>> Cost before: 17GB. Cost now: 15GB.
>> 
>> From a bang-for-hugepages-buck multiples of 16GB are a sweet spot here since (on x64 with 1GB pages) since this allows us to put both 512m bitmaps onto a single huge page.
>> 
>> -----------
>> 
>> No test yet, since I wanted to se...
>
> Thomas Stuefe has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:
> 
>   start

I do wonder if we want to cobble together all Shenandoah bulk memory structures in a single `ReservedSpace` unconditionally, which could then use the single (large) page size, if needed. It feels redundant to try and allocate some data-structures separately and then solve the overdraft factor, splitting and piggy-backing? I think that logic would be even more complicated when GenShen comes in with additional RemSet data structure.

I.e. do a ReservedSpace, which _always_ gets the largest page size, and always contains:
  1. Collection set bitmap
  2. Regions storage
  3. Remembered set (from GenShen)
  4. Mark bitmap
  5. Aux bitmap

The RS base selection would be driven by (1), which wants a specific address.
(1)..(4) are commited at init. (5) is commited on demand, if page sizes allow.
The "waste" on large pages for smaller (1) and (2) would be subsumed by (4) and (5) that are in the same RS.

So if we are lucky, we would be able to fit everything in 1G page, like one of our example shows, but in a simpler way.

The problem I would see is that mark bitmap uncommit code would need to be adjusted a bit, if mark bitmap bases would not be aligned to page sizes anymore, but since they are the last in RS, we can do a bit of internal alignment to fit bulk uncommits better.

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

PR Comment: https://git.openjdk.org/jdk/pull/14559#issuecomment-1614402279

From tschatzl at openjdk.org  Fri Jun 30 11:30:58 2023
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Fri, 30 Jun 2023 11:30:58 GMT
Subject: RFR: JDK-8311026: Some G1 specific tests do not set -XX:+UseG1GC
In-Reply-To: <oUHMIq8zmo_V85u0_aClADgteBsHEZCfLhk9rj-KPeU=.64545793-07de-454d-8b32-23774bd2c095@github.com>
References: <oUHMIq8zmo_V85u0_aClADgteBsHEZCfLhk9rj-KPeU=.64545793-07de-454d-8b32-23774bd2c095@github.com>
Message-ID: <9qV2eIvGliad_OWjWBPLTlVRQAItZH7CW4ocxWNiBKY=.c5d60000-9f25-4130-a8f8-7a40a6c57a03@github.com>

On Fri, 30 Jun 2023 08:11:47 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Most G1 tests set -XX:+UseG1GC, but a few (e.g. gc/g1/TestVerificationInConcurrentCycle.java) miss that.
> This is usually just fine and no problem because G1 is the default anyway.
> However in some cases, where a custom JVM changes the default GC, those tests start to fail which is not really necessary.

Marked as reviewed by tschatzl (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/14722#pullrequestreview-1507020443

From mbaesken at openjdk.org  Fri Jun 30 11:38:06 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 30 Jun 2023 11:38:06 GMT
Subject: RFR: JDK-8311026: Some G1 specific tests do not set -XX:+UseG1GC
In-Reply-To: <oUHMIq8zmo_V85u0_aClADgteBsHEZCfLhk9rj-KPeU=.64545793-07de-454d-8b32-23774bd2c095@github.com>
References: <oUHMIq8zmo_V85u0_aClADgteBsHEZCfLhk9rj-KPeU=.64545793-07de-454d-8b32-23774bd2c095@github.com>
Message-ID: <DNdVwxC4sLBdysLVmCB1qX4tpWS3RaZAOAP8wki5Imk=.da3eaecf-2ddb-439b-928a-0f2076caa9af@github.com>

On Fri, 30 Jun 2023 08:11:47 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Most G1 tests set -XX:+UseG1GC, but a few (e.g. gc/g1/TestVerificationInConcurrentCycle.java) miss that.
> This is usually just fine and no problem because G1 is the default anyway.
> However in some cases, where a custom JVM changes the default GC, those tests start to fail which is not really necessary.

Hi Thomas and Serguei, thanks for the reviews !

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

PR Comment: https://git.openjdk.org/jdk/pull/14722#issuecomment-1614525324

From mbaesken at openjdk.org  Fri Jun 30 11:38:06 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 30 Jun 2023 11:38:06 GMT
Subject: Integrated: JDK-8311026: Some G1 specific tests do not set
 -XX:+UseG1GC
In-Reply-To: <oUHMIq8zmo_V85u0_aClADgteBsHEZCfLhk9rj-KPeU=.64545793-07de-454d-8b32-23774bd2c095@github.com>
References: <oUHMIq8zmo_V85u0_aClADgteBsHEZCfLhk9rj-KPeU=.64545793-07de-454d-8b32-23774bd2c095@github.com>
Message-ID: <QSDcoza58IO1fabVgd7FPockuvk3EdR7Zie6h81ec1s=.cc8cc36f-d10e-4b88-bd1f-6c3f6c66e704@github.com>

On Fri, 30 Jun 2023 08:11:47 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Most G1 tests set -XX:+UseG1GC, but a few (e.g. gc/g1/TestVerificationInConcurrentCycle.java) miss that.
> This is usually just fine and no problem because G1 is the default anyway.
> However in some cases, where a custom JVM changes the default GC, those tests start to fail which is not really necessary.

This pull request has now been integrated.

Changeset: a7d168b5
Author:    Matthias Baesken <mbaesken at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a7d168b522bb05345a40ae1fb18942ba663d3182
Stats:     4 lines in 3 files changed: 0 ins; 0 del; 4 mod

8311026: Some G1 specific tests do not set -XX:+UseG1GC

Reviewed-by: sspitsyn, tschatzl

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

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

From ayang at openjdk.org  Fri Jun 30 12:13:09 2023
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Fri, 30 Jun 2023 12:13:09 GMT
Subject: RFR: 8310311: Serial: move Generation::contribute_scratch to
 DefNewGeneration [v2]
In-Reply-To: <z_diblobapSstXhUETu9N7o35XcJO-3GnNwzW_VrAZs=.e909e3f4-0183-4196-91e0-7d2a56e6c655@github.com>
References: <z_diblobapSstXhUETu9N7o35XcJO-3GnNwzW_VrAZs=.e909e3f4-0183-4196-91e0-7d2a56e6c655@github.com>
Message-ID: <nJ5mP5yKEx5lMf38NeLOozhnA0vcWe2fZwYazteSk2k=.aa3b86fc-5b81-47dc-8dc9-10959c92c877@github.com>

> Simple cleanup to move a method from base-class to  sub-class.
> 
> Test: hotspot_gc

Albert Mingkun 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 one additional commit since the last revision:

  s1-contribute-scratch

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14540/files
  - new: https://git.openjdk.org/jdk/pull/14540/files/443fa29e..91970dc9

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

  Stats: 22983 lines in 994 files changed: 10908 ins; 5800 del; 6275 mod
  Patch: https://git.openjdk.org/jdk/pull/14540.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14540/head:pull/14540

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

From stuefe at openjdk.org  Fri Jun 30 12:25:53 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 30 Jun 2023 12:25:53 GMT
Subject: RFR: JDK-8310111: Shenandoah wastes memory when running with very
 large page sizes [v2]
In-Reply-To: <9VcU06wFPIalVme8zJA9m1pYS2xfBcVa9AaFqF8vYGU=.52a2e784-c327-411d-b948-450982655a51@github.com>
References: <g2vZQuNNbJJoSTc2tE8nZhcLf0muaoZLnkuKZEzHoZQ=.88748998-31db-44bb-a45f-d75e46a4247e@github.com>
 <duqC-dtC4Y4EmWO9lT2BcxzKNwQRpR_jgAXGfQmvPts=.2a77f87b-dbad-4466-bc65-76fa87603717@github.com>
 <9VcU06wFPIalVme8zJA9m1pYS2xfBcVa9AaFqF8vYGU=.52a2e784-c327-411d-b948-450982655a51@github.com>
Message-ID: <w9mUrCYx3fQEtKGxXdXZKgul60HA5_fwIQBQntpM7Po=.02d01236-4422-4b4e-a372-22a76e37e26d@github.com>

On Fri, 30 Jun 2023 09:38:33 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> I do wonder if we want to cobble together all Shenandoah bulk memory structures in a single `ReservedSpace` unconditionally, which could then use the single (large) page size, if needed. It feels redundant to try and allocate some data-structures separately and then solve the overdraft factor, splitting and piggy-backing? I think that logic would be even more complicated when GenShen comes in with additional RemSet data structure.
> 
> I.e. do a ReservedSpace, which _always_ gets the largest page size, and always contains:
> 
>     1. Collection set bitmap
> 
>     2. Regions storage
> 
>     3. Remembered set (from GenShen)
> 
>     4. Mark bitmap
> 
>     5. Aux bitmap
> 
> 
> The RS base selection would be driven by (1), which wants a specific address. (1)..(4) are commited at init. (5) is commited on demand, if page sizes allow. The "waste" on large pages for smaller (1) and (2) would be subsumed by (4) and (5) that are in the same RS.
> 
> So if we are lucky, we would be able to fit everything in 1G page, like one of our example shows, but in a simpler way.
> 

I like it, its simpler, but some drawbacks you need to okay beforehand:

- cset is normally tiny. Therefore the chance to map in lower-based regions is very good. The combined-everything RS would be a lot larger, therfore diminish the chance of mapping in lower regions. It would also reduce the chance of mapping the java heap in lower based regions. Especially if we ever try to attach the heap for zero-based *and* zero-shift oops mode, which at the moment we don't even try.

- Allocating everything together is an all-or-nothing deal: we need to have enough large pages for everyone, otherwise nobody gets large pages.

Both points may be acceptable drawbacks. Especially the second one, since it basically comes down to the sysadmin allocating enough hugepages. Not getting them could be seen as config error.


> The problem I would see is that mark bitmap uncommit code would need to be adjusted a bit, if mark bitmap bases would not be aligned to page sizes anymore, but since they are the last in RS, we can do a bit of internal alignment to fit bulk uncommits better.

I wonder if this is even an issue.

For static hugepages, we are "special" and never uncommit. For THP, would slice-wise uncommit and recommit really make sense? We'd just keep khugepaged busy. Alternatively, we could reserve huge-page-aligned and madvise in THP mode, but then never uncommit. That way, things coalesce and then stay that way.

Btw, on my machines the max. hugepage size for THP seems to be 2M. I know there was a kernel patch some time ago that tried to add 1G support, but don't know whether that ever got integrated.

My proposal would be: as you propose, use one RS. Then:
- static huge pages - no uncommit, no problem
- THP: never uncommit, all stays committed, no problem
- Non-LP: we use tiny system pages. Align the mark bitmap start to system page size, then all works as it did before.

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

PR Comment: https://git.openjdk.org/jdk/pull/14559#issuecomment-1614577295

From ayang at openjdk.org  Fri Jun 30 12:26:05 2023
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Fri, 30 Jun 2023 12:26:05 GMT
Subject: RFR: 8310946: G1: Refactor G1Policy::next_gc_should_be_mixed
In-Reply-To: <tHoboYNg5KG5PVM-R8-jquLd-xcSrTjuCFVsnC_WUSQ=.f0868b14-53d0-4958-8ae1-b3235493dc56@github.com>
References: <tHoboYNg5KG5PVM-R8-jquLd-xcSrTjuCFVsnC_WUSQ=.f0868b14-53d0-4958-8ae1-b3235493dc56@github.com>
Message-ID: <yyW4FA-YeE-OmiVtkUTpVGkZog6iy_Gm3uGa9pt_Uyo=.7e9b5e95-c787-4d5c-b64e-72967d9d3653@github.com>

On Tue, 27 Jun 2023 11:58:34 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple restructuring around `next_gc_should_be_mixed`.
> 
> (After such refactoring, I also tend to think this predicate makes more sense in the caller context, i.e. `bool is_next_gc_mixed = has_marking_candidates();`. For example, one of the call site even asserts `assert(!candidates()->has_more_marking_candidates(),`. Ofc, this is rather subjective.)
> 
> Test: hotspot_gc

Thanks for the review.

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

PR Comment: https://git.openjdk.org/jdk/pull/14673#issuecomment-1614576901

From ayang at openjdk.org  Fri Jun 30 12:26:06 2023
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Fri, 30 Jun 2023 12:26:06 GMT
Subject: Integrated: 8310946: G1: Refactor G1Policy::next_gc_should_be_mixed
In-Reply-To: <tHoboYNg5KG5PVM-R8-jquLd-xcSrTjuCFVsnC_WUSQ=.f0868b14-53d0-4958-8ae1-b3235493dc56@github.com>
References: <tHoboYNg5KG5PVM-R8-jquLd-xcSrTjuCFVsnC_WUSQ=.f0868b14-53d0-4958-8ae1-b3235493dc56@github.com>
Message-ID: <YvtTLr1K6J8j61wiPoy23DupBBpGfpo3YTsFcs3M5kI=.ece19ba9-409c-4e3a-8b3e-b41a2b86b2b3@github.com>

On Tue, 27 Jun 2023 11:58:34 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple restructuring around `next_gc_should_be_mixed`.
> 
> (After such refactoring, I also tend to think this predicate makes more sense in the caller context, i.e. `bool is_next_gc_mixed = has_marking_candidates();`. For example, one of the call site even asserts `assert(!candidates()->has_more_marking_candidates(),`. Ofc, this is rather subjective.)
> 
> Test: hotspot_gc

This pull request has now been integrated.

Changeset: 33011ea1
Author:    Albert Mingkun Yang <ayang at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/33011ea19bb29e88ce18a138a8fa8b34f8c97407
Stats:     17 lines in 2 files changed: 2 ins; 8 del; 7 mod

8310946: G1: Refactor G1Policy::next_gc_should_be_mixed

Reviewed-by: tschatzl, kbarrett

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

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

From aboldtch at openjdk.org  Fri Jun 30 13:19:20 2023
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Fri, 30 Jun 2023 13:19:20 GMT
Subject: RFR: 8310743: assert(reserved_rgn != nullptr) failed: Add committed
 region, No reserved region found
Message-ID: <IntEDDXLSYVwmi95lqxXVl3MZr56OvU6U3QuBbGiPBk=.01ca0002-0049-4cef-9aa5-0d2f0cd29b4f@github.com>

JDK-8309675 tried to solve the issue of NMT reporting to much committed memory by faking the virtual addresses registered when committing physical memory. This mapping was simply the `virtual address  = physical offset in backing file + heap base`. This works when ZGC gets a contiguous heap which starts at the heap base. However fails if it does not start at the heap base or is discontiguous.

This proposal fixes this by keeping track of all the reserved virtual address ranges and by creating a mapping from the physical offsets to the actual reserved virtual address ranges. If the physical offsets committed maps to multiple reserved ranges, it is processed as multiple commits.

The develop flag `ZForceDiscontiguousHeapReservations` is introduced to test the discontiguous heap feature and interactions.

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

Commit messages:
 - 8310743: assert(reserved_rgn != nullptr) failed: Add committed region, No reserved region found

Changes: https://git.openjdk.org/jdk/pull/14730/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14730&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8310743
  Stats: 477 lines in 12 files changed: 429 ins; 32 del; 16 mod
  Patch: https://git.openjdk.org/jdk/pull/14730.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14730/head:pull/14730

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

From stefank at openjdk.org  Fri Jun 30 13:19:21 2023
From: stefank at openjdk.org (Stefan Karlsson)
Date: Fri, 30 Jun 2023 13:19:21 GMT
Subject: RFR: 8310743: assert(reserved_rgn != nullptr) failed: Add
 committed region, No reserved region found
In-Reply-To: <IntEDDXLSYVwmi95lqxXVl3MZr56OvU6U3QuBbGiPBk=.01ca0002-0049-4cef-9aa5-0d2f0cd29b4f@github.com>
References: <IntEDDXLSYVwmi95lqxXVl3MZr56OvU6U3QuBbGiPBk=.01ca0002-0049-4cef-9aa5-0d2f0cd29b4f@github.com>
Message-ID: <q-mkkvS6q6M3DHWzrIY_0cw5TCha7isY0id-eTyn4ok=.b0e5d8ee-8076-4dae-b846-b3ba9588b425@github.com>

On Fri, 30 Jun 2023 13:07:17 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

> JDK-8309675 tried to solve the issue of NMT reporting to much committed memory by faking the virtual addresses registered when committing physical memory. This mapping was simply the `virtual address  = physical offset in backing file + heap base`. This works when ZGC gets a contiguous heap which starts at the heap base. However fails if it does not start at the heap base or is discontiguous.
> 
> This proposal fixes this by keeping track of all the reserved virtual address ranges and by creating a mapping from the physical offsets to the actual reserved virtual address ranges. If the physical offsets committed maps to multiple reserved ranges, it is processed as multiple commits.
> 
> The develop flag `ZForceDiscontiguousHeapReservations` is introduced to test the discontiguous heap feature and interactions.

Marked as reviewed by stefank (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/14730#pullrequestreview-1507172567

From shade at openjdk.org  Fri Jun 30 13:25:58 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 30 Jun 2023 13:25:58 GMT
Subject: RFR: JDK-8310111: Shenandoah wastes memory when running with very
 large page sizes [v2]
In-Reply-To: <duqC-dtC4Y4EmWO9lT2BcxzKNwQRpR_jgAXGfQmvPts=.2a77f87b-dbad-4466-bc65-76fa87603717@github.com>
References: <g2vZQuNNbJJoSTc2tE8nZhcLf0muaoZLnkuKZEzHoZQ=.88748998-31db-44bb-a45f-d75e46a4247e@github.com>
 <duqC-dtC4Y4EmWO9lT2BcxzKNwQRpR_jgAXGfQmvPts=.2a77f87b-dbad-4466-bc65-76fa87603717@github.com>
Message-ID: <Km9caDA75AZ0WkaSppEqp20u3L0UReHhDcOHgZ0UVO4=.43319cf2-1ca3-4ce1-91a2-a0722f19e123@github.com>

On Tue, 20 Jun 2023 15:21:24 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> This proposal changes the reservation of bitmaps and region storage to reduce the wastage associated with running with very large page sizes (e.g. 1GB on x64, 512M on arm64) for both non-THP- and THP-mode.
>> 
>> This patch does:
>> - introducing the notion of "allowed overdraft factor" - allocations for a given page size are rejected if they would cause more wastage than the factor allows
>> - if it makes sense, it places mark- and aux-bitmap into a contiguous region to let them share a ginourmous page. E.g. for a heap of 16G, both bitmaps would now share a single GB page.
>> 
>> Examples:
>> 
>> Note: annoyingly, huge page usage does not show up in RSS. I therefore use a script that parses /proc/pid/smaps and counts hugepage usage to count cost for the following examples:
>> 
>> Example 1:
>> 
>> A machine configured with 1G pages (and nothing else). Heap is allocated with 1G pages, the bitmaps fall back to 4K pages because JVM figures 1GB would be wasted:
>> 
>> 
>> thomas at starfish$ ./images/jdk/bin/java -Xmx4600m -Xlog:pagesize -XX:+UseShenandoahGC -XX:+UseLargePages
>> ...
>> [0.028s][info][pagesize] Mark Bitmap: req_size=160M req_page_size=4K base=0x00007f8149fff000 size=160M page_size=4K
>> [0.028s][info][pagesize] Aux Bitmap: req_size=160M req_page_size=4K base=0x00007f813fffe000 size=160M page_size=4K
>> [0.028s][info][pagesize] Region Storage: req_size=320K req_page_size=4K base=0x00007f817c06f000 size=320K page_size=4K
>> 
>> 
>> Cost before: 8GB. Cost now: 5GB + (2*160M)
>> 
>> Example 2: JVM with 14GB heap: mark and aux bitmap together are large enough to justify another 1G page, so they share it. Notice how we also place the region storage on this page:
>> 
>> 
>> thomas at starfish:/shared/projects/openjdk/jdk-jdk/output-release$ ./images/jdk/bin/java -Xmx14g -Xlog:pagesize 
>> -XX:+UseShenandoahGC -XX:+UseLargePages -cp $REPROS_JAR de.stuefe.repros.Simple
>> [0.003s][info][pagesize] Heap: req_size=14G req_page_size=1G base=0x0000000480000000 size=14G page_size=1G
>> [0.003s][info][pagesize] Mark+Aux Bitmap: req_size=896M req_page_size=1G base=0x00007fee00000000 size=1G page_size=1G
>> [0.003s][info][pagesize] Region Storage: piggy-backing on Mark Bitmap: base=0x00007fee38000000 size=1792
>> <press key>
>> 
>> 
>> Cost before: 17GB. Cost now: 15GB.
>> 
>> From a bang-for-hugepages-buck multiples of 16GB are a sweet spot here since (on x64 with 1GB pages) since this allows us to put both 512m bitmaps onto a single huge page.
>> 
>> -----------
>> 
>> No test yet, since I wanted to se...
>
> Thomas Stuefe has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:
> 
>   start

>     * cset is normally tiny. Therefore the chance to map in lower-based regions is very good. The combined-everything RS would be a lot larger, therfore diminish the chance of mapping in lower regions. It would also reduce the chance of mapping the java heap in lower based regions. Especially if we ever try to attach the heap for zero-based _and_ zero-shift oops mode, which at the moment we don't even try.

Right. Then maybe leave cset bitmap alone, so it is allocatable before the heap, as it needs the most compact encoding possible to optimize the barrier fastpaths. There seem to be little reason to large-page-alloc it at all: the normal region count is about the size of small page size. Then keep the GC structures RS reservation after the heap reservation is done, so we are not interfering with heap base allocation.

>     * Allocating everything together is an all-or-nothing deal: we need to have enough large pages for everyone, otherwise nobody gets large pages.

Seems a fair deal to me. I think we _definitely_ want to avoid entangling the Java heap large pages allocation. After Java heap is allocated with large pages, all-or-nothing for the rest of GC structures seem a reasonable compromise for implementation simplicity.

> My proposal would be: as you propose, use one RS. Then:
>     * static huge pages - no uncommit, no problem
>     * THP: never uncommit, all stays committed, no problem
>     * Non-LP: we use tiny system pages. Align the mark bitmap start to system page size, then all works as it did before.

Would still be nice to support slice uncommit with THP, at least for smaller 2M pages. Aligning marking bitmaps to 2M does not seem to waste a lot of memory, and our footprint is still much better with uncommits.

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

PR Comment: https://git.openjdk.org/jdk/pull/14559#issuecomment-1614647483

From ayang at openjdk.org  Fri Jun 30 15:17:58 2023
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Fri, 30 Jun 2023 15:17:58 GMT
Subject: RFR: 8310743: assert(reserved_rgn != nullptr) failed: Add
 committed region, No reserved region found
In-Reply-To: <IntEDDXLSYVwmi95lqxXVl3MZr56OvU6U3QuBbGiPBk=.01ca0002-0049-4cef-9aa5-0d2f0cd29b4f@github.com>
References: <IntEDDXLSYVwmi95lqxXVl3MZr56OvU6U3QuBbGiPBk=.01ca0002-0049-4cef-9aa5-0d2f0cd29b4f@github.com>
Message-ID: <2O9RRHNCCMQwNaBBP-etQTxvo8IC5rWM5YzB8MvEaKc=.c98848f0-541d-4dbf-887d-e8f6fc5d5bc7@github.com>

On Fri, 30 Jun 2023 13:07:17 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

> JDK-8309675 tried to solve the issue of NMT reporting to much committed memory by faking the virtual addresses registered when committing physical memory. This mapping was simply the `virtual address  = physical offset in backing file + heap base`. This works when ZGC gets a contiguous heap which starts at the heap base. However fails if it does not start at the heap base or is discontiguous.
> 
> This proposal fixes this by keeping track of all the reserved virtual address ranges and by creating a mapping from the physical offsets to the actual reserved virtual address ranges. If the physical offsets committed maps to multiple reserved ranges, it is processed as multiple commits.
> 
> The develop flag `ZForceDiscontiguousHeapReservations` is introduced to test the discontiguous heap feature and interactions.
> 
> Testing: 
>  * Added test on all Oracle platforms
>  * GHA
>  * Running tier1-3

src/hotspot/share/gc/z/zNMT.cpp line 44:

> 42:     const size_t reservation_size = _reservations[index]._size;
> 43:     if (*offset_in_reservation < reservation_size) {
> 44:       break;

I wonder if one can return `index` here. Then, after the for-loop, one can write `fatal(...)`.

src/hotspot/share/gc/z/zNMT.cpp line 79:

> 77:         Tracker tracker(Tracker::uncommit);
> 78:         tracker.record((address)sub_range_addr, sub_range_size);
> 79:       }

Sth like `record_virtual_memory_uncommit` would make this more symmetric. (Better be done in a followup PR though.)

src/hotspot/share/gc/z/zNMT.cpp line 91:

> 89:   }
> 90: 
> 91:   assert(left_to_process == 0, "everything was not commited");

When will this be reachable? I'd expect the if-check inside the for-loop to handle exit-condition.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14730#discussion_r1247884226
PR Review Comment: https://git.openjdk.org/jdk/pull/14730#discussion_r1247983800
PR Review Comment: https://git.openjdk.org/jdk/pull/14730#discussion_r1247982053

From stuefe at openjdk.org  Fri Jun 30 16:34:52 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 30 Jun 2023 16:34:52 GMT
Subject: RFR: JDK-8310111: Shenandoah wastes memory when running with very
 large page sizes [v2]
In-Reply-To: <Km9caDA75AZ0WkaSppEqp20u3L0UReHhDcOHgZ0UVO4=.43319cf2-1ca3-4ce1-91a2-a0722f19e123@github.com>
References: <g2vZQuNNbJJoSTc2tE8nZhcLf0muaoZLnkuKZEzHoZQ=.88748998-31db-44bb-a45f-d75e46a4247e@github.com>
 <duqC-dtC4Y4EmWO9lT2BcxzKNwQRpR_jgAXGfQmvPts=.2a77f87b-dbad-4466-bc65-76fa87603717@github.com>
 <Km9caDA75AZ0WkaSppEqp20u3L0UReHhDcOHgZ0UVO4=.43319cf2-1ca3-4ce1-91a2-a0722f19e123@github.com>
Message-ID: <-svyBJgRP8XkRtiNp9C9GYYQfEDQDMyI81FVVekaVzQ=.23e5eeab-f633-48a0-bb14-691ad708c662@github.com>

On Fri, 30 Jun 2023 13:23:25 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> 
> > My proposal would be: as you propose, use one RS. Then:
> > * static huge pages - no uncommit, no problem
> > * THP: never uncommit, all stays committed, no problem
> > * Non-LP: we use tiny system pages. Align the mark bitmap start to system page size, then all works as it did before.
> 
> Would still be nice to support slice uncommit with THP, at least for smaller 2M pages. Aligning marking bitmaps to 2M does not seem to waste a lot of memory, and our footprint is still much better with uncommits.

Okay, lets do that. I can just let the marking bitmaps live at the front of the RS, then the first is already aligned.

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

PR Comment: https://git.openjdk.org/jdk/pull/14559#issuecomment-1614899136

From shade at openjdk.org  Fri Jun 30 16:43:55 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 30 Jun 2023 16:43:55 GMT
Subject: RFR: JDK-8310111: Shenandoah wastes memory when running with very
 large page sizes [v2]
In-Reply-To: <-svyBJgRP8XkRtiNp9C9GYYQfEDQDMyI81FVVekaVzQ=.23e5eeab-f633-48a0-bb14-691ad708c662@github.com>
References: <g2vZQuNNbJJoSTc2tE8nZhcLf0muaoZLnkuKZEzHoZQ=.88748998-31db-44bb-a45f-d75e46a4247e@github.com>
 <duqC-dtC4Y4EmWO9lT2BcxzKNwQRpR_jgAXGfQmvPts=.2a77f87b-dbad-4466-bc65-76fa87603717@github.com>
 <Km9caDA75AZ0WkaSppEqp20u3L0UReHhDcOHgZ0UVO4=.43319cf2-1ca3-4ce1-91a2-a0722f19e123@github.com>
 <-svyBJgRP8XkRtiNp9C9GYYQfEDQDMyI81FVVekaVzQ=.23e5eeab-f633-48a0-bb14-691ad708c662@github.com>
Message-ID: <LE1klUX0CGxjdTmvXZ3uer3EOhu-BKCrpH_wXmbBgUw=.f31f0afd-f66b-40ce-b2c5-a17e93e7a0ac@github.com>

On Fri, 30 Jun 2023 16:32:23 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> Okay, lets do that. I can just let the marking bitmaps live at the front of the RS, then the first is already aligned.

Yeah, that works too. I kinda put them at the end, so that cset could come first. But if we leave cset alone, it makes sense to put marking bitmaps first, and then the rest.

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

PR Comment: https://git.openjdk.org/jdk/pull/14559#issuecomment-1614908302

From stuefe at openjdk.org  Fri Jun 30 16:56:57 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 30 Jun 2023 16:56:57 GMT
Subject: RFR: JDK-8310111: Shenandoah wastes memory when running with very
 large page sizes [v2]
In-Reply-To: <duqC-dtC4Y4EmWO9lT2BcxzKNwQRpR_jgAXGfQmvPts=.2a77f87b-dbad-4466-bc65-76fa87603717@github.com>
References: <g2vZQuNNbJJoSTc2tE8nZhcLf0muaoZLnkuKZEzHoZQ=.88748998-31db-44bb-a45f-d75e46a4247e@github.com>
 <duqC-dtC4Y4EmWO9lT2BcxzKNwQRpR_jgAXGfQmvPts=.2a77f87b-dbad-4466-bc65-76fa87603717@github.com>
Message-ID: <ZHoTHiREge977foQhuRO2d93R5atutaNoC9_B16_QHA=.757b89e9-5de7-410f-9182-c13e48196f2c@github.com>

On Tue, 20 Jun 2023 15:21:24 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> This proposal changes the reservation of bitmaps and region storage to reduce the wastage associated with running with very large page sizes (e.g. 1GB on x64, 512M on arm64) for both non-THP- and THP-mode.
>> 
>> This patch does:
>> - introducing the notion of "allowed overdraft factor" - allocations for a given page size are rejected if they would cause more wastage than the factor allows
>> - if it makes sense, it places mark- and aux-bitmap into a contiguous region to let them share a ginourmous page. E.g. for a heap of 16G, both bitmaps would now share a single GB page.
>> 
>> Examples:
>> 
>> Note: annoyingly, huge page usage does not show up in RSS. I therefore use a script that parses /proc/pid/smaps and counts hugepage usage to count cost for the following examples:
>> 
>> Example 1:
>> 
>> A machine configured with 1G pages (and nothing else). Heap is allocated with 1G pages, the bitmaps fall back to 4K pages because JVM figures 1GB would be wasted:
>> 
>> 
>> thomas at starfish$ ./images/jdk/bin/java -Xmx4600m -Xlog:pagesize -XX:+UseShenandoahGC -XX:+UseLargePages
>> ...
>> [0.028s][info][pagesize] Mark Bitmap: req_size=160M req_page_size=4K base=0x00007f8149fff000 size=160M page_size=4K
>> [0.028s][info][pagesize] Aux Bitmap: req_size=160M req_page_size=4K base=0x00007f813fffe000 size=160M page_size=4K
>> [0.028s][info][pagesize] Region Storage: req_size=320K req_page_size=4K base=0x00007f817c06f000 size=320K page_size=4K
>> 
>> 
>> Cost before: 8GB. Cost now: 5GB + (2*160M)
>> 
>> Example 2: JVM with 14GB heap: mark and aux bitmap together are large enough to justify another 1G page, so they share it. Notice how we also place the region storage on this page:
>> 
>> 
>> thomas at starfish:/shared/projects/openjdk/jdk-jdk/output-release$ ./images/jdk/bin/java -Xmx14g -Xlog:pagesize 
>> -XX:+UseShenandoahGC -XX:+UseLargePages -cp $REPROS_JAR de.stuefe.repros.Simple
>> [0.003s][info][pagesize] Heap: req_size=14G req_page_size=1G base=0x0000000480000000 size=14G page_size=1G
>> [0.003s][info][pagesize] Mark+Aux Bitmap: req_size=896M req_page_size=1G base=0x00007fee00000000 size=1G page_size=1G
>> [0.003s][info][pagesize] Region Storage: piggy-backing on Mark Bitmap: base=0x00007fee38000000 size=1792
>> <press key>
>> 
>> 
>> Cost before: 17GB. Cost now: 15GB.
>> 
>> From a bang-for-hugepages-buck multiples of 16GB are a sweet spot here since (on x64 with 1GB pages) since this allows us to put both 512m bitmaps onto a single huge page.
>> 
>> -----------
>> 
>> No test yet, since I wanted to se...
>
> Thomas Stuefe has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:
> 
>   start

Putting this back into draft until changes are done and tests are stable.

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

PR Comment: https://git.openjdk.org/jdk/pull/14559#issuecomment-1614922348

From dcubed at openjdk.org  Fri Jun 30 21:14:11 2023
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Fri, 30 Jun 2023 21:14:11 GMT
Subject: RFR: 8311186: ProblemList
 javax/management/remote/mandatory/subjectDelegation/SubjectDelegation1Test.java
 on linux-aarch64
Message-ID: <5Efv-Uyo3Am0KK1YuN-92jlgkkFxwIu5CPgHzSvKRz4=.e57f9707-8d83-45c7-8ab2-65132402bf0e@github.com>

Trivial ProblemListing/disable changes:
- [JDK-8311186](https://bugs.openjdk.org/browse/JDK-8311186) ProblemList javax/management/remote/mandatory/subjectDelegation/SubjectDelegation1Test.java on linux-aarch64
- [JDK-8311189](https://bugs.openjdk.org/browse/JDK-8311189) disable gc/z/TestHighUsage.java
- [JDK-8311190](https://bugs.openjdk.org/browse/JDK-8311190) ProblemList javax/management/remote/mandatory/connection/DeadLockTest.java with virtual threads on windows-x64
- [JDK-8311191](https://bugs.openjdk.org/browse/JDK-8311191) ProblemList javax/management/remote/mandatory/connection/ConnectionTest.java with virtual threads on windows-x64
- [JDK-8311193](https://bugs.openjdk.org/browse/JDK-8311193) ProblemList vmTestbase/nsk/jdb/interrupt/interrupt001/interrupt001.java on linux-all
- [JDK-8311195](https://bugs.openjdk.org/browse/JDK-8311195) ProblemList vmTestbase/nsk/jvmti/scenarios/capability/CM03/cm03t001/TestDescription.java with Xcomp on macosx-x64

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

Commit messages:
 - 8311195: ProblemList vmTestbase/nsk/jvmti/scenarios/capability/CM03/cm03t001/TestDescription.java with Xcomp on macosx-x64
 - 8311193: ProblemList vmTestbase/nsk/jdb/interrupt/interrupt001/interrupt001.java on linux-all
 - 8311191: ProblemList javax/management/remote/mandatory/connection/ConnectionTest.java with virtual threads on windows-x64
 - 8311190: ProblemList javax/management/remote/mandatory/connection/DeadLockTest.java with virtual threads on windows-x64
 - 8311189: disable gc/z/TestHighUsage.java
 - 8311186: ProblemList javax/management/remote/mandatory/subjectDelegation/SubjectDelegation1Test.java on linux-aarch64

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

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

From lmesnik at openjdk.org  Fri Jun 30 21:33:56 2023
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Fri, 30 Jun 2023 21:33:56 GMT
Subject: RFR: 8311186: ProblemList
 javax/management/remote/mandatory/subjectDelegation/SubjectDelegation1Test.java
 on linux-aarch64
In-Reply-To: <5Efv-Uyo3Am0KK1YuN-92jlgkkFxwIu5CPgHzSvKRz4=.e57f9707-8d83-45c7-8ab2-65132402bf0e@github.com>
References: <5Efv-Uyo3Am0KK1YuN-92jlgkkFxwIu5CPgHzSvKRz4=.e57f9707-8d83-45c7-8ab2-65132402bf0e@github.com>
Message-ID: <Mb97kpeHZZSucl1HUCIjQPI9BCnukqfxoyOVv_4yM38=.eb508868-ea1b-4670-bcdd-019d08ac02f9@github.com>

On Fri, 30 Jun 2023 19:26:22 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> Trivial ProblemListing/disable changes:
> - [JDK-8311186](https://bugs.openjdk.org/browse/JDK-8311186) ProblemList javax/management/remote/mandatory/subjectDelegation/SubjectDelegation1Test.java on linux-aarch64
> - [JDK-8311189](https://bugs.openjdk.org/browse/JDK-8311189) disable gc/z/TestHighUsage.java
> - [JDK-8311190](https://bugs.openjdk.org/browse/JDK-8311190) ProblemList javax/management/remote/mandatory/connection/DeadLockTest.java with virtual threads on windows-x64
> - [JDK-8311191](https://bugs.openjdk.org/browse/JDK-8311191) ProblemList javax/management/remote/mandatory/connection/ConnectionTest.java with virtual threads on windows-x64
> - [JDK-8311193](https://bugs.openjdk.org/browse/JDK-8311193) ProblemList vmTestbase/nsk/jdb/interrupt/interrupt001/interrupt001.java on linux-all
> - [JDK-8311195](https://bugs.openjdk.org/browse/JDK-8311195) ProblemList vmTestbase/nsk/jvmti/scenarios/capability/CM03/cm03t001/TestDescription.java with Xcomp on macosx-x64

I understand that test/hotspot/jtreg/gc/z/TestHighUsage.java can't be problemlisted using zgc test lists. But why not to put into plain ProblemList.txt? 
Also, might be it makes sense to remove it from *zgc problem list while adding ignore? But might be it could be done while fixing bug.

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

Marked as reviewed by lmesnik (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14741#pullrequestreview-1507915619

From dcubed at openjdk.org  Fri Jun 30 21:47:02 2023
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Fri, 30 Jun 2023 21:47:02 GMT
Subject: RFR: 8311186: ProblemList
 javax/management/remote/mandatory/subjectDelegation/SubjectDelegation1Test.java
 on linux-aarch64
In-Reply-To: <5Efv-Uyo3Am0KK1YuN-92jlgkkFxwIu5CPgHzSvKRz4=.e57f9707-8d83-45c7-8ab2-65132402bf0e@github.com>
References: <5Efv-Uyo3Am0KK1YuN-92jlgkkFxwIu5CPgHzSvKRz4=.e57f9707-8d83-45c7-8ab2-65132402bf0e@github.com>
Message-ID: <bHYDmSRLliDq67eEuyXQGTQrfeG3djuK-wgJIYkCy3A=.bc0a1100-c1e6-4191-9e6f-7a9f9647e31d@github.com>

On Fri, 30 Jun 2023 19:26:22 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> Trivial ProblemListing/disable changes:
> - [JDK-8311186](https://bugs.openjdk.org/browse/JDK-8311186) ProblemList javax/management/remote/mandatory/subjectDelegation/SubjectDelegation1Test.java on linux-aarch64
> - [JDK-8311189](https://bugs.openjdk.org/browse/JDK-8311189) disable gc/z/TestHighUsage.java
> - [JDK-8311190](https://bugs.openjdk.org/browse/JDK-8311190) ProblemList javax/management/remote/mandatory/connection/DeadLockTest.java with virtual threads on windows-x64
> - [JDK-8311191](https://bugs.openjdk.org/browse/JDK-8311191) ProblemList javax/management/remote/mandatory/connection/ConnectionTest.java with virtual threads on windows-x64
> - [JDK-8311193](https://bugs.openjdk.org/browse/JDK-8311193) ProblemList vmTestbase/nsk/jdb/interrupt/interrupt001/interrupt001.java on linux-all
> - [JDK-8311195](https://bugs.openjdk.org/browse/JDK-8311195) ProblemList vmTestbase/nsk/jvmti/scenarios/capability/CM03/cm03t001/TestDescription.java with Xcomp on macosx-x64

I guess test/hotspot/jtreg/gc/z/TestHighUsage.java could be added to the
ProblemList.txt file. However, that feels a bit misleading to me. It's a
Generational ZGC only test that can't be ProblemListed in the usual way
by putting it on the Generational ZGC ProblemList.

In this case, I just wanted to be sure that it just doesn't run anywhere for
any reason. Especially after the two previous (bad) ProblemListing attempts.

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

PR Comment: https://git.openjdk.org/jdk/pull/14741#issuecomment-1615220031

From lmesnik at openjdk.org  Fri Jun 30 21:47:03 2023
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Fri, 30 Jun 2023 21:47:03 GMT
Subject: RFR: 8311186: ProblemList
 javax/management/remote/mandatory/subjectDelegation/SubjectDelegation1Test.java
 on linux-aarch64
In-Reply-To: <5Efv-Uyo3Am0KK1YuN-92jlgkkFxwIu5CPgHzSvKRz4=.e57f9707-8d83-45c7-8ab2-65132402bf0e@github.com>
References: <5Efv-Uyo3Am0KK1YuN-92jlgkkFxwIu5CPgHzSvKRz4=.e57f9707-8d83-45c7-8ab2-65132402bf0e@github.com>
Message-ID: <ol0UVrbgtZ5Yi2XNGWUS7bj3r_WfAnEsC8XIEofvhLc=.27c22a24-42da-4c20-aa78-1543a8dc1e1b@github.com>

On Fri, 30 Jun 2023 19:26:22 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> Trivial ProblemListing/disable changes:
> - [JDK-8311186](https://bugs.openjdk.org/browse/JDK-8311186) ProblemList javax/management/remote/mandatory/subjectDelegation/SubjectDelegation1Test.java on linux-aarch64
> - [JDK-8311189](https://bugs.openjdk.org/browse/JDK-8311189) disable gc/z/TestHighUsage.java
> - [JDK-8311190](https://bugs.openjdk.org/browse/JDK-8311190) ProblemList javax/management/remote/mandatory/connection/DeadLockTest.java with virtual threads on windows-x64
> - [JDK-8311191](https://bugs.openjdk.org/browse/JDK-8311191) ProblemList javax/management/remote/mandatory/connection/ConnectionTest.java with virtual threads on windows-x64
> - [JDK-8311193](https://bugs.openjdk.org/browse/JDK-8311193) ProblemList vmTestbase/nsk/jdb/interrupt/interrupt001/interrupt001.java on linux-all
> - [JDK-8311195](https://bugs.openjdk.org/browse/JDK-8311195) ProblemList vmTestbase/nsk/jvmti/scenarios/capability/CM03/cm03t001/TestDescription.java with Xcomp on macosx-x64

There is misunderstanding here. Generational ZGC ProblemList is used not to problemlist Gen ZGC tests, but probleml list any test with -XX:ZGC + Generational enabled execution.

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

PR Comment: https://git.openjdk.org/jdk/pull/14741#issuecomment-1615221446

From dcubed at openjdk.org  Fri Jun 30 21:47:04 2023
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Fri, 30 Jun 2023 21:47:04 GMT
Subject: Integrated: 8311186: ProblemList
 javax/management/remote/mandatory/subjectDelegation/SubjectDelegation1Test.java
 on linux-aarch64
In-Reply-To: <5Efv-Uyo3Am0KK1YuN-92jlgkkFxwIu5CPgHzSvKRz4=.e57f9707-8d83-45c7-8ab2-65132402bf0e@github.com>
References: <5Efv-Uyo3Am0KK1YuN-92jlgkkFxwIu5CPgHzSvKRz4=.e57f9707-8d83-45c7-8ab2-65132402bf0e@github.com>
Message-ID: <LhJfcug8W4c3toJLh6gURFA2iYIMGyrKp-wnBEMUdx0=.ae249174-8aea-4595-ad77-4ef02494b970@github.com>

On Fri, 30 Jun 2023 19:26:22 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> Trivial ProblemListing/disable changes:
> - [JDK-8311186](https://bugs.openjdk.org/browse/JDK-8311186) ProblemList javax/management/remote/mandatory/subjectDelegation/SubjectDelegation1Test.java on linux-aarch64
> - [JDK-8311189](https://bugs.openjdk.org/browse/JDK-8311189) disable gc/z/TestHighUsage.java
> - [JDK-8311190](https://bugs.openjdk.org/browse/JDK-8311190) ProblemList javax/management/remote/mandatory/connection/DeadLockTest.java with virtual threads on windows-x64
> - [JDK-8311191](https://bugs.openjdk.org/browse/JDK-8311191) ProblemList javax/management/remote/mandatory/connection/ConnectionTest.java with virtual threads on windows-x64
> - [JDK-8311193](https://bugs.openjdk.org/browse/JDK-8311193) ProblemList vmTestbase/nsk/jdb/interrupt/interrupt001/interrupt001.java on linux-all
> - [JDK-8311195](https://bugs.openjdk.org/browse/JDK-8311195) ProblemList vmTestbase/nsk/jvmti/scenarios/capability/CM03/cm03t001/TestDescription.java with Xcomp on macosx-x64

This pull request has now been integrated.

Changeset: 140b70fb
Author:    Daniel D. Daugherty <dcubed at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/140b70fb29e2b83e5d33765906ee76a36442a687
Stats:     13 lines in 6 files changed: 11 ins; 2 del; 0 mod

8311186: ProblemList javax/management/remote/mandatory/subjectDelegation/SubjectDelegation1Test.java on linux-aarch64
8311189: disable gc/z/TestHighUsage.java
8311190: ProblemList javax/management/remote/mandatory/connection/DeadLockTest.java with virtual threads on windows-x64
8311191: ProblemList javax/management/remote/mandatory/connection/ConnectionTest.java with virtual threads on windows-x64
8311193: ProblemList vmTestbase/nsk/jdb/interrupt/interrupt001/interrupt001.java on linux-all
8311195: ProblemList vmTestbase/nsk/jvmti/scenarios/capability/CM03/cm03t001/TestDescription.java with Xcomp on macosx-x64

Reviewed-by: lmesnik

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

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

From dcubed at openjdk.org  Fri Jun 30 22:01:03 2023
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Fri, 30 Jun 2023 22:01:03 GMT
Subject: RFR: 8311186: ProblemList
 javax/management/remote/mandatory/subjectDelegation/SubjectDelegation1Test.java
 on linux-aarch64
In-Reply-To: <5Efv-Uyo3Am0KK1YuN-92jlgkkFxwIu5CPgHzSvKRz4=.e57f9707-8d83-45c7-8ab2-65132402bf0e@github.com>
References: <5Efv-Uyo3Am0KK1YuN-92jlgkkFxwIu5CPgHzSvKRz4=.e57f9707-8d83-45c7-8ab2-65132402bf0e@github.com>
Message-ID: <-4UUPh9VupNyvb6DuOdo1uh8dGurWBDRbUMvgIVOysg=.476852ae-ba88-40ab-ba9b-0c20738d1005@github.com>

On Fri, 30 Jun 2023 19:26:22 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> Trivial ProblemListing/disable changes:
> - [JDK-8311186](https://bugs.openjdk.org/browse/JDK-8311186) ProblemList javax/management/remote/mandatory/subjectDelegation/SubjectDelegation1Test.java on linux-aarch64
> - [JDK-8311189](https://bugs.openjdk.org/browse/JDK-8311189) disable gc/z/TestHighUsage.java
> - [JDK-8311190](https://bugs.openjdk.org/browse/JDK-8311190) ProblemList javax/management/remote/mandatory/connection/DeadLockTest.java with virtual threads on windows-x64
> - [JDK-8311191](https://bugs.openjdk.org/browse/JDK-8311191) ProblemList javax/management/remote/mandatory/connection/ConnectionTest.java with virtual threads on windows-x64
> - [JDK-8311193](https://bugs.openjdk.org/browse/JDK-8311193) ProblemList vmTestbase/nsk/jdb/interrupt/interrupt001/interrupt001.java on linux-all
> - [JDK-8311195](https://bugs.openjdk.org/browse/JDK-8311195) ProblemList vmTestbase/nsk/jvmti/scenarios/capability/CM03/cm03t001/TestDescription.java with Xcomp on macosx-x64

And my point is that the test executes only with Generational ZGC and cannot
always be ProblemListed via the ProblemList-generational-zgc.txt file.

The test internally specifies -XX:+UseZGC and -XX:+ZGenerational, but not
in a way where the ProblemList-generational-zgc.txt file comes into play.

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

PR Comment: https://git.openjdk.org/jdk/pull/14741#issuecomment-1615229673

From dcubed at openjdk.org  Fri Jun 30 22:27:09 2023
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Fri, 30 Jun 2023 22:27:09 GMT
Subject: [jdk21] RFR: 8311186: ProblemList
 javax/management/remote/mandatory/subjectDelegation/SubjectDelegation1Test.java
 on linux-aarch64
Message-ID: <WzLABA91v04See3wx5fbvgCeHdixDl3syZle3CztAPI=.ee919516-20e7-42ce-97c1-0988ac33f671@github.com>

Backport 140b70fb29e2b83e5d33765906ee76a36442a687

Trivial ProblemListing/disable changes:

[JDK-8311186](https://bugs.openjdk.org/browse/JDK-8311186) ProblemList javax/management/remote/mandatory/subjectDelegation/SubjectDelegation1Test.java on linux-aarch64
[JDK-8311189](https://bugs.openjdk.org/browse/JDK-8311189) disable gc/z/TestHighUsage.java
[JDK-8311190](https://bugs.openjdk.org/browse/JDK-8311190) ProblemList javax/management/remote/mandatory/connection/DeadLockTest.java with virtual threads on windows-x64
[JDK-8311191](https://bugs.openjdk.org/browse/JDK-8311191) ProblemList javax/management/remote/mandatory/connection/ConnectionTest.java with virtual threads on windows-x64
[JDK-8311193](https://bugs.openjdk.org/browse/JDK-8311193) ProblemList vmTestbase/nsk/jdb/interrupt/interrupt001/interrupt001.java on linux-all
[JDK-8311195](https://bugs.openjdk.org/browse/JDK-8311195) ProblemList vmTestbase/nsk/jvmti/scenarios/capability/CM03/cm03t001/TestDescription.java with Xcomp on macosx-x64

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

Commit messages:
 - Backport 140b70fb29e2b83e5d33765906ee76a36442a687

Changes: https://git.openjdk.org/jdk21/pull/88/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk21&pr=88&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8311186
  Stats: 13 lines in 6 files changed: 11 ins; 2 del; 0 mod
  Patch: https://git.openjdk.org/jdk21/pull/88.diff
  Fetch: git fetch https://git.openjdk.org/jdk21.git pull/88/head:pull/88

PR: https://git.openjdk.org/jdk21/pull/88

From lmesnik at openjdk.org  Fri Jun 30 22:30:54 2023
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Fri, 30 Jun 2023 22:30:54 GMT
Subject: [jdk21] RFR: 8311186: ProblemList
 javax/management/remote/mandatory/subjectDelegation/SubjectDelegation1Test.java
 on linux-aarch64
In-Reply-To: <WzLABA91v04See3wx5fbvgCeHdixDl3syZle3CztAPI=.ee919516-20e7-42ce-97c1-0988ac33f671@github.com>
References: <WzLABA91v04See3wx5fbvgCeHdixDl3syZle3CztAPI=.ee919516-20e7-42ce-97c1-0988ac33f671@github.com>
Message-ID: <PFsQPGDPprcqh0D3KbzIkVBi0MSSq9RWBqvQRnTUPOA=.54af3cc7-e6cd-4199-8089-b88cb9c0efb7@github.com>

On Fri, 30 Jun 2023 22:17:40 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> Backport 140b70fb29e2b83e5d33765906ee76a36442a687
> 
> Trivial ProblemListing/disable changes:
> 
> [JDK-8311186](https://bugs.openjdk.org/browse/JDK-8311186) ProblemList javax/management/remote/mandatory/subjectDelegation/SubjectDelegation1Test.java on linux-aarch64
> [JDK-8311189](https://bugs.openjdk.org/browse/JDK-8311189) disable gc/z/TestHighUsage.java
> [JDK-8311190](https://bugs.openjdk.org/browse/JDK-8311190) ProblemList javax/management/remote/mandatory/connection/DeadLockTest.java with virtual threads on windows-x64
> [JDK-8311191](https://bugs.openjdk.org/browse/JDK-8311191) ProblemList javax/management/remote/mandatory/connection/ConnectionTest.java with virtual threads on windows-x64
> [JDK-8311193](https://bugs.openjdk.org/browse/JDK-8311193) ProblemList vmTestbase/nsk/jdb/interrupt/interrupt001/interrupt001.java on linux-all
> [JDK-8311195](https://bugs.openjdk.org/browse/JDK-8311195) ProblemList vmTestbase/nsk/jvmti/scenarios/capability/CM03/cm03t001/TestDescription.java with Xcomp on macosx-x64

Marked as reviewed by lmesnik (Reviewer).

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

PR Review: https://git.openjdk.org/jdk21/pull/88#pullrequestreview-1507948046

From dcubed at openjdk.org  Fri Jun 30 22:33:53 2023
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Fri, 30 Jun 2023 22:33:53 GMT
Subject: [jdk21] RFR: 8311186: ProblemList
 javax/management/remote/mandatory/subjectDelegation/SubjectDelegation1Test.java
 on linux-aarch64
In-Reply-To: <PFsQPGDPprcqh0D3KbzIkVBi0MSSq9RWBqvQRnTUPOA=.54af3cc7-e6cd-4199-8089-b88cb9c0efb7@github.com>
References: <WzLABA91v04See3wx5fbvgCeHdixDl3syZle3CztAPI=.ee919516-20e7-42ce-97c1-0988ac33f671@github.com>
 <PFsQPGDPprcqh0D3KbzIkVBi0MSSq9RWBqvQRnTUPOA=.54af3cc7-e6cd-4199-8089-b88cb9c0efb7@github.com>
Message-ID: <ApYeW9cTGF-r8Y8yWiWCfInP_Ya5hYT8yuBGLh3lnP4=.ace9501c-83da-4c63-bde5-15a91df9f41c@github.com>

On Fri, 30 Jun 2023 22:28:34 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> Backport 140b70fb29e2b83e5d33765906ee76a36442a687
>> 
>> Trivial ProblemListing/disable changes:
>> 
>> [JDK-8311186](https://bugs.openjdk.org/browse/JDK-8311186) ProblemList javax/management/remote/mandatory/subjectDelegation/SubjectDelegation1Test.java on linux-aarch64
>> [JDK-8311189](https://bugs.openjdk.org/browse/JDK-8311189) disable gc/z/TestHighUsage.java
>> [JDK-8311190](https://bugs.openjdk.org/browse/JDK-8311190) ProblemList javax/management/remote/mandatory/connection/DeadLockTest.java with virtual threads on windows-x64
>> [JDK-8311191](https://bugs.openjdk.org/browse/JDK-8311191) ProblemList javax/management/remote/mandatory/connection/ConnectionTest.java with virtual threads on windows-x64
>> [JDK-8311193](https://bugs.openjdk.org/browse/JDK-8311193) ProblemList vmTestbase/nsk/jdb/interrupt/interrupt001/interrupt001.java on linux-all
>> [JDK-8311195](https://bugs.openjdk.org/browse/JDK-8311195) ProblemList vmTestbase/nsk/jvmti/scenarios/capability/CM03/cm03t001/TestDescription.java with Xcomp on macosx-x64
>
> Marked as reviewed by lmesnik (Reviewer).

@lmesnik - Thanks for the fast review!

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

PR Comment: https://git.openjdk.org/jdk21/pull/88#issuecomment-1615247775

From dcubed at openjdk.org  Fri Jun 30 22:37:01 2023
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Fri, 30 Jun 2023 22:37:01 GMT
Subject: [jdk21] Integrated: 8311186: ProblemList
 javax/management/remote/mandatory/subjectDelegation/SubjectDelegation1Test.java
 on linux-aarch64
In-Reply-To: <WzLABA91v04See3wx5fbvgCeHdixDl3syZle3CztAPI=.ee919516-20e7-42ce-97c1-0988ac33f671@github.com>
References: <WzLABA91v04See3wx5fbvgCeHdixDl3syZle3CztAPI=.ee919516-20e7-42ce-97c1-0988ac33f671@github.com>
Message-ID: <3iX8hQceMK6biOj8SOYxPBrrefYptA77mvkNsv64iwc=.60e786d3-70c2-4a59-8358-284bbb9311c9@github.com>

On Fri, 30 Jun 2023 22:17:40 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> Backport 140b70fb29e2b83e5d33765906ee76a36442a687
> 
> Trivial ProblemListing/disable changes:
> 
> [JDK-8311186](https://bugs.openjdk.org/browse/JDK-8311186) ProblemList javax/management/remote/mandatory/subjectDelegation/SubjectDelegation1Test.java on linux-aarch64
> [JDK-8311189](https://bugs.openjdk.org/browse/JDK-8311189) disable gc/z/TestHighUsage.java
> [JDK-8311190](https://bugs.openjdk.org/browse/JDK-8311190) ProblemList javax/management/remote/mandatory/connection/DeadLockTest.java with virtual threads on windows-x64
> [JDK-8311191](https://bugs.openjdk.org/browse/JDK-8311191) ProblemList javax/management/remote/mandatory/connection/ConnectionTest.java with virtual threads on windows-x64
> [JDK-8311193](https://bugs.openjdk.org/browse/JDK-8311193) ProblemList vmTestbase/nsk/jdb/interrupt/interrupt001/interrupt001.java on linux-all
> [JDK-8311195](https://bugs.openjdk.org/browse/JDK-8311195) ProblemList vmTestbase/nsk/jvmti/scenarios/capability/CM03/cm03t001/TestDescription.java with Xcomp on macosx-x64

This pull request has now been integrated.

Changeset: 35d592e3
Author:    Daniel D. Daugherty <dcubed at openjdk.org>
URL:       https://git.openjdk.org/jdk21/commit/35d592e39d2bc99543d1b6bf671fc73fbef35bc8
Stats:     13 lines in 6 files changed: 11 ins; 2 del; 0 mod

8311186: ProblemList javax/management/remote/mandatory/subjectDelegation/SubjectDelegation1Test.java on linux-aarch64
8311189: disable gc/z/TestHighUsage.java
8311190: ProblemList javax/management/remote/mandatory/connection/DeadLockTest.java with virtual threads on windows-x64
8311191: ProblemList javax/management/remote/mandatory/connection/ConnectionTest.java with virtual threads on windows-x64
8311193: ProblemList vmTestbase/nsk/jdb/interrupt/interrupt001/interrupt001.java on linux-all
8311195: ProblemList vmTestbase/nsk/jvmti/scenarios/capability/CM03/cm03t001/TestDescription.java with Xcomp on macosx-x64

Reviewed-by: lmesnik
Backport-of: 140b70fb29e2b83e5d33765906ee76a36442a687

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

PR: https://git.openjdk.org/jdk21/pull/88