From ysr at openjdk.org  Wed Nov  1 01:10:45 2023
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Wed, 1 Nov 2023 01:10:45 GMT
Subject: RFR: 8318462: [GenShen] Prevent unsafe access to displaced
 mark-word [v3]
In-Reply-To: <7WgrlAQun762-rhgugi6qSKkqbrJqAskJDBEDMJ8O6o=.9516f2e1-314a-4173-9b0d-d4e334884c2e@github.com>
References: <uOeuEpzRFvBx1AFgOvvTNfxJIyI4o84yT9D5A_q6BjU=.92103c05-893a-4b0b-a165-54289729f74f@github.com>
 <G4dtAHgyXda6zZiq16qHiyQWWCapLgkoW0dASfjLIF8=.14abe76d-7980-4227-9698-35ded44fc141@github.com>
 <S7Jx2poxtFfB7voH5TUPgzc40hy4jIPQGhHF6kW8VEM=.40dd23a1-78a4-4534-8a86-aa1d99ef7347@github.com>
 <62iAP1xppfg6WDXm-ZdoT8cugt1L-2athpTtFc145M8=.9e763172-f272-4675-93a7-3733d63b335b@github.com>
 <KsJtEqDREZmNhyzaiGDx04yXm_SW-1q-dsrryuS65qc=.2084b551-eade-48e2-ad49-316a7a69f25b@github.com>
 <3ZaUyCn3Fxysz9hN4CK8EHQmDiGW3VEK8eIiBhFM70k=.e9b27e34-c63c-419a-b6b8-4af376c28480@github.com>
 <7WgrlAQun762-rhgugi6qSKkqbrJqAskJDBEDMJ8O6o=.9516f2e1-314a-4173-9b0d-d4e334884c2e@github.com>
Message-ID: <UqHacbyQGuk1rcaQDdWbBlEaqG9YG1IFVCGufSRt8sk=.84027b9b-070a-46f5-8c49-552cc68bfe2d@github.com>

On Tue, 31 Oct 2023 23:21:43 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> The add method of ShenandoahAgeCensus explicitly recognizes and uses the sentinel value, and explicitly skips sentinels that are used to signal that the age could not be read:
>> 
>> 
>> CENSUS_NOISE(void ShenandoahAgeCensus::add(uint obj_age, uint region_age, uint region_youth, size_t size, uint worker_id) {)
>> NO_CENSUS_NOISE(void ShenandoahAgeCensus::add(uint obj_age, uint region_age, size_t size, uint worker_id) {)
>>   if (obj_age <= markWord::max_age) {
>>     assert(obj_age < MAX_COHORTS && region_age < MAX_COHORTS, "Should have been tenured");
>> #ifdef SHENANDOAH_CENSUS_NOISE
>>     // Region ageing is stochastic and non-monotonic; this vitiates mortality
>>     // demographics in ways that might defeat our algorithms. Marking may be a
>>     // time when we might be able to correct this, but we currently do not do
>>     // this. Like skipped statistics further below, we want to track the
>>     // impact of this noise to see if this may be worthwhile. JDK-<TBD>.
>>     uint age = obj_age;
>>     if (region_age > 0) {
>>       add_aged(size, worker_id);   // this tracking is coarse for now
>>       age += region_age;
>>       if (age >= MAX_COHORTS) {
>>         age = (uint)(MAX_COHORTS - 1);  // clamp
>>         add_clamped(size, worker_id);
>>       }
>>     }
>>     if (region_youth > 0) {   // track object volume with retrograde age
>>       add_young(size, worker_id);
>>     }
>> #else   // SHENANDOAH_CENSUS_NOISE
>>     uint age = MIN2(obj_age + region_age, (uint)(MAX_COHORTS - 1));  // clamp
>> #endif  // SHENANDOAH_CENSUS_NOISE
>>     get_local_age_table(worker_id)->add(age, size);
>>   } else {
>>     // update skipped statistics
>>     CENSUS_NOISE(add_skipped(size, worker_id);)
>>   }
>> }
>> 
>> 
>> I think we should leave in place the original code, where all of the special handling of the sentinel values is relegated to the ShenandoahAgeCensus's add method, with no special handling needed at the caller.
>
> Thanks.  That looks good.  I concur.

I realize though that your comment kind of applies to the evacuation tracker code that needs to be cognizant of the change in the semantics of `get_object_age` following Roman's change.

This is the relevant call at:
https://github.com/openjdk/shenandoah/blob/113a3d2bbec5679a9c25550fc825feb75a7b41e8/src/hotspot/share/gc/shenandoah/shenandoahHeap.inline.hpp#L491
which lands us at:
https://github.com/openjdk/shenandoah/blob/113a3d2bbec5679a9c25550fc825feb75a7b41e8/src/hotspot/share/gc/shenandoah/shenandoahEvacTracker.cpp#L60
and thence at:
https://github.com/openjdk/shenandoah/blob/113a3d2bbec5679a9c25550fc825feb75a7b41e8/src/hotspot/share/gc/shared/ageTable.hpp#L63
which might either assert or silently overflow past the end of the table.

It would be useful to filter those records out in ShenandoahEvacuationStats::record_age() or at the caller.

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

PR Review Comment: https://git.openjdk.org/shenandoah/pull/343#discussion_r1378299556

From wkemper at openjdk.org  Wed Nov  1 12:37:35 2023
From: wkemper at openjdk.org (William Kemper)
Date: Wed, 1 Nov 2023 12:37:35 GMT
Subject: RFR: 8318462: [GenShen] Prevent unsafe access to displaced
 mark-word [v4]
In-Reply-To: <7g3I1quU1AP4udb0EdB_s_8dK1coaiFR8wGTEUZ2ASw=.4102020d-3d17-4901-87da-7a47bb4106fd@github.com>
References: <uOeuEpzRFvBx1AFgOvvTNfxJIyI4o84yT9D5A_q6BjU=.92103c05-893a-4b0b-a165-54289729f74f@github.com>
 <7g3I1quU1AP4udb0EdB_s_8dK1coaiFR8wGTEUZ2ASw=.4102020d-3d17-4901-87da-7a47bb4106fd@github.com>
Message-ID: <ysjhCAhlNhdnZniB5HOz1pb-0SoaJmPPbWgKjKu9eaY=.40df6602-7892-4ca0-b0ca-c3f900997521@github.com>

On Tue, 31 Oct 2023 09:51:29 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> We must be very careful when we access (load or update) the object age concurrently because the age is stored in the object's header and that header can be 'displaced'. This means that the header is overloaded with a pointer (stack or ObjectMonitor*) and the original header is stored at that location. The header can also be in INFLATING state, which means that a stack-lock is currently in the process to be inflated to an ObjectMonitor. Let's consider the cases separately:
>> 
>> Loading object age:
>> - INFLATING: we can not access the header, and thus not the age.
>> - Stack-locked: the thread which locks the object can unlock at any time, concurrently. It is not safe to access the header, and thus the age.
>> - Monitor-locked: monitors don't go away without coordinating with Java threads and possibly GC threads. This coordination is done by handshaking the thread - a Java thread would be brought to its next safepoint, and GC threads, which are typically participating in handshakes by joining the SuspendibleThreadSet, can opt to handshake at a safe point by calling SuspendibleThreadSet::yield(). If 'our' thread participates in handshakes in one way or the other, it is safe to access an ObjectMonitor once we got a valid ObjectMonitor* from an object's header, but only until that thread handshakes. Long story short: it is typically safe to access ObjectMonitor :-)
>> 
>> Updating object age:
>> Updating object age only happens during evacuation, and only on a new copy of an object, before that copy has been published. Access to the object header is therefore fully thread-local and not problematic. What *is* problematic is when we have to deal with displaced headers, because displaced headers are *not* thread local, and must be considered a shared resource. A competing thread may succeed to evacuate the object and publish its copy before 'our' thread can do so. If 'our' thread would update the displaced header, it may over-write whatever the other thread has done.
>> - INFLATING: We cannot access the header at all. However, that should not happen: a thread can only inflate once it has successfully evacuated an object, and 
>> - Stack-locked: the other thread may succeed evacuation and continue to unlock the object, at which point the stack-pointer would be 'dangling' and we may over-write random information on the foreign thread stack.
>> - Monitor-locked: even though monitor deflation is coordinated (see above), updating the displaced header in a monitor might over-...
>
> Roman Kennke has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Treat age sentinel correctly
>  - Fix comment formatting

Internal testing looks good.

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

Marked as reviewed by wkemper (Committer).

PR Review: https://git.openjdk.org/shenandoah/pull/343#pullrequestreview-1708129567

From zgu at openjdk.org  Wed Nov  1 13:29:59 2023
From: zgu at openjdk.org (Zhengyu Gu)
Date: Wed, 1 Nov 2023 13:29:59 GMT
Subject: RFR: 8318462: [GenShen] Prevent unsafe access to displaced
 mark-word [v2]
In-Reply-To: <AXtEGeCXjkjSAQ2WvwkGeSI-fEDm9MRKujSaPXcPTWc=.728e373c-a3b7-437e-8694-e29748acd4fa@github.com>
References: <uOeuEpzRFvBx1AFgOvvTNfxJIyI4o84yT9D5A_q6BjU=.92103c05-893a-4b0b-a165-54289729f74f@github.com>
 <2lwvFiHSE-N-kXfzhKYx4HhQASkwI01cjVO_tPJ_KZI=.5c873318-cb3f-44e6-8745-d6f5cbe3e52d@github.com>
 <feghfM7FVv2wf1ImOidYnLI0eSGm27pDetlSsk4lmIU=.2a68f506-fc4a-4aea-bf27-f6812d859e8d@github.com>
 <AXtEGeCXjkjSAQ2WvwkGeSI-fEDm9MRKujSaPXcPTWc=.728e373c-a3b7-437e-8694-e29748acd4fa@github.com>
Message-ID: <u1mkVvSzlJfy3POuWkjnRSZ_3JSq-0ahO3Idg_xsk98=.58598511-e471-4dc7-a88c-449d2acdf9cc@github.com>

On Tue, 31 Oct 2023 09:39:45 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> > Just FYI: Here is another place to update object age, probably you want to consolidate.
> > https://github.com/openjdk/shenandoah/blob/master/src/hotspot/share/gc/shenandoah/shenandoahStringDedup.inline.hpp#L55
> 
> Right. The problem there is that this block of code does a sort of concurrent/atomic update of the object age that would require re-working and/or adding age helper methods. I'd rather not do that now.

I think for GenShen, StringDeduplication should not update age, so code can just be simplified as following:


bool ShenandoahStringDedup::is_candidate(oop obj) {
  if (!is_string_candidate(obj)) {
    return false;
  }

  const markWord mark = obj->mark();

  // Having/had displaced header, too risky to deal with them, skip
  if ((LockingMode != LM_LIGHTWEIGHT && mark == markWord::INFLATING()) || mark.has_displaced_mark_helper()) {
    return false;
  }

  return StringDedup::is_threshold_age(new_mark.age()) &&
             !dedup_requested(obj);
}

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

PR Comment: https://git.openjdk.org/shenandoah/pull/343#issuecomment-1788955550

From kdnilsen at openjdk.org  Wed Nov  1 16:06:55 2023
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Wed, 1 Nov 2023 16:06:55 GMT
Subject: RFR: 8319198: GenShen: Old at end of Full GC must include newly
 promoted objects
Message-ID: <FUY4bRy5inYwg1GEDJfzS5LVi6wT4Il821F0khQdHkw=.2fd5f11e-6de9-48b9-9f01-e40c57cfd24b@github.com>

At end of Full GC, remember live bytes after last old-gen mark after promotions are completed rather than immediately after old marking is completed.  This is a more accurate representation of old live.  This reduces the likelihood that we will need to immediately trigger another old-gen GC following the Full GC.

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

Commit messages:
 - Record old-gen live after promotion is done

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

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

From wkemper at openjdk.org  Wed Nov  1 16:20:36 2023
From: wkemper at openjdk.org (William Kemper)
Date: Wed, 1 Nov 2023 16:20:36 GMT
Subject: RFR: 8319198: GenShen: Old at end of Full GC must include newly
 promoted objects
In-Reply-To: <FUY4bRy5inYwg1GEDJfzS5LVi6wT4Il821F0khQdHkw=.2fd5f11e-6de9-48b9-9f01-e40c57cfd24b@github.com>
References: <FUY4bRy5inYwg1GEDJfzS5LVi6wT4Il821F0khQdHkw=.2fd5f11e-6de9-48b9-9f01-e40c57cfd24b@github.com>
Message-ID: <hJpXo8I3No1OVEzPhoC5xFrNL218Mm_0dwMw6iM5FW4=.e8524e59-f63e-41a4-9d7a-ce6abdb30856@github.com>

On Wed, 1 Nov 2023 16:01:34 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

> At end of Full GC, remember live bytes after last old-gen mark after promotions are completed rather than immediately after old marking is completed.  This is a more accurate representation of old live.  This reduces the likelihood that we will need to immediately trigger another old-gen GC following the Full GC.

Looks good to me.

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

Marked as reviewed by wkemper (Committer).

PR Review: https://git.openjdk.org/shenandoah/pull/350#pullrequestreview-1708565899

From kdnilsen at openjdk.org  Wed Nov  1 17:38:09 2023
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Wed, 1 Nov 2023 17:38:09 GMT
Subject: Integrated: 8319198: GenShen: Old at end of Full GC must include newly
 promoted objects
In-Reply-To: <FUY4bRy5inYwg1GEDJfzS5LVi6wT4Il821F0khQdHkw=.2fd5f11e-6de9-48b9-9f01-e40c57cfd24b@github.com>
References: <FUY4bRy5inYwg1GEDJfzS5LVi6wT4Il821F0khQdHkw=.2fd5f11e-6de9-48b9-9f01-e40c57cfd24b@github.com>
Message-ID: <Q4BmrWUck4M6l2DLhieOODpCx6SUEF3kJlCw3-lTj-E=.7fd959bb-b2be-46cd-9191-9a339032262c@github.com>

On Wed, 1 Nov 2023 16:01:34 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

> At end of Full GC, remember live bytes after last old-gen mark after promotions are completed rather than immediately after old marking is completed.  This is a more accurate representation of old live.  This reduces the likelihood that we will need to immediately trigger another old-gen GC following the Full GC.

This pull request has now been integrated.

Changeset: e4a8a438
Author:    Kelvin Nilsen <kdnilsen at openjdk.org>
URL:       https://git.openjdk.org/shenandoah/commit/e4a8a43806537303fbf18a062ac536f0c2729551
Stats:     4 lines in 1 file changed: 3 ins; 1 del; 0 mod

8319198: GenShen: Old at end of Full GC must include newly promoted objects

Reviewed-by: wkemper

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

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

From wkemper at openjdk.org  Wed Nov  1 17:48:46 2023
From: wkemper at openjdk.org (William Kemper)
Date: Wed, 1 Nov 2023 17:48:46 GMT
Subject: RFR: Merge openjdk/jdk:master [v2]
In-Reply-To: <EeGf2W-QhnzG0LiDC_e_fVlf8xwLbUCj4C5d0dRXqXA=.b9c16e1d-6129-4589-9f38-d8747282c255@github.com>
References: <sNtakAFQZaJykc9t8PSoYuscumjUbDUPENz6htHhFqk=.f7831246-671e-4790-8701-27be6b2773dc@github.com>
 <EeGf2W-QhnzG0LiDC_e_fVlf8xwLbUCj4C5d0dRXqXA=.b9c16e1d-6129-4589-9f38-d8747282c255@github.com>
Message-ID: <VsgK11qZs50BQSb80hgzO3tIyM2hqFsHmEMfPTo6zhQ=.aabd48d8-92f8-4a84-a794-7f673aeee20f@github.com>

On Fri, 20 Oct 2023 15:47:44 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> Merges tag jdk-22+20
>
> William Kemper has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 128 commits:
> 
>  - Merge remote-tracking branch 'shenandoah/master' into merge-jdk-22+20
>  - 8318363: Foreign benchmarks fail to build on some platforms
>    
>    Reviewed-by: jvernee, mcimadamore
>  - 8318183: C2: VM may crash after hitting node limit
>    
>    Reviewed-by: kvn, thartmann
>  - 8315974: Make fields final in 'com.sun.crypto.provider' package
>    
>    Reviewed-by: valeriep
>  - 8317886: Add @sealedGraph to ByteBuffer
>    
>    Reviewed-by: rriggs, iris
>  - 8318365: Test runtime/cds/appcds/sharedStrings/InternSharedString.java fails after JDK-8311538
>    
>    Reviewed-by: cjplummer, lmesnik
>  - 8309966: Enhanced TLS connections
>    
>    Reviewed-by: mschoene, hchao, rhalade, jnimeh
>  - 8286503: Enhance security classes
>    
>    Reviewed-by: rhalade, mullan, skoivu, weijun
>  - 8297856: Improve handling of Bidi characters
>    
>    Reviewed-by: rhalade, mschoene, rriggs
>  - 8296581: Better system proxy support
>    
>    Reviewed-by: rhalade, dfuchs, michaelm, alanb
>  - ... and 118 more: https://git.openjdk.org/shenandoah/compare/ac30d485...de29536b

Superseded by PR to merge jdk-22+21.

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

PR Comment: https://git.openjdk.org/shenandoah/pull/346#issuecomment-1789389504

From wkemper at openjdk.org  Wed Nov  1 17:48:46 2023
From: wkemper at openjdk.org (William Kemper)
Date: Wed, 1 Nov 2023 17:48:46 GMT
Subject: Withdrawn: Merge openjdk/jdk:master
In-Reply-To: <sNtakAFQZaJykc9t8PSoYuscumjUbDUPENz6htHhFqk=.f7831246-671e-4790-8701-27be6b2773dc@github.com>
References: <sNtakAFQZaJykc9t8PSoYuscumjUbDUPENz6htHhFqk=.f7831246-671e-4790-8701-27be6b2773dc@github.com>
Message-ID: <TQeDbLOiQ71VloI1myBA7RsuAruvqBF7NiT8ho2qmUE=.87da88c3-80b1-4a53-9447-9004243cc0b3@github.com>

On Thu, 19 Oct 2023 22:17:19 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Merges tag jdk-22+20

This pull request has been closed without being integrated.

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

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

From rkennke at openjdk.org  Thu Nov  2 11:52:56 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Thu, 2 Nov 2023 11:52:56 GMT
Subject: RFR: 8318462: [GenShen] Prevent unsafe access to displaced
 mark-word [v5]
In-Reply-To: <uOeuEpzRFvBx1AFgOvvTNfxJIyI4o84yT9D5A_q6BjU=.92103c05-893a-4b0b-a165-54289729f74f@github.com>
References: <uOeuEpzRFvBx1AFgOvvTNfxJIyI4o84yT9D5A_q6BjU=.92103c05-893a-4b0b-a165-54289729f74f@github.com>
Message-ID: <y-ptOV2dCTKCql_rlIqNssEBMtGNXh8pf5HIbVXYJJo=.1c0b02dc-a92f-455f-95d4-8e8b3e3d71d5@github.com>

> We must be very careful when we access (load or update) the object age concurrently because the age is stored in the object's header and that header can be 'displaced'. This means that the header is overloaded with a pointer (stack or ObjectMonitor*) and the original header is stored at that location. The header can also be in INFLATING state, which means that a stack-lock is currently in the process to be inflated to an ObjectMonitor. Let's consider the cases separately:
> 
> Loading object age:
> - INFLATING: we can not access the header, and thus not the age.
> - Stack-locked: the thread which locks the object can unlock at any time, concurrently. It is not safe to access the header, and thus the age.
> - Monitor-locked: monitors don't go away without coordinating with Java threads and possibly GC threads. This coordination is done by handshaking the thread - a Java thread would be brought to its next safepoint, and GC threads, which are typically participating in handshakes by joining the SuspendibleThreadSet, can opt to handshake at a safe point by calling SuspendibleThreadSet::yield(). If 'our' thread participates in handshakes in one way or the other, it is safe to access an ObjectMonitor once we got a valid ObjectMonitor* from an object's header, but only until that thread handshakes. Long story short: it is typically safe to access ObjectMonitor :-)
> 
> Updating object age:
> Updating object age only happens during evacuation, and only on a new copy of an object, before that copy has been published. Access to the object header is therefore fully thread-local and not problematic. What *is* problematic is when we have to deal with displaced headers, because displaced headers are *not* thread local, and must be considered a shared resource. A competing thread may succeed to evacuate the object and publish its copy before 'our' thread can do so. If 'our' thread would update the displaced header, it may over-write whatever the other thread has done.
> - INFLATING: We cannot access the header at all. However, that should not happen: a thread can only inflate once it has successfully evacuated an object, and 
> - Stack-locked: the other thread may succeed evacuation and continue to unlock the object, at which point the stack-pointer would be 'dangling' and we may over-write random information on the foreign thread stack.
> - Monitor-locked: even though monitor deflation is coordinated (see above), updating the displaced header in a monitor might over-write whatever a competi...

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

  Simplify string-dedup age handling

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

Changes:
  - all: https://git.openjdk.org/shenandoah/pull/343/files
  - new: https://git.openjdk.org/shenandoah/pull/343/files/113a3d2b..969e4650

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

  Stats: 21 lines in 1 file changed: 3 ins; 14 del; 4 mod
  Patch: https://git.openjdk.org/shenandoah/pull/343.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah.git pull/343/head:pull/343

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

From wkemper at openjdk.org  Thu Nov  2 14:15:58 2023
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 2 Nov 2023 14:15:58 GMT
Subject: RFR: Merge openjdk/jdk:master
Message-ID: <EZt6H-Ey6cRguW0Uigj4WT7JgqcJq0Rew1VTAnSy0QM=.48d20e80-ff9d-43cd-97be-27796afcb8a5@github.com>

Merges tag jdk-22+22

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

Commit messages:
 - 8318694: [JVMCI] disable can_call_java in most contexts for libjvmci compiler threads
 - 8319046: Execute tests in source/class-file order in JavadocTester
 - 8319139: Improve diagnosability of `JavadocTester` output
 - 8316025: Use testUI() method of PassFailJFrame.Builder in FileChooserSymLinkTest.java
 - 8317048: VerifyError with unnamed pattern variable and more than one components
 - 8318647: Serial: Refactor BlockOffsetTable
 - 8304939: os::win32::exit_process_or_thread should be marked noreturn
 - 8318016: Per-compilation memory ceiling
 - 8318683: compiler/c2/irTests/TestPhiDuplicatedConversion.java "Failed IR Rules (2) of Methods (2)"
 - 8306980: Generated docs should contain correct Legal Documents
 - ... and 66 more: https://git.openjdk.org/shenandoah/compare/d96f38b8...d354141a

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

Changes: https://git.openjdk.org/shenandoah/pull/351/files
  Stats: 27458 lines in 1170 files changed: 14959 ins; 4156 del; 8343 mod
  Patch: https://git.openjdk.org/shenandoah/pull/351.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah.git pull/351/head:pull/351

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

From wkemper at openjdk.org  Thu Nov  2 16:29:38 2023
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 2 Nov 2023 16:29:38 GMT
Subject: RFR: Merge openjdk/jdk:master [v2]
In-Reply-To: <EZt6H-Ey6cRguW0Uigj4WT7JgqcJq0Rew1VTAnSy0QM=.48d20e80-ff9d-43cd-97be-27796afcb8a5@github.com>
References: <EZt6H-Ey6cRguW0Uigj4WT7JgqcJq0Rew1VTAnSy0QM=.48d20e80-ff9d-43cd-97be-27796afcb8a5@github.com>
Message-ID: <8uEDs5EvShRtlND-ytX70TgezC0-5w3OhvtSLVD-Rsw=.1d7eb8e7-bdff-4cb8-b03b-47f79f655829@github.com>

> Merges tag jdk-22+22

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

 - Merge branch 'shenandoah/master' into merge-jdk-22+22
 - 8318694: [JVMCI] disable can_call_java in most contexts for libjvmci compiler threads
   
   Reviewed-by: dholmes, never
 - 8319046: Execute tests in source/class-file order in JavadocTester
   
   Reviewed-by: hannesw
 - 8319139: Improve diagnosability of `JavadocTester` output
   
   Reviewed-by: hannesw
 - 8316025: Use testUI() method of PassFailJFrame.Builder in FileChooserSymLinkTest.java
   
   Reviewed-by: azvegint
 - 8317048: VerifyError with unnamed pattern variable and more than one components
   
   Reviewed-by: jlahoda
 - 8318647: Serial: Refactor BlockOffsetTable
   
   Reviewed-by: tschatzl, iwalulya
 - 8304939: os::win32::exit_process_or_thread should be marked noreturn
   
   Reviewed-by: dholmes, kbarrett
 - 8318016: Per-compilation memory ceiling
   
   Reviewed-by: roland, thartmann
 - 8318683: compiler/c2/irTests/TestPhiDuplicatedConversion.java "Failed IR Rules (2) of Methods (2)"
   
   Reviewed-by: thartmann, kvn
 - ... and 67 more: https://git.openjdk.org/shenandoah/compare/e4a8a438...578915b0

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

Changes: https://git.openjdk.org/shenandoah/pull/351/files
 Webrev: https://webrevs.openjdk.org/?repo=shenandoah&pr=351&range=01
  Stats: 27452 lines in 1168 files changed: 14955 ins; 4156 del; 8341 mod
  Patch: https://git.openjdk.org/shenandoah/pull/351.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah.git pull/351/head:pull/351

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

From cslucas at openjdk.org  Thu Nov  2 22:36:20 2023
From: cslucas at openjdk.org (Cesar Soares Lucas)
Date: Thu, 2 Nov 2023 22:36:20 GMT
Subject: RFR: JDK-8241503: C2: Share MacroAssembler between mach nodes during
 code emission
Message-ID: <ExCrwPns55nw2P62UI3vzSVTmFCh3dzJq7u3Kugp9EA=.c20cd86c-2c16-4869-ba7f-76f2a53821d0@github.com>

# Description

Please review this PR with a patch to re-use the same C2_MacroAssembler object to emit all instructions in the same compilation unit.

Overall, the change is pretty simple. However, due to the renaming of the variable to access C2_MacroAssembler, from `_masm.` to `masm->`, and also some method prototype changes, the patch became quite large.

# Help Needed for Testing

I don't have access to all platforms necessary to test this. I hope some other folks can help with testing on `S390`, `RISC-V` and `PPC`.

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

Commit messages:
 - Reuse same C2_MacroAssembler object to emit instructions.

Changes: https://git.openjdk.org/jdk/pull/16484/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16484&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8241503
  Stats: 2665 lines in 60 files changed: 112 ins; 429 del; 2124 mod
  Patch: https://git.openjdk.org/jdk/pull/16484.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16484/head:pull/16484

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

From mdoerr at openjdk.org  Thu Nov  2 23:24:05 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Thu, 2 Nov 2023 23:24:05 GMT
Subject: RFR: JDK-8241503: C2: Share MacroAssembler between mach nodes
 during code emission
In-Reply-To: <ExCrwPns55nw2P62UI3vzSVTmFCh3dzJq7u3Kugp9EA=.c20cd86c-2c16-4869-ba7f-76f2a53821d0@github.com>
References: <ExCrwPns55nw2P62UI3vzSVTmFCh3dzJq7u3Kugp9EA=.c20cd86c-2c16-4869-ba7f-76f2a53821d0@github.com>
Message-ID: <BJtlt-cQZXjDRa0F5QbiqHe_3y-Ih58tlRScZy1H-Ps=.86398c74-3a29-4b8b-b7c6-9e7b6a75cdf9@github.com>

On Thu, 2 Nov 2023 22:17:43 GMT, Cesar Soares Lucas <cslucas at openjdk.org> wrote:

> # Description
> 
> Please review this PR with a patch to re-use the same C2_MacroAssembler object to emit all instructions in the same compilation unit.
> 
> Overall, the change is pretty simple. However, due to the renaming of the variable to access C2_MacroAssembler, from `_masm.` to `masm->`, and also some method prototype changes, the patch became quite large.
> 
> # Help Needed for Testing
> 
> I don't have access to all platforms necessary to test this. I hope some other folks can help with testing on `S390`, `RISC-V` and `PPC`.

PPC64 runs into assert(masm->inst_mark() == nullptr) failed: should be.
V  [libjvm.so+0x1648528]  PhaseOutput::fill_buffer(C2_MacroAssembler*, unsigned int*)+0x10c8  (output.cpp:1812)
V  [libjvm.so+0x164b35c]  PhaseOutput::Output()+0xd5c  (output.cpp:362)
V  [libjvm.so+0x958f9c]  Compile::Code_Gen()+0x4ec  (compile.cpp:2989)
V  [libjvm.so+0x95e484]  Compile::Compile(ciEnv*, ciMethod*, int, Options, DirectiveSet*)+0x1a84  (compile.cpp:887)
V  [libjvm.so+0x718f58]  C2Compiler::compile_method(ciEnv*, ciMethod*, int, bool, DirectiveSet*)+0x198  (c2compiler.cpp:119)

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

PR Comment: https://git.openjdk.org/jdk/pull/16484#issuecomment-1791694904

From cslucas at openjdk.org  Thu Nov  2 23:39:02 2023
From: cslucas at openjdk.org (Cesar Soares Lucas)
Date: Thu, 2 Nov 2023 23:39:02 GMT
Subject: RFR: JDK-8241503: C2: Share MacroAssembler between mach nodes
 during code emission
In-Reply-To: <BJtlt-cQZXjDRa0F5QbiqHe_3y-Ih58tlRScZy1H-Ps=.86398c74-3a29-4b8b-b7c6-9e7b6a75cdf9@github.com>
References: <ExCrwPns55nw2P62UI3vzSVTmFCh3dzJq7u3Kugp9EA=.c20cd86c-2c16-4869-ba7f-76f2a53821d0@github.com>
 <BJtlt-cQZXjDRa0F5QbiqHe_3y-Ih58tlRScZy1H-Ps=.86398c74-3a29-4b8b-b7c6-9e7b6a75cdf9@github.com>
Message-ID: <4LqTlmsaVA4gGTi5WQNjhn9KCN9SotYddp9SpdIpv-g=.294ccf81-e719-4621-8384-10242d2d7e95@github.com>

On Thu, 2 Nov 2023 23:21:23 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> # Description
>> 
>> Please review this PR with a patch to re-use the same C2_MacroAssembler object to emit all instructions in the same compilation unit.
>> 
>> Overall, the change is pretty simple. However, due to the renaming of the variable to access C2_MacroAssembler, from `_masm.` to `masm->`, and also some method prototype changes, the patch became quite large.
>> 
>> # Help Needed for Testing
>> 
>> I don't have access to all platforms necessary to test this. I hope some other folks can help with testing on `S390`, `RISC-V` and `PPC`.
>
> PPC64 runs into assert(masm->inst_mark() == nullptr) failed: should be.
> V  [libjvm.so+0x1648528]  PhaseOutput::fill_buffer(C2_MacroAssembler*, unsigned int*)+0x10c8  (output.cpp:1812)
> V  [libjvm.so+0x164b35c]  PhaseOutput::Output()+0xd5c  (output.cpp:362)
> V  [libjvm.so+0x958f9c]  Compile::Code_Gen()+0x4ec  (compile.cpp:2989)
> V  [libjvm.so+0x95e484]  Compile::Compile(ciEnv*, ciMethod*, int, Options, DirectiveSet*)+0x1a84  (compile.cpp:887)
> V  [libjvm.so+0x718f58]  C2Compiler::compile_method(ciEnv*, ciMethod*, int, bool, DirectiveSet*)+0x198  (c2compiler.cpp:119)

@TheRealMDoerr - this is likely because of some missing `clear_inst_mark` call on my part in the PPC ad, I'll take a look into it.

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

PR Comment: https://git.openjdk.org/jdk/pull/16484#issuecomment-1791705658

From ysr at openjdk.org  Fri Nov  3 00:24:47 2023
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Fri, 3 Nov 2023 00:24:47 GMT
Subject: RFR: Merge openjdk/jdk:master [v2]
In-Reply-To: <8uEDs5EvShRtlND-ytX70TgezC0-5w3OhvtSLVD-Rsw=.1d7eb8e7-bdff-4cb8-b03b-47f79f655829@github.com>
References: <EZt6H-Ey6cRguW0Uigj4WT7JgqcJq0Rew1VTAnSy0QM=.48d20e80-ff9d-43cd-97be-27796afcb8a5@github.com>
 <8uEDs5EvShRtlND-ytX70TgezC0-5w3OhvtSLVD-Rsw=.1d7eb8e7-bdff-4cb8-b03b-47f79f655829@github.com>
Message-ID: <d_cTL9r9RxWp0oBzxefRo55LBcJARUju6awifEr1tKQ=.9c7c4f4b-6016-42a9-9041-e67887e7a5e5@github.com>

On Thu, 2 Nov 2023 16:29:38 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> Merges tag jdk-22+22
>
> William Kemper has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 77 commits:
> 
>  - Merge branch 'shenandoah/master' into merge-jdk-22+22
>  - 8318694: [JVMCI] disable can_call_java in most contexts for libjvmci compiler threads
>    
>    Reviewed-by: dholmes, never
>  - 8319046: Execute tests in source/class-file order in JavadocTester
>    
>    Reviewed-by: hannesw
>  - 8319139: Improve diagnosability of `JavadocTester` output
>    
>    Reviewed-by: hannesw
>  - 8316025: Use testUI() method of PassFailJFrame.Builder in FileChooserSymLinkTest.java
>    
>    Reviewed-by: azvegint
>  - 8317048: VerifyError with unnamed pattern variable and more than one components
>    
>    Reviewed-by: jlahoda
>  - 8318647: Serial: Refactor BlockOffsetTable
>    
>    Reviewed-by: tschatzl, iwalulya
>  - 8304939: os::win32::exit_process_or_thread should be marked noreturn
>    
>    Reviewed-by: dholmes, kbarrett
>  - 8318016: Per-compilation memory ceiling
>    
>    Reviewed-by: roland, thartmann
>  - 8318683: compiler/c2/irTests/TestPhiDuplicatedConversion.java "Failed IR Rules (2) of Methods (2)"
>    
>    Reviewed-by: thartmann, kvn
>  - ... and 67 more: https://git.openjdk.org/shenandoah/compare/e4a8a438...578915b0

@earthling-amzn : it looks like a few shenandoah only tests e.g.:
https://github.com/earthling-amzn/shenandoah/actions/runs/6735431147#user-content-gc_shenandoah_oom_testthreadfailure

need to be changed to accommodate the changes to ProcessTools:

https://github.com/earthling-amzn/shenandoah/blob/578915b06592d273a986a9d56a7631ea7f5995f8/test/lib/jdk/test/lib/process/ProcessTools.java#L505

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

PR Comment: https://git.openjdk.org/shenandoah/pull/351#issuecomment-1791736274

From dlong at openjdk.org  Fri Nov  3 01:47:02 2023
From: dlong at openjdk.org (Dean Long)
Date: Fri, 3 Nov 2023 01:47:02 GMT
Subject: RFR: JDK-8241503: C2: Share MacroAssembler between mach nodes
 during code emission
In-Reply-To: <ExCrwPns55nw2P62UI3vzSVTmFCh3dzJq7u3Kugp9EA=.c20cd86c-2c16-4869-ba7f-76f2a53821d0@github.com>
References: <ExCrwPns55nw2P62UI3vzSVTmFCh3dzJq7u3Kugp9EA=.c20cd86c-2c16-4869-ba7f-76f2a53821d0@github.com>
Message-ID: <UGrpyynLCpoOo2S1FPh_i4G44QflcSFCFr42qvQrBVI=.d6495455-c652-4447-be5c-c1c7df457a72@github.com>

On Thu, 2 Nov 2023 22:17:43 GMT, Cesar Soares Lucas <cslucas at openjdk.org> wrote:

> # Description
> 
> Please review this PR with a patch to re-use the same C2_MacroAssembler object to emit all instructions in the same compilation unit.
> 
> Overall, the change is pretty simple. However, due to the renaming of the variable to access C2_MacroAssembler, from `_masm.` to `masm->`, and also some method prototype changes, the patch became quite large.
> 
> # Help Needed for Testing
> 
> I don't have access to all platforms necessary to test this. I hope some other folks can help with testing on `S390`, `RISC-V` and `PPC`.

src/hotspot/cpu/x86/gc/z/z_x86_64.ad line 37:

> 35: #include "gc/z/zBarrierSetAssembler.hpp"
> 36: 
> 37: static void z_color(MacroAssembler* masm, const MachNode* node, Register ref) {

For files already using MacroAssembler& _masm, the only change needed is this at the top:

undef __
#define __ _masm.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16484#discussion_r1381015121

From dlong at openjdk.org  Fri Nov  3 02:07:10 2023
From: dlong at openjdk.org (Dean Long)
Date: Fri, 3 Nov 2023 02:07:10 GMT
Subject: RFR: JDK-8241503: C2: Share MacroAssembler between mach nodes
 during code emission
In-Reply-To: <UGrpyynLCpoOo2S1FPh_i4G44QflcSFCFr42qvQrBVI=.d6495455-c652-4447-be5c-c1c7df457a72@github.com>
References: <ExCrwPns55nw2P62UI3vzSVTmFCh3dzJq7u3Kugp9EA=.c20cd86c-2c16-4869-ba7f-76f2a53821d0@github.com>
 <UGrpyynLCpoOo2S1FPh_i4G44QflcSFCFr42qvQrBVI=.d6495455-c652-4447-be5c-c1c7df457a72@github.com>
Message-ID: <CzmCsBgo4tYIKfIH32SOVqy6GLusy8DRIz1QMt97XCA=.d5b9d7e1-1e74-4c05-a474-05abf000d190@github.com>

On Fri, 3 Nov 2023 01:44:42 GMT, Dean Long <dlong at openjdk.org> wrote:

>> # Description
>> 
>> Please review this PR with a patch to re-use the same C2_MacroAssembler object to emit all instructions in the same compilation unit.
>> 
>> Overall, the change is pretty simple. However, due to the renaming of the variable to access C2_MacroAssembler, from `_masm.` to `masm->`, and also some method prototype changes, the patch became quite large.
>> 
>> # Help Needed for Testing
>> 
>> I don't have access to all platforms necessary to test this. I hope some other folks can help with testing on `S390`, `RISC-V` and `PPC`.
>
> src/hotspot/cpu/x86/gc/z/z_x86_64.ad line 37:
> 
>> 35: #include "gc/z/zBarrierSetAssembler.hpp"
>> 36: 
>> 37: static void z_color(MacroAssembler* masm, const MachNode* node, Register ref) {
> 
> For files already using MacroAssembler& _masm, the only change needed is this at the top:
> 
> undef __
> #define __ _masm.

I guess that doesn't work because different files are concatenated together, causing a conflict if some files expect MacroAssembler *masm.  To reduce the number of changes, couldn't we use MacroAssembler& _masm everywhere?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16484#discussion_r1381098489

From fyang at openjdk.org  Fri Nov  3 04:49:01 2023
From: fyang at openjdk.org (Fei Yang)
Date: Fri, 3 Nov 2023 04:49:01 GMT
Subject: RFR: JDK-8241503: C2: Share MacroAssembler between mach nodes
 during code emission
In-Reply-To: <ExCrwPns55nw2P62UI3vzSVTmFCh3dzJq7u3Kugp9EA=.c20cd86c-2c16-4869-ba7f-76f2a53821d0@github.com>
References: <ExCrwPns55nw2P62UI3vzSVTmFCh3dzJq7u3Kugp9EA=.c20cd86c-2c16-4869-ba7f-76f2a53821d0@github.com>
Message-ID: <F4F6PqnrFUaeVy2mZA9h09Gd5X9xjJQfC0HVts-zxcs=.c7e38cd6-285c-49f0-b711-76b7df681e37@github.com>

On Thu, 2 Nov 2023 22:17:43 GMT, Cesar Soares Lucas <cslucas at openjdk.org> wrote:

> # Description
> 
> Please review this PR with a patch to re-use the same C2_MacroAssembler object to emit all instructions in the same compilation unit.
> 
> Overall, the change is pretty simple. However, due to the renaming of the variable to access C2_MacroAssembler, from `_masm.` to `masm->`, and also some method prototype changes, the patch became quite large.
> 
> # Help Needed for Testing
> 
> I don't have access to all platforms necessary to test this. I hope some other folks can help with testing on `S390`, `RISC-V` and `PPC`.

Hello, I guess you might want to merge latest jdk master and add more changes.
I witnessed some build errors when building the latest jdk master with this patch on linux-riscv64:

/home/fyang/jdk/src/hotspot/cpu/riscv/riscv.ad: In member function 'virtual void UdivINode::emit(C2_MacroAssembler*, PhaseRegAlloc*) const':
/home/fyang/jdk/src/hotspot/cpu/riscv/riscv.ad:2412:30: error: 'cbuf' was not declared in this scope
 2412 |     C2_MacroAssembler _masm(&cbuf);
      |                              ^~~~
/home/fyang/jdk/src/hotspot/cpu/riscv/riscv.ad: In member function 'virtual void UdivLNode::emit(C2_MacroAssembler*, PhaseRegAlloc*) const':
/home/fyang/jdk/src/hotspot/cpu/riscv/riscv.ad:2427:30: error: 'cbuf' was not declared in this scope
 2427 |     C2_MacroAssembler _masm(&cbuf);
      |                              ^~~~
/home/fyang/jdk/src/hotspot/cpu/riscv/riscv.ad: In member function 'virtual void UmodINode::emit(C2_MacroAssembler*, PhaseRegAlloc*) const':
/home/fyang/jdk/src/hotspot/cpu/riscv/riscv.ad:2442:30: error: 'cbuf' was not declared in this scope
 2442 |     C2_MacroAssembler _masm(&cbuf);
      |                              ^~~~
/home/fyang/jdk/src/hotspot/cpu/riscv/riscv.ad: In member function 'virtual void UmodLNode::emit(C2_MacroAssembler*, PhaseRegAlloc*) const':
/home/fyang/jdk/src/hotspot/cpu/riscv/riscv.ad:2457:30: error: 'cbuf' was not declared in this scope
 2457 |     C2_MacroAssembler _masm(&cbuf);

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

PR Comment: https://git.openjdk.org/jdk/pull/16484#issuecomment-1791888196

From wkemper at openjdk.org  Fri Nov  3 16:19:22 2023
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 3 Nov 2023 16:19:22 GMT
Subject: RFR: Merge openjdk/jdk:master [v3]
In-Reply-To: <EZt6H-Ey6cRguW0Uigj4WT7JgqcJq0Rew1VTAnSy0QM=.48d20e80-ff9d-43cd-97be-27796afcb8a5@github.com>
References: <EZt6H-Ey6cRguW0Uigj4WT7JgqcJq0Rew1VTAnSy0QM=.48d20e80-ff9d-43cd-97be-27796afcb8a5@github.com>
Message-ID: <BJ_meS-bTtaWcFQtCYMDHdGInx2ls0IrfBNoU-mHgsM=.481b5151-a19b-456a-b3cb-4166fa8a79d9@github.com>

> Merges tag jdk-22+22

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

  Fix merge error

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

Changes:
  - all: https://git.openjdk.org/shenandoah/pull/351/files
  - new: https://git.openjdk.org/shenandoah/pull/351/files/578915b0..177886ac

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

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

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

From cslucas at openjdk.org  Fri Nov  3 16:27:06 2023
From: cslucas at openjdk.org (Cesar Soares Lucas)
Date: Fri, 3 Nov 2023 16:27:06 GMT
Subject: RFR: JDK-8241503: C2: Share MacroAssembler between mach nodes
 during code emission
In-Reply-To: <F4F6PqnrFUaeVy2mZA9h09Gd5X9xjJQfC0HVts-zxcs=.c7e38cd6-285c-49f0-b711-76b7df681e37@github.com>
References: <ExCrwPns55nw2P62UI3vzSVTmFCh3dzJq7u3Kugp9EA=.c20cd86c-2c16-4869-ba7f-76f2a53821d0@github.com>
 <F4F6PqnrFUaeVy2mZA9h09Gd5X9xjJQfC0HVts-zxcs=.c7e38cd6-285c-49f0-b711-76b7df681e37@github.com>
Message-ID: <_Qvj6Msy_P6hIWUc4IwGPLKXLK7391GMCEI4XlNYQrY=.1e03e561-071f-48ae-b322-d944c7b1ff36@github.com>

On Fri, 3 Nov 2023 04:44:40 GMT, Fei Yang <fyang at openjdk.org> wrote:

>> # Description
>> 
>> Please review this PR with a patch to re-use the same C2_MacroAssembler object to emit all instructions in the same compilation unit.
>> 
>> Overall, the change is pretty simple. However, due to the renaming of the variable to access C2_MacroAssembler, from `_masm.` to `masm->`, and also some method prototype changes, the patch became quite large.
>> 
>> # Help Needed for Testing
>> 
>> I don't have access to all platforms necessary to test this. I hope some other folks can help with testing on `S390`, `RISC-V` and `PPC`.
>
> Hello, I guess you might want to merge latest jdk master and add more changes.
> I witnessed some build errors when building the latest jdk master with this patch on linux-riscv64:
> 
> /home/fyang/jdk/src/hotspot/cpu/riscv/riscv.ad: In member function 'virtual void UdivINode::emit(C2_MacroAssembler*, PhaseRegAlloc*) const':
> /home/fyang/jdk/src/hotspot/cpu/riscv/riscv.ad:2412:30: error: 'cbuf' was not declared in this scope
>  2412 |     C2_MacroAssembler _masm(&cbuf);
>       |                              ^~~~
> /home/fyang/jdk/src/hotspot/cpu/riscv/riscv.ad: In member function 'virtual void UdivLNode::emit(C2_MacroAssembler*, PhaseRegAlloc*) const':
> /home/fyang/jdk/src/hotspot/cpu/riscv/riscv.ad:2427:30: error: 'cbuf' was not declared in this scope
>  2427 |     C2_MacroAssembler _masm(&cbuf);
>       |                              ^~~~
> /home/fyang/jdk/src/hotspot/cpu/riscv/riscv.ad: In member function 'virtual void UmodINode::emit(C2_MacroAssembler*, PhaseRegAlloc*) const':
> /home/fyang/jdk/src/hotspot/cpu/riscv/riscv.ad:2442:30: error: 'cbuf' was not declared in this scope
>  2442 |     C2_MacroAssembler _masm(&cbuf);
>       |                              ^~~~
> /home/fyang/jdk/src/hotspot/cpu/riscv/riscv.ad: In member function 'virtual void UmodLNode::emit(C2_MacroAssembler*, PhaseRegAlloc*) const':
> /home/fyang/jdk/src/hotspot/cpu/riscv/riscv.ad:2457:30: error: 'cbuf' was not declared in this scope
>  2457 |     C2_MacroAssembler _masm(&cbuf);

@RealFYang - Thanks for the note. I'll do that and update the PR.

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

PR Comment: https://git.openjdk.org/jdk/pull/16484#issuecomment-1792746837

From wkemper at openjdk.org  Fri Nov  3 19:34:06 2023
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 3 Nov 2023 19:34:06 GMT
Subject: RFR: Merge openjdk/jdk:master [v4]
In-Reply-To: <EZt6H-Ey6cRguW0Uigj4WT7JgqcJq0Rew1VTAnSy0QM=.48d20e80-ff9d-43cd-97be-27796afcb8a5@github.com>
References: <EZt6H-Ey6cRguW0Uigj4WT7JgqcJq0Rew1VTAnSy0QM=.48d20e80-ff9d-43cd-97be-27796afcb8a5@github.com>
Message-ID: <2RWdMoUPRGXsUmRqzsR7WxFvlcozVfTVXtyzJrK0E5g=.82b77ffc-7501-47aa-8a74-62b7ae68cbe3@github.com>

> Merges tag jdk-22+22

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

  Fix merge errors, harder

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

Changes:
  - all: https://git.openjdk.org/shenandoah/pull/351/files
  - new: https://git.openjdk.org/shenandoah/pull/351/files/177886ac..8a52f169

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

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

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

From kdnilsen at openjdk.org  Fri Nov  3 21:25:49 2023
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Fri, 3 Nov 2023 21:25:49 GMT
Subject: RFR: 8319342: GenShen: Reset the count of degenerated cycles in a row
 following Full GC
Message-ID: <rCs8Wg84Qlm7U040SDODaHg1RYJTj-m8yBFacF2xmsM=.f2e385ca-d02b-42b5-8f5a-2d79e83976c2@github.com>

After a Full GC completes, reset the count on consecutive degenerated cycles to zero.  This prevents automatic triggering of back-to-back Full GC.

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

Commit messages:
 - Do not increment degen count if degen upgrades to full
 - Count degen cycles in a row within ShenandoahCollectorPolicy

Changes: https://git.openjdk.org/shenandoah/pull/352/files
 Webrev: https://webrevs.openjdk.org/?repo=shenandoah&pr=352&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8319342
  Stats: 53 lines in 9 files changed: 16 ins; 32 del; 5 mod
  Patch: https://git.openjdk.org/shenandoah/pull/352.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah.git pull/352/head:pull/352

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

From kbarrett at openjdk.org  Sat Nov  4 11:31:20 2023
From: kbarrett at openjdk.org (Kim Barrett)
Date: Sat, 4 Nov 2023 11:31:20 GMT
Subject: RFR: 8319439: Move BufferNode from PtrQueue files to new files
Message-ID: <zgfte_VjFQ56hJ2KGXvXtAhrjBaPvhPZ4t59eh-UN8U=.4beba8d0-dbe8-4582-93cb-b4a60b898bcf@github.com>

Please review this simple (trivial?) change that moves the BufferNode class
from share/gc/shared/ptrQueue.[ch]pp to new files
share/gc/shared/bufferNode.[ch]pp.  The code (as opposed to the surrounding
boiler plate and #include's) was moved unchanged.

This led to adding #include's of the new header file to a bunch of other files
(include what you use), in some cases eliminating the need to #include
ptrQueue.hpp.  Also tidied up the #include's for ptrQueue.[ch]pp to take
advantage of the split.

Also, the gtest gc/shared/test_ptrQueueBufferAllocator.cpp is renamed to  
gc/shared/test_bufferNodeAllocator.cpp, with some adjustments to includes and
test naming.

Testing:
mach5 tier1

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

Commit messages:
 - fixup gtest after rename
 - move test
 - move BufferNode to new files

Changes: https://git.openjdk.org/jdk/pull/16506/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16506&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8319439
  Stats: 383 lines in 17 files changed: 223 ins; 152 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/16506.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16506/head:pull/16506

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

From rkennke at openjdk.org  Mon Nov  6 12:38:46 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Mon, 6 Nov 2023 12:38:46 GMT
Subject: RFR: 8318462: [GenShen] Prevent unsafe access to displaced
 mark-word [v6]
In-Reply-To: <uOeuEpzRFvBx1AFgOvvTNfxJIyI4o84yT9D5A_q6BjU=.92103c05-893a-4b0b-a165-54289729f74f@github.com>
References: <uOeuEpzRFvBx1AFgOvvTNfxJIyI4o84yT9D5A_q6BjU=.92103c05-893a-4b0b-a165-54289729f74f@github.com>
Message-ID: <LeCiTuYemKhB_xHW8xfNFYnAqv019CX4kZIq2CtG7Gs=.b37843c8-cae6-4e66-9871-18bd9a0165a6@github.com>

> We must be very careful when we access (load or update) the object age concurrently because the age is stored in the object's header and that header can be 'displaced'. This means that the header is overloaded with a pointer (stack or ObjectMonitor*) and the original header is stored at that location. The header can also be in INFLATING state, which means that a stack-lock is currently in the process to be inflated to an ObjectMonitor. Let's consider the cases separately:
> 
> Loading object age:
> - INFLATING: we can not access the header, and thus not the age.
> - Stack-locked: the thread which locks the object can unlock at any time, concurrently. It is not safe to access the header, and thus the age.
> - Monitor-locked: monitors don't go away without coordinating with Java threads and possibly GC threads. This coordination is done by handshaking the thread - a Java thread would be brought to its next safepoint, and GC threads, which are typically participating in handshakes by joining the SuspendibleThreadSet, can opt to handshake at a safe point by calling SuspendibleThreadSet::yield(). If 'our' thread participates in handshakes in one way or the other, it is safe to access an ObjectMonitor once we got a valid ObjectMonitor* from an object's header, but only until that thread handshakes. Long story short: it is typically safe to access ObjectMonitor :-)
> 
> Updating object age:
> Updating object age only happens during evacuation, and only on a new copy of an object, before that copy has been published. Access to the object header is therefore fully thread-local and not problematic. What *is* problematic is when we have to deal with displaced headers, because displaced headers are *not* thread local, and must be considered a shared resource. A competing thread may succeed to evacuate the object and publish its copy before 'our' thread can do so. If 'our' thread would update the displaced header, it may over-write whatever the other thread has done.
> - INFLATING: We cannot access the header at all. However, that should not happen: a thread can only inflate once it has successfully evacuated an object, and 
> - Stack-locked: the other thread may succeed evacuation and continue to unlock the object, at which point the stack-pointer would be 'dangling' and we may over-write random information on the foreign thread stack.
> - Monitor-locked: even though monitor deflation is coordinated (see above), updating the displaced header in a monitor might over-write whatever a competi...

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

  Fix handling of age sentinel

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

Changes:
  - all: https://git.openjdk.org/shenandoah/pull/343/files
  - new: https://git.openjdk.org/shenandoah/pull/343/files/969e4650..3c982491

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

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

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

From cslucas at openjdk.org  Mon Nov  6 22:22:30 2023
From: cslucas at openjdk.org (Cesar Soares Lucas)
Date: Mon, 6 Nov 2023 22:22:30 GMT
Subject: RFR: JDK-8241503: C2: Share MacroAssembler between mach nodes
 during code emission
In-Reply-To: <CzmCsBgo4tYIKfIH32SOVqy6GLusy8DRIz1QMt97XCA=.d5b9d7e1-1e74-4c05-a474-05abf000d190@github.com>
References: <ExCrwPns55nw2P62UI3vzSVTmFCh3dzJq7u3Kugp9EA=.c20cd86c-2c16-4869-ba7f-76f2a53821d0@github.com>
 <UGrpyynLCpoOo2S1FPh_i4G44QflcSFCFr42qvQrBVI=.d6495455-c652-4447-be5c-c1c7df457a72@github.com>
 <CzmCsBgo4tYIKfIH32SOVqy6GLusy8DRIz1QMt97XCA=.d5b9d7e1-1e74-4c05-a474-05abf000d190@github.com>
Message-ID: <_1LI3cbeE9XR-7E7gD22M7xNueLRhlAtHWopiTccb1Y=.a26dde00-d6b8-4c98-a84d-143d65ef251c@github.com>

On Fri, 3 Nov 2023 02:04:13 GMT, Dean Long <dlong at openjdk.org> wrote:

>> src/hotspot/cpu/x86/gc/z/z_x86_64.ad line 37:
>> 
>>> 35: #include "gc/z/zBarrierSetAssembler.hpp"
>>> 36: 
>>> 37: static void z_color(MacroAssembler* masm, const MachNode* node, Register ref) {
>> 
>> For files already using MacroAssembler& _masm, the only change needed is this at the top:
>> 
>> undef __
>> #define __ _masm.
>
> I guess that doesn't work because different files are concatenated together, causing a conflict if some files expect MacroAssembler *masm.  To reduce the number of changes, couldn't we use MacroAssembler& _masm everywhere?

Because some places were using `if (cbuf)` I ended up opting to make the parameter also a pointer instead of a reference.

> For files already using MacroAssembler& _masm, the only change needed is this at the top:

My opinion would be to use Reference or Pointer everywhere and not mix the two - to prevent confusion. But if you folks think it's best to go that way, I'm fine with it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16484#discussion_r1384095916

From wkemper at openjdk.org  Mon Nov  6 23:11:51 2023
From: wkemper at openjdk.org (William Kemper)
Date: Mon, 6 Nov 2023 23:11:51 GMT
Subject: RFR: 8319342: GenShen: Reset the count of degenerated cycles in a
 row following Full GC
In-Reply-To: <rCs8Wg84Qlm7U040SDODaHg1RYJTj-m8yBFacF2xmsM=.f2e385ca-d02b-42b5-8f5a-2d79e83976c2@github.com>
References: <rCs8Wg84Qlm7U040SDODaHg1RYJTj-m8yBFacF2xmsM=.f2e385ca-d02b-42b5-8f5a-2d79e83976c2@github.com>
Message-ID: <KMD_OFSQeGgchZ6AnoKCyjPL7CjsYQqBpHE6UAUMHtc=.916e32b5-886c-4f13-a0e2-15a54f017f60@github.com>

On Fri, 3 Nov 2023 21:17:42 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

> After a Full GC completes, reset the count on consecutive degenerated cycles to zero.  This prevents automatic triggering of back-to-back Full GC.

Changes requested by wkemper (Committer).

src/hotspot/share/gc/shenandoah/heuristics/shenandoahPassiveHeuristics.cpp line 49:

> 47: bool ShenandoahPassiveHeuristics::should_degenerate_cycle() {
> 48:   // Always fail to Degenerated GC, if enabled
> 49:   return ShenandoahDegeneratedGC;

Are we changing how the passive heuristic behaves now? With this change `ShenandoahCollectorPolicy::should_degenerate_cycle` would return `false` sometimes when the passive heuristic would have "degenerated".

src/hotspot/share/gc/shenandoah/shenandoahCollectorPolicy.hpp line 64:

> 62:   ShenandoahTracer* _tracer;
> 63: 
> 64:   uint _degenerated_cycles_in_a_row;

Nit, but we could call this `_consecutive_degenerated_gcs` for consistency with other fields in this class? (Also, possibly rename `_abbreviated_cycles` to `_abbreviated_gcs` for the same reason.

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

PR Review: https://git.openjdk.org/shenandoah/pull/352#pullrequestreview-1716475112
PR Review Comment: https://git.openjdk.org/shenandoah/pull/352#discussion_r1384151138
PR Review Comment: https://git.openjdk.org/shenandoah/pull/352#discussion_r1384144872

From ysr at openjdk.org  Tue Nov  7 00:29:25 2023
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Tue, 7 Nov 2023 00:29:25 GMT
Subject: RFR: 8319342: GenShen: Reset the count of degenerated cycles in a
 row following Full GC
In-Reply-To: <KMD_OFSQeGgchZ6AnoKCyjPL7CjsYQqBpHE6UAUMHtc=.916e32b5-886c-4f13-a0e2-15a54f017f60@github.com>
References: <rCs8Wg84Qlm7U040SDODaHg1RYJTj-m8yBFacF2xmsM=.f2e385ca-d02b-42b5-8f5a-2d79e83976c2@github.com>
 <KMD_OFSQeGgchZ6AnoKCyjPL7CjsYQqBpHE6UAUMHtc=.916e32b5-886c-4f13-a0e2-15a54f017f60@github.com>
Message-ID: <7V6Xb-M5kmJPyGNmcewQ0wrI8P1JrzSKnaWG63DXJmM=.cfbf51b4-dd3d-412a-b8fe-f9c39688a64e@github.com>

On Mon, 6 Nov 2023 22:59:31 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> After a Full GC completes, reset the count on consecutive degenerated cycles to zero.  This prevents automatic triggering of back-to-back Full GC.
>
> src/hotspot/share/gc/shenandoah/heuristics/shenandoahPassiveHeuristics.cpp line 49:
> 
>> 47: bool ShenandoahPassiveHeuristics::should_degenerate_cycle() {
>> 48:   // Always fail to Degenerated GC, if enabled
>> 49:   return ShenandoahDegeneratedGC;
> 
> Are we changing how the passive heuristic behaves now? With this change `ShenandoahCollectorPolicy::should_degenerate_cycle` would return `false` sometimes when the passive heuristic would have "degenerated".

I agee with William... You can leave all state (counters) and its manipulation entirely in the heuristics object, and let the policy object query the heuristics like you do today, and inform it when it does do a full gc, etc. so relevant state may be updated.

Of course, the policy should not independently reach in and change the state maintained in the heuristics, just query that state, and inform it of events that might entail changes to that state.

We can clean things up by asking what the role of heuristics is vs what the role of policy is. It seems as if policy is broad and heuristics is more specific within that broad policy. It is also possible to keep the state in the policy, be mutated only by policy in response to events, and have the heuristics be completely state-free, but call-back to policy to use any state it would use for its decisions. Clarifying this structure and their relationship, and sticking to a consistent (documented) protocol here would avoid confusion and errors.

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

PR Review Comment: https://git.openjdk.org/shenandoah/pull/352#discussion_r1384200774

From wkemper at openjdk.org  Tue Nov  7 01:03:37 2023
From: wkemper at openjdk.org (William Kemper)
Date: Tue, 7 Nov 2023 01:03:37 GMT
Subject: RFR: Merge openjdk/jdk:master [v5]
In-Reply-To: <EZt6H-Ey6cRguW0Uigj4WT7JgqcJq0Rew1VTAnSy0QM=.48d20e80-ff9d-43cd-97be-27796afcb8a5@github.com>
References: <EZt6H-Ey6cRguW0Uigj4WT7JgqcJq0Rew1VTAnSy0QM=.48d20e80-ff9d-43cd-97be-27796afcb8a5@github.com>
Message-ID: <eYQVeAWCMita3NiBAHtmnK2dnZTy5jXW6fD8M9llbew=.f31e72c9-e8ea-4bd0-aacc-242bb81ca4ad@github.com>

> Merges tag jdk-22+22

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

  Increase no progress threshold for generation mode

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

Changes:
  - all: https://git.openjdk.org/shenandoah/pull/351/files
  - new: https://git.openjdk.org/shenandoah/pull/351/files/8a52f169..14d3f617

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

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

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

From tschatzl at openjdk.org  Tue Nov  7 11:21:27 2023
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Tue, 7 Nov 2023 11:21:27 GMT
Subject: RFR: 8319439: Move BufferNode from PtrQueue files to new files
In-Reply-To: <zgfte_VjFQ56hJ2KGXvXtAhrjBaPvhPZ4t59eh-UN8U=.4beba8d0-dbe8-4582-93cb-b4a60b898bcf@github.com>
References: <zgfte_VjFQ56hJ2KGXvXtAhrjBaPvhPZ4t59eh-UN8U=.4beba8d0-dbe8-4582-93cb-b4a60b898bcf@github.com>
Message-ID: <geFOSqiqFQaNgL5ojPLRWMy3gyETSybCpKeHdoOrO8k=.5fe9c8d9-fafe-4f74-b938-524b50d73507@github.com>

On Sat, 4 Nov 2023 11:25:05 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this simple (trivial?) change that moves the BufferNode class
> from share/gc/shared/ptrQueue.[ch]pp to new files
> share/gc/shared/bufferNode.[ch]pp.  The code (as opposed to the surrounding
> boiler plate and #include's) was moved unchanged.
> 
> This led to adding #include's of the new header file to a bunch of other files
> (include what you use), in some cases eliminating the need to #include
> ptrQueue.hpp.  Also tidied up the #include's for ptrQueue.[ch]pp to take
> advantage of the split.
> 
> Also, the gtest gc/shared/test_ptrQueueBufferAllocator.cpp is renamed to  
> gc/shared/test_bufferNodeAllocator.cpp, with some adjustments to includes and
> test naming.
> 
> Testing:
> mach5 tier1

lgtm

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

Marked as reviewed by tschatzl (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16506#pullrequestreview-1717445517

From ysr at openjdk.org  Tue Nov  7 19:10:33 2023
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Tue, 7 Nov 2023 19:10:33 GMT
Subject: RFR: Merge openjdk/jdk:master [v5]
In-Reply-To: <eYQVeAWCMita3NiBAHtmnK2dnZTy5jXW6fD8M9llbew=.f31e72c9-e8ea-4bd0-aacc-242bb81ca4ad@github.com>
References: <EZt6H-Ey6cRguW0Uigj4WT7JgqcJq0Rew1VTAnSy0QM=.48d20e80-ff9d-43cd-97be-27796afcb8a5@github.com>
 <eYQVeAWCMita3NiBAHtmnK2dnZTy5jXW6fD8M9llbew=.f31e72c9-e8ea-4bd0-aacc-242bb81ca4ad@github.com>
Message-ID: <IoCv7OkD2BwAMbSAMrsRPqudn0GdpkF5a8iH8hNmuaA=.e4f49e4e-4ab1-4d8c-9c82-d22b1c63e416@github.com>

On Tue, 7 Nov 2023 01:03:37 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> Merges tag jdk-22+22
>
> William Kemper has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Increase no progress threshold for generation mode

Marked as reviewed by ysr (Committer).

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

PR Review: https://git.openjdk.org/shenandoah/pull/351#pullrequestreview-1718498719

From kdnilsen at openjdk.org  Tue Nov  7 21:22:41 2023
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Tue, 7 Nov 2023 21:22:41 GMT
Subject: RFR: 8319342: GenShen: Reset the count of degenerated cycles in a
 row following Full GC
In-Reply-To: <KMD_OFSQeGgchZ6AnoKCyjPL7CjsYQqBpHE6UAUMHtc=.916e32b5-886c-4f13-a0e2-15a54f017f60@github.com>
References: <rCs8Wg84Qlm7U040SDODaHg1RYJTj-m8yBFacF2xmsM=.f2e385ca-d02b-42b5-8f5a-2d79e83976c2@github.com>
 <KMD_OFSQeGgchZ6AnoKCyjPL7CjsYQqBpHE6UAUMHtc=.916e32b5-886c-4f13-a0e2-15a54f017f60@github.com>
Message-ID: <UpYwwAPWlH6dPAEECXSZvr5BB0GQSjvqycdMaH9KPZM=.8fade8d1-2902-4144-b474-7cb2654bf1ce@github.com>

On Mon, 6 Nov 2023 22:49:57 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> After a Full GC completes, reset the count on consecutive degenerated cycles to zero.  This prevents automatic triggering of back-to-back Full GC.
>
> src/hotspot/share/gc/shenandoah/shenandoahCollectorPolicy.hpp line 64:
> 
>> 62:   ShenandoahTracer* _tracer;
>> 63: 
>> 64:   uint _degenerated_cycles_in_a_row;
> 
> Nit, but we could call this `_consecutive_degenerated_gcs` for consistency with other fields in this class? (Also, possibly rename `_abbreviated_cycles` to `_abbreviated_gcs` for the same reason.

Thanks.  Making this change.

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

PR Review Comment: https://git.openjdk.org/shenandoah/pull/352#discussion_r1385601350

From kdnilsen at openjdk.org  Tue Nov  7 21:42:27 2023
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Tue, 7 Nov 2023 21:42:27 GMT
Subject: RFR: 8319342: GenShen: Reset the count of degenerated cycles in a
 row following Full GC
In-Reply-To: <7V6Xb-M5kmJPyGNmcewQ0wrI8P1JrzSKnaWG63DXJmM=.cfbf51b4-dd3d-412a-b8fe-f9c39688a64e@github.com>
References: <rCs8Wg84Qlm7U040SDODaHg1RYJTj-m8yBFacF2xmsM=.f2e385ca-d02b-42b5-8f5a-2d79e83976c2@github.com>
 <KMD_OFSQeGgchZ6AnoKCyjPL7CjsYQqBpHE6UAUMHtc=.916e32b5-886c-4f13-a0e2-15a54f017f60@github.com>
 <7V6Xb-M5kmJPyGNmcewQ0wrI8P1JrzSKnaWG63DXJmM=.cfbf51b4-dd3d-412a-b8fe-f9c39688a64e@github.com>
Message-ID: <jyPf9nclPpHEdpa-1ea9CoumFuO84cMms1RXD8nhLmk=.f702d070-7f40-40bd-87f7-62baec5fc517@github.com>

On Tue, 7 Nov 2023 00:26:39 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

>> src/hotspot/share/gc/shenandoah/heuristics/shenandoahPassiveHeuristics.cpp line 49:
>> 
>>> 47: bool ShenandoahPassiveHeuristics::should_degenerate_cycle() {
>>> 48:   // Always fail to Degenerated GC, if enabled
>>> 49:   return ShenandoahDegeneratedGC;
>> 
>> Are we changing how the passive heuristic behaves now? With this change `ShenandoahCollectorPolicy::should_degenerate_cycle` would return `false` sometimes when the passive heuristic would have "degenerated".
>
> I agee with William... You can leave all state (counters) and its manipulation entirely in the heuristics object, and let the policy object query the heuristics like you do today, and inform it when it does do a full gc, etc. so relevant state may be updated.
> 
> Of course, the policy should not independently reach in and change the state maintained in the heuristics, just query that state, and inform it of events that might entail changes to that state.
> 
> We can clean things up by asking what the role of heuristics is vs what the role of policy is. It seems as if policy is broad and heuristics is more specific within that broad policy. It is also possible to keep the state in the policy, be mutated only by policy in response to events, and have the heuristics be completely state-free, but call-back to policy to use any state it would use for its decisions. Clarifying this structure and their relationship, and sticking to a consistent (documented) protocol here would avoid confusion and errors.

Good catch.  That was an unintended consequence.  I will return the methods to the Heuristics hierarchy, but will query the consecutive_degenerated_gcs value from collector policy.

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

PR Review Comment: https://git.openjdk.org/shenandoah/pull/352#discussion_r1385618089

From kdnilsen at openjdk.org  Tue Nov  7 21:58:07 2023
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Tue, 7 Nov 2023 21:58:07 GMT
Subject: RFR: 8319342: GenShen: Reset the count of degenerated cycles in a
 row following Full GC [v2]
In-Reply-To: <rCs8Wg84Qlm7U040SDODaHg1RYJTj-m8yBFacF2xmsM=.f2e385ca-d02b-42b5-8f5a-2d79e83976c2@github.com>
References: <rCs8Wg84Qlm7U040SDODaHg1RYJTj-m8yBFacF2xmsM=.f2e385ca-d02b-42b5-8f5a-2d79e83976c2@github.com>
Message-ID: <0yq9fTGZoWjjhbleGS8GRDOZ3kAIp92nZRet9gX7plM=.7247cee6-db8c-4355-8a11-257af3d06b35@github.com>

> After a Full GC completes, reset the count on consecutive degenerated cycles to zero.  This prevents automatic triggering of back-to-back Full GC.

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

  Respond to reviewer feedback
  
  Restore the original ShenandoahHeuristics::should_degenerate_cycle() so
  that ShenandoahPassiveHeuristics can differentate from other
  implementations.
  
  Improve instance variable names.

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

Changes:
  - all: https://git.openjdk.org/shenandoah/pull/352/files
  - new: https://git.openjdk.org/shenandoah/pull/352/files/3b3a1672..8bd0b992

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

  Stats: 39 lines in 7 files changed: 19 ins; 10 del; 10 mod
  Patch: https://git.openjdk.org/shenandoah/pull/352.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah.git pull/352/head:pull/352

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

From kdnilsen at openjdk.org  Tue Nov  7 22:02:51 2023
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Tue, 7 Nov 2023 22:02:51 GMT
Subject: RFR: 8319342: GenShen: Reset the count of degenerated cycles in a
 row following Full GC [v3]
In-Reply-To: <rCs8Wg84Qlm7U040SDODaHg1RYJTj-m8yBFacF2xmsM=.f2e385ca-d02b-42b5-8f5a-2d79e83976c2@github.com>
References: <rCs8Wg84Qlm7U040SDODaHg1RYJTj-m8yBFacF2xmsM=.f2e385ca-d02b-42b5-8f5a-2d79e83976c2@github.com>
Message-ID: <SDgKwSOyNjwyBe1okGVAw-HmRUPnhl4BFCukJzRf2dU=.f743b040-5694-4bc7-b561-0de3bc395b18@github.com>

> After a Full GC completes, reset the count on consecutive degenerated cycles to zero.  This prevents automatic triggering of back-to-back Full GC.

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

  Fix typo

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

Changes:
  - all: https://git.openjdk.org/shenandoah/pull/352/files
  - new: https://git.openjdk.org/shenandoah/pull/352/files/8bd0b992..b18f7041

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

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

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

From wkemper at openjdk.org  Tue Nov  7 22:24:53 2023
From: wkemper at openjdk.org (William Kemper)
Date: Tue, 7 Nov 2023 22:24:53 GMT
Subject: Integrated: Merge openjdk/jdk:master
In-Reply-To: <EZt6H-Ey6cRguW0Uigj4WT7JgqcJq0Rew1VTAnSy0QM=.48d20e80-ff9d-43cd-97be-27796afcb8a5@github.com>
References: <EZt6H-Ey6cRguW0Uigj4WT7JgqcJq0Rew1VTAnSy0QM=.48d20e80-ff9d-43cd-97be-27796afcb8a5@github.com>
Message-ID: <ATR7t802Tue3IXlOzmu9jE1WjIBiTyiEtzBp8S84NXs=.8ac622e9-05e6-4f0a-8028-68f5258f7ab5@github.com>

On Thu, 2 Nov 2023 14:10:06 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Merges tag jdk-22+22

This pull request has now been integrated.

Changeset: 20172ba8
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.org/shenandoah/commit/20172ba83a5d0348dba93bfbfce5bfd84d088258
Stats:     27457 lines in 1169 files changed: 14955 ins; 4156 del; 8346 mod

Merge

Reviewed-by: ysr

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

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

From wkemper at openjdk.org  Wed Nov  8 01:10:45 2023
From: wkemper at openjdk.org (William Kemper)
Date: Wed, 8 Nov 2023 01:10:45 GMT
Subject: RFR: 8319671 GenShen: Old marking may encounter invalid pointers in
 SATB buffers
Message-ID: <W0dibwDlhcO9ISwjnLpQYKgMMRy1pfQHTYtXBCwep1I=.7b185312-f96c-4970-827a-f1ab9a56dae9@github.com>

Weak handles which are null'd out after final marking of young, but during marking of old, will have their original referent placed into a SATB buffer. These entries need to be purged before old marking resumes. In the case of abbreviated young cycles, these entries would not be purged.

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

Commit messages:
 - Purge SATB buffers if necessary at the end of an abbreviated cycle

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

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

From amitkumar at openjdk.org  Wed Nov  8 04:36:53 2023
From: amitkumar at openjdk.org (Amit Kumar)
Date: Wed, 8 Nov 2023 04:36:53 GMT
Subject: RFR: JDK-8241503: C2: Share MacroAssembler between mach nodes
 during code emission
In-Reply-To: <ExCrwPns55nw2P62UI3vzSVTmFCh3dzJq7u3Kugp9EA=.c20cd86c-2c16-4869-ba7f-76f2a53821d0@github.com>
References: <ExCrwPns55nw2P62UI3vzSVTmFCh3dzJq7u3Kugp9EA=.c20cd86c-2c16-4869-ba7f-76f2a53821d0@github.com>
Message-ID: <yMm8dccKyhmu3glz-hLgP8V81EYvwFASjEUItwKGlHI=.692202d3-87e0-4c0e-9daf-1b4df9af36b9@github.com>

On Thu, 2 Nov 2023 22:17:43 GMT, Cesar Soares Lucas <cslucas at openjdk.org> wrote:

> # Description
> 
> Please review this PR with a patch to re-use the same C2_MacroAssembler object to emit all instructions in the same compilation unit.
> 
> Overall, the change is pretty simple. However, due to the renaming of the variable to access C2_MacroAssembler, from `_masm.` to `masm->`, and also some method prototype changes, the patch became quite large.
> 
> # Help Needed for Testing
> 
> I don't have access to all platforms necessary to test this. I hope some other folks can help with testing on `S390`, `RISC-V` and `PPC`.

`s390x` also run into assert failure: `assert(masm->inst_mark() == nullptr) failed: should be.`


V  [libjvm.so+0xfb0938]  PhaseOutput::fill_buffer(C2_MacroAssembler*, unsigned int*)+0x2370  (output.cpp:1812)
V  [libjvm.so+0xfb21ce]  PhaseOutput::Output()+0xcae  (output.cpp:362)
V  [libjvm.so+0x6a90a8]  Compile::Code_Gen()+0x460  (compile.cpp:2989)
V  [libjvm.so+0x6ad848]  Compile::Compile(ciEnv*, ciMethod*, int, Options, DirectiveSet*)+0x1738  (compile.cpp:887)
V  [libjvm.so+0x4fb932]  C2Compiler::compile_method(ciEnv*, ciMethod*, int, bool, DirectiveSet*)+0x14a  (c2compiler.cpp:119)
V  [libjvm.so+0x6b81a2]  CompileBroker::invoke_compiler_on_method(CompileTask*)+0xd9a  (compileBroker.cpp:2282)
V  [libjvm.so+0x6b8eaa]  CompileBroker::compiler_thread_loop()+0x5a2  (compileBroker.cpp:1943)

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

PR Comment: https://git.openjdk.org/jdk/pull/16484#issuecomment-1801070622

From ysr at openjdk.org  Wed Nov  8 05:40:43 2023
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Wed, 8 Nov 2023 05:40:43 GMT
Subject: RFR: 8319671 GenShen: Old marking may encounter invalid pointers
 in SATB buffers
In-Reply-To: <W0dibwDlhcO9ISwjnLpQYKgMMRy1pfQHTYtXBCwep1I=.7b185312-f96c-4970-827a-f1ab9a56dae9@github.com>
References: <W0dibwDlhcO9ISwjnLpQYKgMMRy1pfQHTYtXBCwep1I=.7b185312-f96c-4970-827a-f1ab9a56dae9@github.com>
Message-ID: <BaKWcHYCSyjxUpE8NZaJ1EHMZcEzvAZ6tU1XolNWc6Y=.8e4f8587-48d3-4519-b943-d5d54373318c@github.com>

On Wed, 8 Nov 2023 01:05:24 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Weak handles which are null'd out after final marking of young, but during marking of old, will have their original referent placed into a SATB buffer. These entries need to be purged before old marking resumes. In the case of abbreviated young cycles, these entries would not be purged.

This seems safe, but we should separately explore as a follow-up a more discriminatory SATB barrier for old vs young marking so a to avoid these wrinkles and the extra work.

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

Marked as reviewed by ysr (Committer).

PR Review: https://git.openjdk.org/shenandoah/pull/353#pullrequestreview-1719406785

From ysr at openjdk.org  Wed Nov  8 09:19:40 2023
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Wed, 8 Nov 2023 09:19:40 GMT
Subject: RFR: 8318462: [GenShen] Prevent unsafe access to displaced
 mark-word [v6]
In-Reply-To: <LeCiTuYemKhB_xHW8xfNFYnAqv019CX4kZIq2CtG7Gs=.b37843c8-cae6-4e66-9871-18bd9a0165a6@github.com>
References: <uOeuEpzRFvBx1AFgOvvTNfxJIyI4o84yT9D5A_q6BjU=.92103c05-893a-4b0b-a165-54289729f74f@github.com>
 <LeCiTuYemKhB_xHW8xfNFYnAqv019CX4kZIq2CtG7Gs=.b37843c8-cae6-4e66-9871-18bd9a0165a6@github.com>
Message-ID: <nioYbeMz-odSr1Qlyh_Bn3v2LMMITBJzFeAdBx2R2yE=.69c91eb1-b366-459c-9515-127cb2c99a48@github.com>

On Mon, 6 Nov 2023 12:38:46 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> We must be very careful when we access (load or update) the object age concurrently because the age is stored in the object's header and that header can be 'displaced'. This means that the header is overloaded with a pointer (stack or ObjectMonitor*) and the original header is stored at that location. The header can also be in INFLATING state, which means that a stack-lock is currently in the process to be inflated to an ObjectMonitor. Let's consider the cases separately:
>> 
>> Loading object age:
>> - INFLATING: we can not access the header, and thus not the age.
>> - Stack-locked: the thread which locks the object can unlock at any time, concurrently. It is not safe to access the header, and thus the age.
>> - Monitor-locked: monitors don't go away without coordinating with Java threads and possibly GC threads. This coordination is done by handshaking the thread - a Java thread would be brought to its next safepoint, and GC threads, which are typically participating in handshakes by joining the SuspendibleThreadSet, can opt to handshake at a safe point by calling SuspendibleThreadSet::yield(). If 'our' thread participates in handshakes in one way or the other, it is safe to access an ObjectMonitor once we got a valid ObjectMonitor* from an object's header, but only until that thread handshakes. Long story short: it is typically safe to access ObjectMonitor :-)
>> 
>> Updating object age:
>> Updating object age only happens during evacuation, and only on a new copy of an object, before that copy has been published. Access to the object header is therefore fully thread-local and not problematic. What *is* problematic is when we have to deal with displaced headers, because displaced headers are *not* thread local, and must be considered a shared resource. A competing thread may succeed to evacuate the object and publish its copy before 'our' thread can do so. If 'our' thread would update the displaced header, it may over-write whatever the other thread has done.
>> - INFLATING: We cannot access the header at all. However, that should not happen: a thread can only inflate once it has successfully evacuated an object, and 
>> - Stack-locked: the other thread may succeed evacuation and continue to unlock the object, at which point the stack-pointer would be 'dangling' and we may over-write random information on the foreign thread stack.
>> - Monitor-locked: even though monitor deflation is coordinated (see above), updating the displaced header in a monitor might over-...
>
> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix handling of age sentinel

Nice; thanks also for the documentation!

?

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

Marked as reviewed by ysr (Committer).

PR Review: https://git.openjdk.org/shenandoah/pull/343#pullrequestreview-1719766973

From cslucas at openjdk.org  Wed Nov  8 16:51:00 2023
From: cslucas at openjdk.org (Cesar Soares Lucas)
Date: Wed, 8 Nov 2023 16:51:00 GMT
Subject: RFR: JDK-8241503: C2: Share MacroAssembler between mach nodes
 during code emission
In-Reply-To: <BJtlt-cQZXjDRa0F5QbiqHe_3y-Ih58tlRScZy1H-Ps=.86398c74-3a29-4b8b-b7c6-9e7b6a75cdf9@github.com>
References: <ExCrwPns55nw2P62UI3vzSVTmFCh3dzJq7u3Kugp9EA=.c20cd86c-2c16-4869-ba7f-76f2a53821d0@github.com>
 <BJtlt-cQZXjDRa0F5QbiqHe_3y-Ih58tlRScZy1H-Ps=.86398c74-3a29-4b8b-b7c6-9e7b6a75cdf9@github.com>
Message-ID: <ijV6S7yy1MtQ0DN9fTc_2s4TkVKfFegnWMQ-mGjnmbQ=.81b14c8b-f414-4988-948a-298767d3c33e@github.com>

On Thu, 2 Nov 2023 23:21:23 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> # Description
>> 
>> Please review this PR with a patch to re-use the same C2_MacroAssembler object to emit all instructions in the same compilation unit.
>> 
>> Overall, the change is pretty simple. However, due to the renaming of the variable to access C2_MacroAssembler, from `_masm.` to `masm->`, and also some method prototype changes, the patch became quite large.
>> 
>> # Help Needed for Testing
>> 
>> I don't have access to all platforms necessary to test this. I hope some other folks can help with testing on `S390`, `RISC-V` and `PPC`.
>
> PPC64 runs into assert(masm->inst_mark() == nullptr) failed: should be.
> V  [libjvm.so+0x1648528]  PhaseOutput::fill_buffer(C2_MacroAssembler*, unsigned int*)+0x10c8  (output.cpp:1812)
> V  [libjvm.so+0x164b35c]  PhaseOutput::Output()+0xd5c  (output.cpp:362)
> V  [libjvm.so+0x958f9c]  Compile::Code_Gen()+0x4ec  (compile.cpp:2989)
> V  [libjvm.so+0x95e484]  Compile::Compile(ciEnv*, ciMethod*, int, Options, DirectiveSet*)+0x1a84  (compile.cpp:887)
> V  [libjvm.so+0x718f58]  C2Compiler::compile_method(ciEnv*, ciMethod*, int, bool, DirectiveSet*)+0x198  (c2compiler.cpp:119)

Thank you for helping with test @TheRealMDoerr @offamitkumar @RealFYang . I working on an update and I'll push it today or soon after.

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

PR Comment: https://git.openjdk.org/jdk/pull/16484#issuecomment-1802277112

From wkemper at openjdk.org  Wed Nov  8 17:54:37 2023
From: wkemper at openjdk.org (William Kemper)
Date: Wed, 8 Nov 2023 17:54:37 GMT
Subject: Integrated: 8319671 GenShen: Old marking may encounter invalid
 pointers in SATB buffers
In-Reply-To: <W0dibwDlhcO9ISwjnLpQYKgMMRy1pfQHTYtXBCwep1I=.7b185312-f96c-4970-827a-f1ab9a56dae9@github.com>
References: <W0dibwDlhcO9ISwjnLpQYKgMMRy1pfQHTYtXBCwep1I=.7b185312-f96c-4970-827a-f1ab9a56dae9@github.com>
Message-ID: <azy5iTR_hg2Kepo6QseNaFn9q3dLu37gbSKJcRj1Ml8=.c0db1b3f-9d20-4633-901f-29313b22ac34@github.com>

On Wed, 8 Nov 2023 01:05:24 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Weak handles which are null'd out after final marking of young, but during marking of old, will have their original referent placed into a SATB buffer. These entries need to be purged before old marking resumes. In the case of abbreviated young cycles, these entries would not be purged.

This pull request has now been integrated.

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

8319671: GenShen: Old marking may encounter invalid pointers in SATB buffers

Reviewed-by: ysr

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

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

From rkennke at openjdk.org  Thu Nov  9 13:25:40 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Thu, 9 Nov 2023 13:25:40 GMT
Subject: RFR: 8318462: [GenShen] Prevent unsafe access to displaced
 mark-word [v6]
In-Reply-To: <LeCiTuYemKhB_xHW8xfNFYnAqv019CX4kZIq2CtG7Gs=.b37843c8-cae6-4e66-9871-18bd9a0165a6@github.com>
References: <uOeuEpzRFvBx1AFgOvvTNfxJIyI4o84yT9D5A_q6BjU=.92103c05-893a-4b0b-a165-54289729f74f@github.com>
 <LeCiTuYemKhB_xHW8xfNFYnAqv019CX4kZIq2CtG7Gs=.b37843c8-cae6-4e66-9871-18bd9a0165a6@github.com>
Message-ID: <SN7VwZzGmyHeRvqFWfZP1S62ZwfJAvz9ABmAiQPoMEA=.0e94e25b-33e8-4e6c-8ed7-fd215ff82d51@github.com>

On Mon, 6 Nov 2023 12:38:46 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> We must be very careful when we access (load or update) the object age concurrently because the age is stored in the object's header and that header can be 'displaced'. This means that the header is overloaded with a pointer (stack or ObjectMonitor*) and the original header is stored at that location. The header can also be in INFLATING state, which means that a stack-lock is currently in the process to be inflated to an ObjectMonitor. Let's consider the cases separately:
>> 
>> Loading object age:
>> - INFLATING: we can not access the header, and thus not the age.
>> - Stack-locked: the thread which locks the object can unlock at any time, concurrently. It is not safe to access the header, and thus the age.
>> - Monitor-locked: monitors don't go away without coordinating with Java threads and possibly GC threads. This coordination is done by handshaking the thread - a Java thread would be brought to its next safepoint, and GC threads, which are typically participating in handshakes by joining the SuspendibleThreadSet, can opt to handshake at a safe point by calling SuspendibleThreadSet::yield(). If 'our' thread participates in handshakes in one way or the other, it is safe to access an ObjectMonitor once we got a valid ObjectMonitor* from an object's header, but only until that thread handshakes. Long story short: it is typically safe to access ObjectMonitor :-)
>> 
>> Updating object age:
>> Updating object age only happens during evacuation, and only on a new copy of an object, before that copy has been published. Access to the object header is therefore fully thread-local and not problematic. What *is* problematic is when we have to deal with displaced headers, because displaced headers are *not* thread local, and must be considered a shared resource. A competing thread may succeed to evacuate the object and publish its copy before 'our' thread can do so. If 'our' thread would update the displaced header, it may over-write whatever the other thread has done.
>> - INFLATING: We cannot access the header at all. However, that should not happen: a thread can only inflate once it has successfully evacuated an object, and 
>> - Stack-locked: the other thread may succeed evacuation and continue to unlock the object, at which point the stack-pointer would be 'dangling' and we may over-write random information on the foreign thread stack.
>> - Monitor-locked: even though monitor deflation is coordinated (see above), updating the displaced header in a monitor might over-...
>
> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix handling of age sentinel

Thanks!

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

PR Comment: https://git.openjdk.org/shenandoah/pull/343#issuecomment-1803825424

From rkennke at openjdk.org  Thu Nov  9 13:43:07 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Thu, 9 Nov 2023 13:43:07 GMT
Subject: Integrated: 8318462: [GenShen] Prevent unsafe access to displaced
 mark-word
In-Reply-To: <uOeuEpzRFvBx1AFgOvvTNfxJIyI4o84yT9D5A_q6BjU=.92103c05-893a-4b0b-a165-54289729f74f@github.com>
References: <uOeuEpzRFvBx1AFgOvvTNfxJIyI4o84yT9D5A_q6BjU=.92103c05-893a-4b0b-a165-54289729f74f@github.com>
Message-ID: <MRn7pioWQIe-aK_TveCQOhPftYZfxXWO3XIKdnDs1DY=.4b640867-bd54-41c4-81da-180790750c08@github.com>

On Wed, 18 Oct 2023 17:23:15 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> We must be very careful when we access (load or update) the object age concurrently because the age is stored in the object's header and that header can be 'displaced'. This means that the header is overloaded with a pointer (stack or ObjectMonitor*) and the original header is stored at that location. The header can also be in INFLATING state, which means that a stack-lock is currently in the process to be inflated to an ObjectMonitor. Let's consider the cases separately:
> 
> Loading object age:
> - INFLATING: we can not access the header, and thus not the age.
> - Stack-locked: the thread which locks the object can unlock at any time, concurrently. It is not safe to access the header, and thus the age.
> - Monitor-locked: monitors don't go away without coordinating with Java threads and possibly GC threads. This coordination is done by handshaking the thread - a Java thread would be brought to its next safepoint, and GC threads, which are typically participating in handshakes by joining the SuspendibleThreadSet, can opt to handshake at a safe point by calling SuspendibleThreadSet::yield(). If 'our' thread participates in handshakes in one way or the other, it is safe to access an ObjectMonitor once we got a valid ObjectMonitor* from an object's header, but only until that thread handshakes. Long story short: it is typically safe to access ObjectMonitor :-)
> 
> Updating object age:
> Updating object age only happens during evacuation, and only on a new copy of an object, before that copy has been published. Access to the object header is therefore fully thread-local and not problematic. What *is* problematic is when we have to deal with displaced headers, because displaced headers are *not* thread local, and must be considered a shared resource. A competing thread may succeed to evacuate the object and publish its copy before 'our' thread can do so. If 'our' thread would update the displaced header, it may over-write whatever the other thread has done.
> - INFLATING: We cannot access the header at all. However, that should not happen: a thread can only inflate once it has successfully evacuated an object, and 
> - Stack-locked: the other thread may succeed evacuation and continue to unlock the object, at which point the stack-pointer would be 'dangling' and we may over-write random information on the foreign thread stack.
> - Monitor-locked: even though monitor deflation is coordinated (see above), updating the displaced header in a monitor might over-write whatever a competi...

This pull request has now been integrated.

Changeset: 48293049
Author:    Roman Kennke <rkennke at openjdk.org>
URL:       https://git.openjdk.org/shenandoah/commit/48293049b6f79fc197fdfc14b23253fa91a20344
Stats:     69 lines in 5 files changed: 28 ins; 26 del; 15 mod

8318462: [GenShen] Prevent unsafe access to displaced mark-word

Reviewed-by: kdnilsen, wkemper, ysr

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

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

From wkemper at openjdk.org  Thu Nov  9 14:15:37 2023
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 9 Nov 2023 14:15:37 GMT
Subject: RFR: Merge openjdk/jdk:master
Message-ID: <JDOQ-6KECd36wxCFG85qMV7rV1W9P7z0s96Ny7FKfTY=.e1949360-62f4-413b-8322-8936aa2e91b1@github.com>

Merges tag jdk-22+23

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

Commit messages:
 - 8319318: bufferedStream fixed case can be removed
 - 8319556: Harmonize interface formatting in the FFM API
 - 8319378: Spec for j.util.Timer::purge and j.util.Timer::cancel could be improved
 - 8315680: java/lang/ref/ReachabilityFenceTest.java should run with -Xbatch
 - 8305814: Update Xalan Java to 2.7.3
 - 8319573: Change to Visual Studio 17.6.5 for building on Windows at Oracle
 - 8319338: tools/jpackage/share/RuntimeImageTest.java fails with -XX:+UseZGC
 - 8319436: Proxy.newProxyInstance throws NPE if loader is null and interface not visible from class loader
 - 8314891: Additional Zip64 extra header validation
 - 8318594: NMT: VM.native_memory crashes on assert if functionality isn't supported by OS
 - ... and 69 more: https://git.openjdk.org/shenandoah/compare/d354141a...8555e0f6

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

Changes: https://git.openjdk.org/shenandoah/pull/354/files
  Stats: 12726 lines in 343 files changed: 6049 ins; 3383 del; 3294 mod
  Patch: https://git.openjdk.org/shenandoah/pull/354.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah.git pull/354/head:pull/354

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

From wkemper at openjdk.org  Thu Nov  9 18:50:05 2023
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 9 Nov 2023 18:50:05 GMT
Subject: RFR: Merge openjdk/jdk:master [v2]
In-Reply-To: <JDOQ-6KECd36wxCFG85qMV7rV1W9P7z0s96Ny7FKfTY=.e1949360-62f4-413b-8322-8936aa2e91b1@github.com>
References: <JDOQ-6KECd36wxCFG85qMV7rV1W9P7z0s96Ny7FKfTY=.e1949360-62f4-413b-8322-8936aa2e91b1@github.com>
Message-ID: <JTrWOcXwq6YxqY3laKItWeDCEKuIK_aVeg4cW7co6Go=.b14576cd-d091-416d-91df-4845dc56d8f7@github.com>

> Merges tag jdk-22+23

William Kemper has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase.

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

Changes:
  - all: https://git.openjdk.org/shenandoah/pull/354/files
  - new: https://git.openjdk.org/shenandoah/pull/354/files/8555e0f6..8555e0f6

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

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

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

From wkemper at openjdk.org  Thu Nov  9 18:50:07 2023
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 9 Nov 2023 18:50:07 GMT
Subject: Integrated: Merge openjdk/jdk:master
In-Reply-To: <JDOQ-6KECd36wxCFG85qMV7rV1W9P7z0s96Ny7FKfTY=.e1949360-62f4-413b-8322-8936aa2e91b1@github.com>
References: <JDOQ-6KECd36wxCFG85qMV7rV1W9P7z0s96Ny7FKfTY=.e1949360-62f4-413b-8322-8936aa2e91b1@github.com>
Message-ID: <CO8-qjz8d8nv34d8_Yde1NJQkcnLu35sUxCDWVnS9Yc=.d0cc6cb2-2d88-49ba-8738-931ef32a9beb@github.com>

On Thu, 9 Nov 2023 14:09:32 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Merges tag jdk-22+23

This pull request has now been integrated.

Changeset: a9718c13
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.org/shenandoah/commit/a9718c135cde2e7402a4051340e5fa91f08313ee
Stats:     12726 lines in 343 files changed: 6049 ins; 3383 del; 3294 mod

Merge

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

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

From rkennke at openjdk.org  Thu Nov  9 20:05:39 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Thu, 9 Nov 2023 20:05:39 GMT
Subject: RFR: 8305896: Alternative full GC forwarding [v55]
In-Reply-To: <yFs73BPFgB89xCPY4k63X4VTz13N8ELJf1lGQlE6UpA=.85ee4f25-a4ee-41d0-b4c2-ed9ff2cb1bb1@github.com>
References: <yFs73BPFgB89xCPY4k63X4VTz13N8ELJf1lGQlE6UpA=.85ee4f25-a4ee-41d0-b4c2-ed9ff2cb1bb1@github.com>
Message-ID: <puBndDbS9afVAyoDN4QxwZsVy-8VHZG5bT8TAFWpW2A=.03e81560-d96e-4318-acf2-0101cf2b043d@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 122 commits:

 - Merge remote-tracking branch 'upstream/master' into JDK-8305896
 - Fix build
 - Merge remote-tracking branch 'upstream/master' into JDK-8305896
 - Merge remote-tracking branch 'upstream/master' into JDK-8305896
 - Merge branch 'master' into JDK-8305896
 - Various cleanups
 - Some @shipilev comments from downstream review
 - 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
 - ... and 112 more: https://git.openjdk.org/jdk/compare/38745eca...bdc8c823

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

Changes: https://git.openjdk.org/jdk/pull/13582/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13582&range=54
  Stats: 1203 lines in 39 files changed: 1079 ins; 10 del; 114 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 wkemper at openjdk.org  Thu Nov  9 21:40:53 2023
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 9 Nov 2023 21:40:53 GMT
Subject: RFR: 8319867: GenShen: Make old regions parseable at end of concurrent
 cycles
Message-ID: <9-BBrOKn0PqKcJcZgRRbDgl8QK04QuC62Jd8CKOwZdo=.15ad81a4-0f10-451e-8921-00b705c5d48d@github.com>

### Background
When Shenandoah is performing a concurrent mark of the old generation, it is not safe for the young generation's remembered set scan to use the old mark bitmap. For this reason, any old regions that were not included in a collection set (either mixed or a global collection) must be made _parseable_ for the remembered set scan (we call this "coalescing and filling" in the code).

### Description
Before this change, Shenandoah has deferred making these regions parseable until it begins the young generation bootstrap cycle. This is fine, except that we have also recently made old generation collections subordinate to young collections. In other words, an old collection cannot start unless Shenandoah wants to first start a young collection.

Unfortunately, the additional time to concurrently coalesce and fill old regions before resetting the old mark bitmaps is not accounted for in the heuristics and this increases the likelihood that the heuristic has started the cycles too late and that the cycle will degenerate into a stop the world pause.

After this change, Shenandoah will make old regions parseable immediately following the last mixed collection (or following a global collection). At this point, Shenandoah has just finished reclaiming memory and we expect less urgency to coalesce and fill old regions. It also means that young bootstrap cycles will not take (much) longer than conventional young generation collections.

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

Commit messages:
 - Fix up documentation
 - Do not change class unloading configuration for degenerated cycles
 - Merge remote-tracking branch 'shenandoah/master' into make-old-parseable-after-evac
 - Purge SATB buffers if necessary at the end of an abbreviated cycle
 - Log if remembered set scan is using mark bitmap or not
 - Don't allow generation to change after we've decided on class unloading
 - Do not attempt to unload classes when resuming old gc operations
 - WIP: Reset old at start of bootstrap cycle
 - WIP: Remove unused parameters
 - WIP: Fix simple issue
 - ... and 2 more: https://git.openjdk.org/shenandoah/compare/20172ba8...012068ac

Changes: https://git.openjdk.org/shenandoah/pull/355/files
 Webrev: https://webrevs.openjdk.org/?repo=shenandoah&pr=355&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8319867
  Stats: 261 lines in 17 files changed: 78 ins; 93 del; 90 mod
  Patch: https://git.openjdk.org/shenandoah/pull/355.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah.git pull/355/head:pull/355

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

From kdnilsen at openjdk.org  Thu Nov  9 22:04:35 2023
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Thu, 9 Nov 2023 22:04:35 GMT
Subject: RFR: 8319867: GenShen: Make old regions parseable at end of
 concurrent cycles
In-Reply-To: <9-BBrOKn0PqKcJcZgRRbDgl8QK04QuC62Jd8CKOwZdo=.15ad81a4-0f10-451e-8921-00b705c5d48d@github.com>
References: <9-BBrOKn0PqKcJcZgRRbDgl8QK04QuC62Jd8CKOwZdo=.15ad81a4-0f10-451e-8921-00b705c5d48d@github.com>
Message-ID: <tMBG74AyZEuSxPv3nn4e9dYf-yV_3fVMFAmGf8CyQ5E=.8900c704-a2c3-4a6d-83a5-f07ea7c0ee0c@github.com>

On Thu, 9 Nov 2023 21:35:40 GMT, William Kemper <wkemper at openjdk.org> wrote:

> ### Background
> When Shenandoah is performing a concurrent mark of the old generation, it is not safe for the young generation's remembered set scan to use the old mark bitmap. For this reason, any old regions that were not included in a collection set (either mixed or a global collection) must be made _parseable_ for the remembered set scan (we call this "coalescing and filling" in the code).
> 
> ### Description
> Before this change, Shenandoah has deferred making these regions parseable until it begins the young generation bootstrap cycle. This is fine, except that we have also recently made old generation collections subordinate to young collections. In other words, an old collection cannot start unless Shenandoah wants to first start a young collection.
> 
> Unfortunately, the additional time to concurrently coalesce and fill old regions before resetting the old mark bitmaps is not accounted for in the heuristics and this increases the likelihood that the heuristic has started the cycles too late and that the cycle will degenerate into a stop the world pause.
> 
> After this change, Shenandoah will make old regions parseable immediately following the last mixed collection (or following a global collection). At this point, Shenandoah has just finished reclaiming memory and we expect less urgency to coalesce and fill old regions. It also means that young bootstrap cycles will not take (much) longer than conventional young generation collections.

Thank you.  I believe this will improve latency for several of our workloads.

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

Marked as reviewed by kdnilsen (Committer).

PR Review: https://git.openjdk.org/shenandoah/pull/355#pullrequestreview-1723575156

From ysr at openjdk.org  Sat Nov 11 00:22:33 2023
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Sat, 11 Nov 2023 00:22:33 GMT
Subject: RFR: 8319867: GenShen: Make old regions parseable at end of
 concurrent cycles
In-Reply-To: <9-BBrOKn0PqKcJcZgRRbDgl8QK04QuC62Jd8CKOwZdo=.15ad81a4-0f10-451e-8921-00b705c5d48d@github.com>
References: <9-BBrOKn0PqKcJcZgRRbDgl8QK04QuC62Jd8CKOwZdo=.15ad81a4-0f10-451e-8921-00b705c5d48d@github.com>
Message-ID: <GFpXA-Z6RjKumIHqEfl9jZjxl4Iq8r6OXxphvXxxdy8=.9dcb4958-cbc8-4392-90c6-e3e98afaba72@github.com>

On Thu, 9 Nov 2023 21:35:40 GMT, William Kemper <wkemper at openjdk.org> wrote:

> ### Background
> When Shenandoah is performing a concurrent mark of the old generation, it is not safe for the young generation's remembered set scan to use the old mark bitmap. For this reason, any old regions that were not included in a collection set (either mixed or a global collection) must be made _parseable_ for the remembered set scan (we call this "coalescing and filling" in the code).
> 
> ### Description
> Before this change, Shenandoah has deferred making these regions parseable until it begins the young generation bootstrap cycle. This is fine, except that we have also recently made old generation collections subordinate to young collections. In other words, an old collection cannot start unless Shenandoah wants to first start a young collection.
> 
> Unfortunately, the additional time to concurrently coalesce and fill old regions before resetting the old mark bitmaps is not accounted for in the heuristics and this increases the likelihood that the heuristic has started the cycles too late and that the cycle will degenerate into a stop the world pause.
> 
> After this change, Shenandoah will make old regions parseable immediately following the last mixed collection (or following a global collection). At this point, Shenandoah has just finished reclaiming memory and we expect less urgency to coalesce and fill old regions. It also means that young bootstrap cycles will not take (much) longer than conventional young generation collections.

Some remarks, not all of them need to be immediately actioned (if the remarks are correct).

Was there a test case that revealed this? If so, can we add that to the JBS ticket and mentioned as part of the testing for the PR?

Marked as reviewed by ysr (Committer).

src/hotspot/share/gc/shenandoah/shenandoahMmuTracker.hpp line 93:

> 91:   // both record_full() and record_degenerated() with the same value of gcid.  record_full() is called first and the log
> 92:   // reports such a cycle as a FULL cycle.
> 93:   void record_young(ShenandoahGeneration* generation, size_t gcid);

Thanks for cleaning up the unused ShenandoahGeneration* and other unused parms.

src/hotspot/share/gc/shenandoah/shenandoahOldGeneration.cpp line 259:

> 257: }
> 258: 
> 259: // Make the old generation regions parseable, so they can be safely

Nothing to do now, but my ex-colleague Peter Kessler told me many years ago that the correct spelling is "parsable" (without the "e" between the s and the a :-) One can do a cleanup of spelling in a separate PR in the fullness of time.

https://word.tips/spelling/parsable-vs-parseable/

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

> 426:   switch (new_state) {
> 427:     case FILLING:
> 428:       assert(heap->is_old_bitmap_stable(), "Cannot begin filling without first completing marking, state is '%s'", state_name(_state));

Do you also want to say:


assert(_state > FILLING && _state != WAITING_FOR_BOOTSTRAP, "Illegal state transition"):

src/hotspot/share/gc/shenandoah/shenandoahOldGeneration.cpp line 432:

> 430:       break;
> 431:     case WAITING_FOR_BOOTSTRAP:
> 432:       // GC cancellation can send us back to IDLE from any state.

Since there isn't now a state named "IDLE", it might be less confusing to just say "FILLING" or "WAITING_FOR_BOOTSTRAP"? Should we assert here that there are no `coalesce_and_fill_candidates` or is that implied by perhaps stronger checks below? (Wouldn't hurt even if so.)

src/hotspot/share/gc/shenandoah/shenandoahOldGeneration.cpp line 448:

> 446:       break;
> 447:     case EVACUATING:
> 448:       assert(_state == WAITING_FOR_BOOTSTRAP || _state == MARKING, "Cannot have old collection candidates without first marking, state is '%s'", state_name(_state));

FWIW, the ASCII art state-transition-diagram doesn't show the transition from WAITING_FOR_BOOTSTRAP directly into EVACUATING, without passing through an intermediate MARKING.

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

PR Review: https://git.openjdk.org/shenandoah/pull/355#pullrequestreview-1725807183
PR Review: https://git.openjdk.org/shenandoah/pull/355#pullrequestreview-1725836333
PR Review Comment: https://git.openjdk.org/shenandoah/pull/355#discussion_r1390033021
PR Review Comment: https://git.openjdk.org/shenandoah/pull/355#discussion_r1390037239
PR Review Comment: https://git.openjdk.org/shenandoah/pull/355#discussion_r1390050334
PR Review Comment: https://git.openjdk.org/shenandoah/pull/355#discussion_r1390047203
PR Review Comment: https://git.openjdk.org/shenandoah/pull/355#discussion_r1390053016

From ysr at openjdk.org  Sat Nov 11 00:22:33 2023
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Sat, 11 Nov 2023 00:22:33 GMT
Subject: RFR: 8319867: GenShen: Make old regions parseable at end of
 concurrent cycles
In-Reply-To: <GFpXA-Z6RjKumIHqEfl9jZjxl4Iq8r6OXxphvXxxdy8=.9dcb4958-cbc8-4392-90c6-e3e98afaba72@github.com>
References: <9-BBrOKn0PqKcJcZgRRbDgl8QK04QuC62Jd8CKOwZdo=.15ad81a4-0f10-451e-8921-00b705c5d48d@github.com>
 <GFpXA-Z6RjKumIHqEfl9jZjxl4Iq8r6OXxphvXxxdy8=.9dcb4958-cbc8-4392-90c6-e3e98afaba72@github.com>
Message-ID: <YtVfB_09X0wpmxLUCI20JSwu49UL61JWWWvyFp3eROQ=.eb4a636b-aacd-4bb2-b14e-8cd1427fbecd@github.com>

On Sat, 11 Nov 2023 00:02:38 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

>> ### Background
>> When Shenandoah is performing a concurrent mark of the old generation, it is not safe for the young generation's remembered set scan to use the old mark bitmap. For this reason, any old regions that were not included in a collection set (either mixed or a global collection) must be made _parseable_ for the remembered set scan (we call this "coalescing and filling" in the code).
>> 
>> ### Description
>> Before this change, Shenandoah has deferred making these regions parseable until it begins the young generation bootstrap cycle. This is fine, except that we have also recently made old generation collections subordinate to young collections. In other words, an old collection cannot start unless Shenandoah wants to first start a young collection.
>> 
>> Unfortunately, the additional time to concurrently coalesce and fill old regions before resetting the old mark bitmaps is not accounted for in the heuristics and this increases the likelihood that the heuristic has started the cycles too late and that the cycle will degenerate into a stop the world pause.
>> 
>> After this change, Shenandoah will make old regions parseable immediately following the last mixed collection (or following a global collection). At this point, Shenandoah has just finished reclaiming memory and we expect less urgency to coalesce and fill old regions. It also means that young bootstrap cycles will not take (much) longer than conventional young generation collections.
>
> src/hotspot/share/gc/shenandoah/shenandoahOldGeneration.cpp line 432:
> 
>> 430:       break;
>> 431:     case WAITING_FOR_BOOTSTRAP:
>> 432:       // GC cancellation can send us back to IDLE from any state.
> 
> Since there isn't now a state named "IDLE", it might be less confusing to just say "FILLING" or "WAITING_FOR_BOOTSTRAP"? Should we assert here that there are no `coalesce_and_fill_candidates` or is that implied by perhaps stronger checks below? (Wouldn't hurt even if so.)

assert(_state != BOOTSTRAP && _state != WAITING_FOR_BOOTSTRAP, "Illegal transition");

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

PR Review Comment: https://git.openjdk.org/shenandoah/pull/355#discussion_r1390050871

From ysr at openjdk.org  Sat Nov 11 00:22:33 2023
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Sat, 11 Nov 2023 00:22:33 GMT
Subject: RFR: 8319867: GenShen: Make old regions parseable at end of
 concurrent cycles
In-Reply-To: <YtVfB_09X0wpmxLUCI20JSwu49UL61JWWWvyFp3eROQ=.eb4a636b-aacd-4bb2-b14e-8cd1427fbecd@github.com>
References: <9-BBrOKn0PqKcJcZgRRbDgl8QK04QuC62Jd8CKOwZdo=.15ad81a4-0f10-451e-8921-00b705c5d48d@github.com>
 <GFpXA-Z6RjKumIHqEfl9jZjxl4Iq8r6OXxphvXxxdy8=.9dcb4958-cbc8-4392-90c6-e3e98afaba72@github.com>
 <YtVfB_09X0wpmxLUCI20JSwu49UL61JWWWvyFp3eROQ=.eb4a636b-aacd-4bb2-b14e-8cd1427fbecd@github.com>
Message-ID: <7qBpCiLCAU6ecsabjcPsvjYH7YxVbnv17ohBd17BtO8=.f2c49bfd-e161-491e-a7c4-a96cb5abdb0a@github.com>

On Sat, 11 Nov 2023 00:07:26 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

>> src/hotspot/share/gc/shenandoah/shenandoahOldGeneration.cpp line 432:
>> 
>>> 430:       break;
>>> 431:     case WAITING_FOR_BOOTSTRAP:
>>> 432:       // GC cancellation can send us back to IDLE from any state.
>> 
>> Since there isn't now a state named "IDLE", it might be less confusing to just say "FILLING" or "WAITING_FOR_BOOTSTRAP"? Should we assert here that there are no `coalesce_and_fill_candidates` or is that implied by perhaps stronger checks below? (Wouldn't hurt even if so.)
>
> assert(_state != BOOTSTRAP && _state != WAITING_FOR_BOOTSTRAP, "Illegal transition");

I am thinking that the most parsimonious way of covering all bases is by associating a pre-condition with entering each state and a post-condition with exiting each state, and verifying those conditions in the transition validation methods. But may be that can be done as a separate PR if it makes sense.

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

PR Review Comment: https://git.openjdk.org/shenandoah/pull/355#discussion_r1390052540

From wkemper at openjdk.org  Sat Nov 11 00:36:30 2023
From: wkemper at openjdk.org (William Kemper)
Date: Sat, 11 Nov 2023 00:36:30 GMT
Subject: RFR: 8319867: GenShen: Make old regions parseable at end of
 concurrent cycles
In-Reply-To: <GFpXA-Z6RjKumIHqEfl9jZjxl4Iq8r6OXxphvXxxdy8=.9dcb4958-cbc8-4392-90c6-e3e98afaba72@github.com>
References: <9-BBrOKn0PqKcJcZgRRbDgl8QK04QuC62Jd8CKOwZdo=.15ad81a4-0f10-451e-8921-00b705c5d48d@github.com>
 <GFpXA-Z6RjKumIHqEfl9jZjxl4Iq8r6OXxphvXxxdy8=.9dcb4958-cbc8-4392-90c6-e3e98afaba72@github.com>
Message-ID: <-8QhfBfs3uf6x7Dlv_IuAvFycOx4BAv1mmeD2gO5jVk=.1712f20a-bd56-4f9e-a7f9-52a12770fea6@github.com>

On Fri, 10 Nov 2023 23:47:23 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

>> ### Background
>> When Shenandoah is performing a concurrent mark of the old generation, it is not safe for the young generation's remembered set scan to use the old mark bitmap. For this reason, any old regions that were not included in a collection set (either mixed or a global collection) must be made _parseable_ for the remembered set scan (we call this "coalescing and filling" in the code).
>> 
>> ### Description
>> Before this change, Shenandoah has deferred making these regions parseable until it begins the young generation bootstrap cycle. This is fine, except that we have also recently made old generation collections subordinate to young collections. In other words, an old collection cannot start unless Shenandoah wants to first start a young collection.
>> 
>> Unfortunately, the additional time to concurrently coalesce and fill old regions before resetting the old mark bitmaps is not accounted for in the heuristics and this increases the likelihood that the heuristic has started the cycles too late and that the cycle will degenerate into a stop the world pause.
>> 
>> After this change, Shenandoah will make old regions parseable immediately following the last mixed collection (or following a global collection). At this point, Shenandoah has just finished reclaiming memory and we expect less urgency to coalesce and fill old regions. It also means that young bootstrap cycles will not take (much) longer than conventional young generation collections.
>
> src/hotspot/share/gc/shenandoah/shenandoahOldGeneration.cpp line 259:
> 
>> 257: }
>> 258: 
>> 259: // Make the old generation regions parseable, so they can be safely
> 
> Nothing to do now, but my ex-colleague Peter Kessler told me many years ago that the correct spelling is "parsable" (without the "e" between the s and the a :-) One can do a cleanup of spelling in a separate PR in the fullness of time.
> 
> https://word.tips/spelling/parsable-vs-parseable/

[0] % grep -irI parsable src/ | wc -l 
352

[0] % grep -irI parseable src/ | wc -l
84

Indeed. I'll fix up all the misspellings in `gc/shenandoah` in a separate PR. Thanks for the tip!

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

PR Review Comment: https://git.openjdk.org/shenandoah/pull/355#discussion_r1390061992

From wkemper at openjdk.org  Sat Nov 11 00:47:32 2023
From: wkemper at openjdk.org (William Kemper)
Date: Sat, 11 Nov 2023 00:47:32 GMT
Subject: RFR: 8319867: GenShen: Make old regions parseable at end of
 concurrent cycles
In-Reply-To: <GFpXA-Z6RjKumIHqEfl9jZjxl4Iq8r6OXxphvXxxdy8=.9dcb4958-cbc8-4392-90c6-e3e98afaba72@github.com>
References: <9-BBrOKn0PqKcJcZgRRbDgl8QK04QuC62Jd8CKOwZdo=.15ad81a4-0f10-451e-8921-00b705c5d48d@github.com>
 <GFpXA-Z6RjKumIHqEfl9jZjxl4Iq8r6OXxphvXxxdy8=.9dcb4958-cbc8-4392-90c6-e3e98afaba72@github.com>
Message-ID: <MB07kaUY-T-oGj9rtyPdbHkNK8-mbTX17R_nlL4Bpb4=.a6276aa1-b80d-4229-8b77-4d9f1565c448@github.com>

On Sat, 11 Nov 2023 00:05:24 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

>> ### Background
>> When Shenandoah is performing a concurrent mark of the old generation, it is not safe for the young generation's remembered set scan to use the old mark bitmap. For this reason, any old regions that were not included in a collection set (either mixed or a global collection) must be made _parseable_ for the remembered set scan (we call this "coalescing and filling" in the code).
>> 
>> ### Description
>> Before this change, Shenandoah has deferred making these regions parseable until it begins the young generation bootstrap cycle. This is fine, except that we have also recently made old generation collections subordinate to young collections. In other words, an old collection cannot start unless Shenandoah wants to first start a young collection.
>> 
>> Unfortunately, the additional time to concurrently coalesce and fill old regions before resetting the old mark bitmaps is not accounted for in the heuristics and this increases the likelihood that the heuristic has started the cycles too late and that the cycle will degenerate into a stop the world pause.
>> 
>> After this change, Shenandoah will make old regions parseable immediately following the last mixed collection (or following a global collection). At this point, Shenandoah has just finished reclaiming memory and we expect less urgency to coalesce and fill old regions. It also means that young bootstrap cycles will not take (much) longer than conventional young generation collections.
>
> src/hotspot/share/gc/shenandoah/shenandoahOldGeneration.cpp line 428:
> 
>> 426:   switch (new_state) {
>> 427:     case FILLING:
>> 428:       assert(heap->is_old_bitmap_stable(), "Cannot begin filling without first completing marking, state is '%s'", state_name(_state));
> 
> Do you also want to say:
> 
> 
> assert(_state > FILLING && _state != WAITING_FOR_BOOTSTRAP, "Illegal state transition"):

No - at the end of a _GLOBAL_ collection, it may put the old generation in this state without progressing through the other states.

> src/hotspot/share/gc/shenandoah/shenandoahOldGeneration.cpp line 448:
> 
>> 446:       break;
>> 447:     case EVACUATING:
>> 448:       assert(_state == WAITING_FOR_BOOTSTRAP || _state == MARKING, "Cannot have old collection candidates without first marking, state is '%s'", state_name(_state));
> 
> FWIW, the ASCII art state-transition-diagram doesn't show the transition from WAITING_FOR_BOOTSTRAP directly into EVACUATING, without passing through an intermediate MARKING.

Yes, that can only happen at the end of a _GLOBAL_ collection. This is explained in the comment above the diagram. I will add it to the diagram.

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

PR Review Comment: https://git.openjdk.org/shenandoah/pull/355#discussion_r1390064709
PR Review Comment: https://git.openjdk.org/shenandoah/pull/355#discussion_r1390066019

From wkemper at openjdk.org  Sat Nov 11 00:47:32 2023
From: wkemper at openjdk.org (William Kemper)
Date: Sat, 11 Nov 2023 00:47:32 GMT
Subject: RFR: 8319867: GenShen: Make old regions parseable at end of
 concurrent cycles
In-Reply-To: <7qBpCiLCAU6ecsabjcPsvjYH7YxVbnv17ohBd17BtO8=.f2c49bfd-e161-491e-a7c4-a96cb5abdb0a@github.com>
References: <9-BBrOKn0PqKcJcZgRRbDgl8QK04QuC62Jd8CKOwZdo=.15ad81a4-0f10-451e-8921-00b705c5d48d@github.com>
 <GFpXA-Z6RjKumIHqEfl9jZjxl4Iq8r6OXxphvXxxdy8=.9dcb4958-cbc8-4392-90c6-e3e98afaba72@github.com>
 <YtVfB_09X0wpmxLUCI20JSwu49UL61JWWWvyFp3eROQ=.eb4a636b-aacd-4bb2-b14e-8cd1427fbecd@github.com>
 <7qBpCiLCAU6ecsabjcPsvjYH7YxVbnv17ohBd17BtO8=.f2c49bfd-e161-491e-a7c4-a96cb5abdb0a@github.com>
Message-ID: <LuQr2EyCvx0gDu5QcvQmHBVSHzSMieni-EJXWxMMc24=.84f9e140-a5b1-499d-9363-0d5a36fa0b0a@github.com>

On Sat, 11 Nov 2023 00:11:32 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

>> assert(_state != BOOTSTRAP && _state != WAITING_FOR_BOOTSTRAP, "Illegal transition");
>
> I am thinking that the most parsimonious way of covering all bases is by associating a pre-condition with entering each state and a post-condition with exiting each state, and verifying those conditions in the transition validation methods. But may be that can be done as a separate PR if it makes sense.

Hmm - I thought that's what this code is doing. Or rather, it is asserting what conditions must hold to _be_ in this state (checking pre/post conditions simultaneously).

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

PR Review Comment: https://git.openjdk.org/shenandoah/pull/355#discussion_r1390064292

From wkemper at openjdk.org  Sat Nov 11 00:56:02 2023
From: wkemper at openjdk.org (William Kemper)
Date: Sat, 11 Nov 2023 00:56:02 GMT
Subject: RFR: 8319867: GenShen: Make old regions parseable at end of
 concurrent cycles [v2]
In-Reply-To: <9-BBrOKn0PqKcJcZgRRbDgl8QK04QuC62Jd8CKOwZdo=.15ad81a4-0f10-451e-8921-00b705c5d48d@github.com>
References: <9-BBrOKn0PqKcJcZgRRbDgl8QK04QuC62Jd8CKOwZdo=.15ad81a4-0f10-451e-8921-00b705c5d48d@github.com>
Message-ID: <94gpkJJtcuzv66G823Fdv3fl_0AVVXHqDt5-7umYq-E=.f49bfd59-8375-475f-a255-d6206a42e516@github.com>

> ### Background
> When Shenandoah is performing a concurrent mark of the old generation, it is not safe for the young generation's remembered set scan to use the old mark bitmap. For this reason, any old regions that were not included in a collection set (either mixed or a global collection) must be made _parseable_ for the remembered set scan (we call this "coalescing and filling" in the code).
> 
> ### Description
> Before this change, Shenandoah has deferred making these regions parseable until it begins the young generation bootstrap cycle. This is fine, except that we have also recently made old generation collections subordinate to young collections. In other words, an old collection cannot start unless Shenandoah wants to first start a young collection.
> 
> Unfortunately, the additional time to concurrently coalesce and fill old regions before resetting the old mark bitmaps is not accounted for in the heuristics and this increases the likelihood that the heuristic has started the cycles too late and that the cycle will degenerate into a stop the world pause.
> 
> After this change, Shenandoah will make old regions parseable immediately following the last mixed collection (or following a global collection). At this point, Shenandoah has just finished reclaiming memory and we expect less urgency to coalesce and fill old regions. It also means that young bootstrap cycles will not take (much) longer than conventional young generation collections.

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

  Update ascii diagram, fix spelling errors

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

Changes:
  - all: https://git.openjdk.org/shenandoah/pull/355/files
  - new: https://git.openjdk.org/shenandoah/pull/355/files/012068ac..65bec3b2

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

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

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

From wkemper at openjdk.org  Sat Nov 11 00:56:02 2023
From: wkemper at openjdk.org (William Kemper)
Date: Sat, 11 Nov 2023 00:56:02 GMT
Subject: RFR: 8319867: GenShen: Make old regions parseable at end of
 concurrent cycles
In-Reply-To: <9-BBrOKn0PqKcJcZgRRbDgl8QK04QuC62Jd8CKOwZdo=.15ad81a4-0f10-451e-8921-00b705c5d48d@github.com>
References: <9-BBrOKn0PqKcJcZgRRbDgl8QK04QuC62Jd8CKOwZdo=.15ad81a4-0f10-451e-8921-00b705c5d48d@github.com>
Message-ID: <lHbFF2rWEvBd6qrl4RKsCDqEQ624YiPsHrRFCys1vu0=.32fa04f6-3b62-4e74-9582-6d93ace9f144@github.com>

On Thu, 9 Nov 2023 21:35:40 GMT, William Kemper <wkemper at openjdk.org> wrote:

> ### Background
> When Shenandoah is performing a concurrent mark of the old generation, it is not safe for the young generation's remembered set scan to use the old mark bitmap. For this reason, any old regions that were not included in a collection set (either mixed or a global collection) must be made _parseable_ for the remembered set scan (we call this "coalescing and filling" in the code).
> 
> ### Description
> Before this change, Shenandoah has deferred making these regions parseable until it begins the young generation bootstrap cycle. This is fine, except that we have also recently made old generation collections subordinate to young collections. In other words, an old collection cannot start unless Shenandoah wants to first start a young collection.
> 
> Unfortunately, the additional time to concurrently coalesce and fill old regions before resetting the old mark bitmaps is not accounted for in the heuristics and this increases the likelihood that the heuristic has started the cycles too late and that the cycle will degenerate into a stop the world pause.
> 
> After this change, Shenandoah will make old regions parseable immediately following the last mixed collection (or following a global collection). At this point, Shenandoah has just finished reclaiming memory and we expect less urgency to coalesce and fill old regions. It also means that young bootstrap cycles will not take (much) longer than conventional young generation collections.

We don't have a test that shows this, just thought experiments.

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

PR Comment: https://git.openjdk.org/shenandoah/pull/355#issuecomment-1806606414

From dholmes at openjdk.org  Mon Nov 13 04:44:09 2023
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 13 Nov 2023 04:44:09 GMT
Subject: RFR: 8318776: Require supports_cx8 to always be true
Message-ID: <oIBgmqm_tcBgAzRlR-vLLnW9ky7pTgNwKy0463UZw5Q=.87894004-0e8a-4d75-bb8f-be6602a09a97@github.com>

As discussed in JBS all platforms (some tweaks to Zero are in progress) actually do support `cx8` i.e. 64-bit compare-and-exchange, so we can strip out the locked-based alternatives to using it and just add a guarantee that it is true at runtime. And all platforms except some ARM variants set `SUPPORTS_NATIVE_CX8`, so we can greatly simplify things. Summary of changes:
- `_supports_cx8` field is only needed when `SUPPORTS_NATIVE_CX8` is not defined
- Assertions for `supports_cx8()` are removed
- Access backend is greatly simplified without the need for lock-based alternative
- `java.util.concurrent.AtomicLongFieldUpdater` is simplified without the need for a lock-based alternative

I did consider moving all the ARM `kuser_helper` related code to be only defined when `SUPPORTS_NATIVE_CX8` is not defined, but there was a theoretical risk this could change the behaviour if ARMv7 binaries were run on other ARM CPU's. I added a note to that effect in vm_version_linux_arm32.cpp so the ARM port maintainers could clean this up further if desired.

Testing:
- All Oracle tiers 1-5 builds (which includes an ARMv7 build)
- GHA builds/tests
- Oracle tiers 1-3 sanity testing

Zero changes coming in via [JDK-8319777](https://bugs.openjdk.org/browse/JDK-8319777) will be merged when they arrive.

Thanks.

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

Commit messages:
 - 8318776: Require supports_cx8 to always be true

Changes: https://git.openjdk.org/jdk/pull/16625/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16625&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8318776
  Stats: 386 lines in 35 files changed: 14 ins; 359 del; 13 mod
  Patch: https://git.openjdk.org/jdk/pull/16625.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16625/head:pull/16625

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

From dholmes at openjdk.org  Mon Nov 13 04:50:12 2023
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 13 Nov 2023 04:50:12 GMT
Subject: RFR: 8318776: Require supports_cx8 to always be true [v2]
In-Reply-To: <oIBgmqm_tcBgAzRlR-vLLnW9ky7pTgNwKy0463UZw5Q=.87894004-0e8a-4d75-bb8f-be6602a09a97@github.com>
References: <oIBgmqm_tcBgAzRlR-vLLnW9ky7pTgNwKy0463UZw5Q=.87894004-0e8a-4d75-bb8f-be6602a09a97@github.com>
Message-ID: <DuQh-KLdZfRWCAdtEaOSolJW0ipljBozPOzIKsgIRkE=.bf4d8f7a-ba10-4cf0-8738-0ae55cdd8548@github.com>

> As discussed in JBS all platforms (some tweaks to Zero are in progress) actually do support `cx8` i.e. 64-bit compare-and-exchange, so we can strip out the locked-based alternatives to using it and just add a guarantee that it is true at runtime. And all platforms except some ARM variants set `SUPPORTS_NATIVE_CX8`, so we can greatly simplify things. Summary of changes:
> - `_supports_cx8` field is only needed when `SUPPORTS_NATIVE_CX8` is not defined
> - Assertions for `supports_cx8()` are removed
> - Compiler predicates requiring `supports_cx8()` are removed
> - Access backend is greatly simplified without the need for lock-based alternative
> - `java.util.concurrent.AtomicLongFieldUpdater` is simplified without the need for a lock-based alternative
> 
> I did consider moving all the ARM `kuser_helper` related code to be only defined when `SUPPORTS_NATIVE_CX8` is not defined, but there was a theoretical risk this could change the behaviour if ARMv7 binaries were run on other ARM CPU's. I added a note to that effect in vm_version_linux_arm32.cpp so the ARM port maintainers could clean this up further if desired.
> 
> Testing:
> - All Oracle tiers 1-5 builds (which includes an ARMv7 build)
> - GHA builds/tests
> - Oracle tiers 1-3 sanity testing
> 
> Zero changes coming in via [JDK-8319777](https://bugs.openjdk.org/browse/JDK-8319777) will be merged when they arrive.
> 
> Thanks.

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

  Remove test for VMSupportsCX8

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16625/files
  - new: https://git.openjdk.org/jdk/pull/16625/files/3f2ec66f..b6dea4b6

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

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

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

From dholmes at openjdk.org  Mon Nov 13 05:10:17 2023
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 13 Nov 2023 05:10:17 GMT
Subject: RFR: 8318776: Require supports_cx8 to always be true [v3]
In-Reply-To: <oIBgmqm_tcBgAzRlR-vLLnW9ky7pTgNwKy0463UZw5Q=.87894004-0e8a-4d75-bb8f-be6602a09a97@github.com>
References: <oIBgmqm_tcBgAzRlR-vLLnW9ky7pTgNwKy0463UZw5Q=.87894004-0e8a-4d75-bb8f-be6602a09a97@github.com>
Message-ID: <Bo-4dwX2g5Nx-_DgsN1hbC24GsjFPDYgxRXJDN4FdUg=.d70c5d95-eb3a-4e4e-bd56-914e1da02779@github.com>

> As discussed in JBS all platforms (some tweaks to Zero are in progress) actually do support `cx8` i.e. 64-bit compare-and-exchange, so we can strip out the locked-based alternatives to using it and just add a guarantee that it is true at runtime. And all platforms except some ARM variants set `SUPPORTS_NATIVE_CX8`, so we can greatly simplify things. Summary of changes:
> - `_supports_cx8` field is only needed when `SUPPORTS_NATIVE_CX8` is not defined
> - Assertions for `supports_cx8()` are removed
> - Compiler predicates requiring `supports_cx8()` are removed
> - Access backend is greatly simplified without the need for lock-based alternative
> - `java.util.concurrent.AtomicLongFieldUpdater` is simplified without the need for a lock-based alternative
> 
> I did consider moving all the ARM `kuser_helper` related code to be only defined when `SUPPORTS_NATIVE_CX8` is not defined, but there was a theoretical risk this could change the behaviour if ARMv7 binaries were run on other ARM CPU's. I added a note to that effect in vm_version_linux_arm32.cpp so the ARM port maintainers could clean this up further if desired.
> 
> Testing:
> - All Oracle tiers 1-5 builds (which includes an ARMv7 build)
> - GHA builds/tests
> - Oracle tiers 1-3 sanity testing
> 
> Zero changes coming in via [JDK-8319777](https://bugs.openjdk.org/browse/JDK-8319777) will be merged when they arrive.
> 
> Thanks.

David Holmes has updated the pull request incrementally with two additional commits since the last revision:

 - Remove cx8 comment as no longer relevant (the spinlock is used regardless of cx8)
 - Remove suports_cx8() checks from gtest

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16625/files
  - new: https://git.openjdk.org/jdk/pull/16625/files/b6dea4b6..65871144

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

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

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

From ysr at openjdk.org  Mon Nov 13 15:55:05 2023
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Mon, 13 Nov 2023 15:55:05 GMT
Subject: RFR: 8319867: GenShen: Make old regions parseable at end of
 concurrent cycles [v2]
In-Reply-To: <94gpkJJtcuzv66G823Fdv3fl_0AVVXHqDt5-7umYq-E=.f49bfd59-8375-475f-a255-d6206a42e516@github.com>
References: <9-BBrOKn0PqKcJcZgRRbDgl8QK04QuC62Jd8CKOwZdo=.15ad81a4-0f10-451e-8921-00b705c5d48d@github.com>
 <94gpkJJtcuzv66G823Fdv3fl_0AVVXHqDt5-7umYq-E=.f49bfd59-8375-475f-a255-d6206a42e516@github.com>
Message-ID: <3x_japJ76Ze-FbVdFv2WZOwApjvKvA2oHr1VkaQhhi4=.635138d7-f16b-4ed8-b5f7-6819bdb170a6@github.com>

On Sat, 11 Nov 2023 00:56:02 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> ### Background
>> When Shenandoah is performing a concurrent mark of the old generation, it is not safe for the young generation's remembered set scan to use the old mark bitmap. For this reason, any old regions that were not included in a collection set (either mixed or a global collection) must be made _parseable_ for the remembered set scan (we call this "coalescing and filling" in the code).
>> 
>> ### Description
>> Before this change, Shenandoah has deferred making these regions parseable until it begins the young generation bootstrap cycle. This is fine, except that we have also recently made old generation collections subordinate to young collections. In other words, an old collection cannot start unless Shenandoah wants to first start a young collection.
>> 
>> Unfortunately, the additional time to concurrently coalesce and fill old regions before resetting the old mark bitmaps is not accounted for in the heuristics and this increases the likelihood that the heuristic has started the cycles too late and that the cycle will degenerate into a stop the world pause.
>> 
>> After this change, Shenandoah will make old regions parseable immediately following the last mixed collection (or following a global collection). At this point, Shenandoah has just finished reclaiming memory and we expect less urgency to coalesce and fill old regions. It also means that young bootstrap cycles will not take (much) longer than conventional young generation collections.
>
> William Kemper has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update ascii diagram, fix spelling errors

LGTM; reviewed!

?

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

Marked as reviewed by ysr (Committer).

PR Review: https://git.openjdk.org/shenandoah/pull/355#pullrequestreview-1727623009

From ysr at openjdk.org  Mon Nov 13 15:55:08 2023
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Mon, 13 Nov 2023 15:55:08 GMT
Subject: RFR: 8319867: GenShen: Make old regions parseable at end of
 concurrent cycles [v2]
In-Reply-To: <MB07kaUY-T-oGj9rtyPdbHkNK8-mbTX17R_nlL4Bpb4=.a6276aa1-b80d-4229-8b77-4d9f1565c448@github.com>
References: <9-BBrOKn0PqKcJcZgRRbDgl8QK04QuC62Jd8CKOwZdo=.15ad81a4-0f10-451e-8921-00b705c5d48d@github.com>
 <GFpXA-Z6RjKumIHqEfl9jZjxl4Iq8r6OXxphvXxxdy8=.9dcb4958-cbc8-4392-90c6-e3e98afaba72@github.com>
 <MB07kaUY-T-oGj9rtyPdbHkNK8-mbTX17R_nlL4Bpb4=.a6276aa1-b80d-4229-8b77-4d9f1565c448@github.com>
Message-ID: <dbbWyc_S22RkxYc2YuARhcu0RLyLzZlhlCaUDfpTfbQ=.e5f81b65-dbd2-43fe-a940-f1bf1b7313f5@github.com>

On Sat, 11 Nov 2023 00:44:35 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> src/hotspot/share/gc/shenandoah/shenandoahOldGeneration.cpp line 448:
>> 
>>> 446:       break;
>>> 447:     case EVACUATING:
>>> 448:       assert(_state == WAITING_FOR_BOOTSTRAP || _state == MARKING, "Cannot have old collection candidates without first marking, state is '%s'", state_name(_state));
>> 
>> FWIW, the ASCII art state-transition-diagram doesn't show the transition from WAITING_FOR_BOOTSTRAP directly into EVACUATING, without passing through an intermediate MARKING.
>
> Yes, that can only happen at the end of a _GLOBAL_ collection. This is explained in the comment above the diagram. I will add it to the diagram.

Got it. One way to manage this and still get stronger checking during all, but in particular non-global, collections, might be to organize the state transition checks per collection type, and make assertions specific to the kind of collection in which the transition is happening/being checked. But perhaps that is overkill, and in any case not necessary in this PR.

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

PR Review Comment: https://git.openjdk.org/shenandoah/pull/355#discussion_r1391304232

From wkemper at openjdk.org  Mon Nov 13 17:03:15 2023
From: wkemper at openjdk.org (William Kemper)
Date: Mon, 13 Nov 2023 17:03:15 GMT
Subject: RFR: 8319867: GenShen: Make old regions parsable at end of
 concurrent cycles [v3]
In-Reply-To: <9-BBrOKn0PqKcJcZgRRbDgl8QK04QuC62Jd8CKOwZdo=.15ad81a4-0f10-451e-8921-00b705c5d48d@github.com>
References: <9-BBrOKn0PqKcJcZgRRbDgl8QK04QuC62Jd8CKOwZdo=.15ad81a4-0f10-451e-8921-00b705c5d48d@github.com>
Message-ID: <S3UkNKAG8zYatCP3MCowgoXrNH0rURehJn_VPjtj_PY=.25fdcabb-9c8a-40be-b83e-e421bd9fb096@github.com>

> ### Background
> When Shenandoah is performing a concurrent mark of the old generation, it is not safe for the young generation's remembered set scan to use the old mark bitmap. For this reason, any old regions that were not included in a collection set (either mixed or a global collection) must be made _parsable_ for the remembered set scan (we call this "coalescing and filling" in the code).
> 
> ### Description
> Before this change, Shenandoah has deferred making these regions parsable until it begins the young generation bootstrap cycle. This is fine, except that we have also recently made old generation collections subordinate to young collections. In other words, an old collection cannot start unless Shenandoah wants to first start a young collection.
> 
> Unfortunately, the additional time to concurrently coalesce and fill old regions before resetting the old mark bitmaps is not accounted for in the heuristics and this increases the likelihood that the heuristic has started the cycles too late and that the cycle will degenerate into a stop the world pause.
> 
> After this change, Shenandoah will make old regions parsable immediately following the last mixed collection (or following a global collection). At this point, Shenandoah has just finished reclaiming memory and we expect less urgency to coalesce and fill old regions. It also means that young bootstrap cycles will not take (much) longer than conventional young generation collections.

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

  Fix whitespace errors

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

Changes:
  - all: https://git.openjdk.org/shenandoah/pull/355/files
  - new: https://git.openjdk.org/shenandoah/pull/355/files/65bec3b2..07d93f95

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

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

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

From wkemper at openjdk.org  Mon Nov 13 17:08:39 2023
From: wkemper at openjdk.org (William Kemper)
Date: Mon, 13 Nov 2023 17:08:39 GMT
Subject: RFR: 8319342: GenShen: Reset the count of degenerated cycles in a
 row following Full GC [v3]
In-Reply-To: <SDgKwSOyNjwyBe1okGVAw-HmRUPnhl4BFCukJzRf2dU=.f743b040-5694-4bc7-b561-0de3bc395b18@github.com>
References: <rCs8Wg84Qlm7U040SDODaHg1RYJTj-m8yBFacF2xmsM=.f2e385ca-d02b-42b5-8f5a-2d79e83976c2@github.com>
 <SDgKwSOyNjwyBe1okGVAw-HmRUPnhl4BFCukJzRf2dU=.f743b040-5694-4bc7-b561-0de3bc395b18@github.com>
Message-ID: <pmYzZMJokA1OoyFw2Z9RBPY-mPrc3LDcRZnQxAPhb8k=.100e9471-efe9-498a-943f-0eaa0469e025@github.com>

On Tue, 7 Nov 2023 22:02:51 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> After a Full GC completes, reset the count on consecutive degenerated cycles to zero.  This prevents automatic triggering of back-to-back Full GC.
>
> Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix typo

Marked as reviewed by wkemper (Committer).

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

PR Review: https://git.openjdk.org/shenandoah/pull/352#pullrequestreview-1727795317

From wkemper at openjdk.org  Mon Nov 13 17:13:54 2023
From: wkemper at openjdk.org (William Kemper)
Date: Mon, 13 Nov 2023 17:13:54 GMT
Subject: RFR: 8319931: GenShen: Increase no progress threshold for
 TestThreadFailure
Message-ID: <X7rwJXT2qWRV5nhseL0WXXk6CNB0LPdA-w0Z6YeJJXk=.d90d2e69-3c3c-4cd0-a02b-9b4e168596a7@github.com>

The test walks to close to the edge of an out of memory cliff. Intermittent failures are caused by [JDK-8316632](https://bugs.openjdk.org/browse/JDK-8316632). Further investigation is needed for Genshen. The intention of this PR is just to increase the setting `ShenandoahNoProgressThreshold` for this test to pass.

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

Commit messages:
 - Increase no progress threshold for generational test

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

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

From kdnilsen at openjdk.org  Mon Nov 13 17:54:37 2023
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Mon, 13 Nov 2023 17:54:37 GMT
Subject: RFR: 8319931: GenShen: Increase no progress threshold for
 TestThreadFailure
In-Reply-To: <X7rwJXT2qWRV5nhseL0WXXk6CNB0LPdA-w0Z6YeJJXk=.d90d2e69-3c3c-4cd0-a02b-9b4e168596a7@github.com>
References: <X7rwJXT2qWRV5nhseL0WXXk6CNB0LPdA-w0Z6YeJJXk=.d90d2e69-3c3c-4cd0-a02b-9b4e168596a7@github.com>
Message-ID: <mxZc-pwTaP-ayHmFO-KZo7DcTaCTMwX0lP57qQd-2NE=.17b07baf-c439-4ce3-8987-c7614ee241b0@github.com>

On Mon, 13 Nov 2023 17:09:04 GMT, William Kemper <wkemper at openjdk.org> wrote:

> The test walks to close to the edge of an out of memory cliff. Intermittent failures are caused by [JDK-8316632](https://bugs.openjdk.org/browse/JDK-8316632). Further investigation is needed for Genshen. The intention of this PR is just to increase the setting `ShenandoahNoProgressThreshold` for this test to pass.

Marked as reviewed by kdnilsen (Committer).

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

PR Review: https://git.openjdk.org/shenandoah/pull/356#pullrequestreview-1727890128

From wkemper at openjdk.org  Mon Nov 13 18:06:35 2023
From: wkemper at openjdk.org (William Kemper)
Date: Mon, 13 Nov 2023 18:06:35 GMT
Subject: Integrated: 8319867: GenShen: Make old regions parsable at end of
 concurrent cycles
In-Reply-To: <9-BBrOKn0PqKcJcZgRRbDgl8QK04QuC62Jd8CKOwZdo=.15ad81a4-0f10-451e-8921-00b705c5d48d@github.com>
References: <9-BBrOKn0PqKcJcZgRRbDgl8QK04QuC62Jd8CKOwZdo=.15ad81a4-0f10-451e-8921-00b705c5d48d@github.com>
Message-ID: <keaYHH4KAsbdl179XLCcISEpO4fGHdRgZqQMnWrL5Do=.88f73e79-0bf3-47ee-be46-4b3560aa9aa3@github.com>

On Thu, 9 Nov 2023 21:35:40 GMT, William Kemper <wkemper at openjdk.org> wrote:

> ### Background
> When Shenandoah is performing a concurrent mark of the old generation, it is not safe for the young generation's remembered set scan to use the old mark bitmap. For this reason, any old regions that were not included in a collection set (either mixed or a global collection) must be made _parsable_ for the remembered set scan (we call this "coalescing and filling" in the code).
> 
> ### Description
> Before this change, Shenandoah has deferred making these regions parsable until it begins the young generation bootstrap cycle. This is fine, except that we have also recently made old generation collections subordinate to young collections. In other words, an old collection cannot start unless Shenandoah wants to first start a young collection.
> 
> Unfortunately, the additional time to concurrently coalesce and fill old regions before resetting the old mark bitmaps is not accounted for in the heuristics and this increases the likelihood that the heuristic has started the cycles too late and that the cycle will degenerate into a stop the world pause.
> 
> After this change, Shenandoah will make old regions parsable immediately following the last mixed collection (or following a global collection). At this point, Shenandoah has just finished reclaiming memory and we expect less urgency to coalesce and fill old regions. It also means that young bootstrap cycles will not take (much) longer than conventional young generation collections.

This pull request has now been integrated.

Changeset: e8602e7b
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.org/shenandoah/commit/e8602e7bf3fb4fb4539ee00683551fadcc739e65
Stats:     257 lines in 17 files changed: 73 ins; 93 del; 91 mod

8319867: GenShen: Make old regions parsable at end of concurrent cycles

Reviewed-by: kdnilsen, ysr

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

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

From ysr at openjdk.org  Mon Nov 13 18:06:39 2023
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Mon, 13 Nov 2023 18:06:39 GMT
Subject: RFR: 8319931: GenShen: Increase no progress threshold for
 TestThreadFailure
In-Reply-To: <X7rwJXT2qWRV5nhseL0WXXk6CNB0LPdA-w0Z6YeJJXk=.d90d2e69-3c3c-4cd0-a02b-9b4e168596a7@github.com>
References: <X7rwJXT2qWRV5nhseL0WXXk6CNB0LPdA-w0Z6YeJJXk=.d90d2e69-3c3c-4cd0-a02b-9b4e168596a7@github.com>
Message-ID: <j6CbUOlCde2eU9fdBkRzU5dn7tLmunRARHK2lPeZrxM=.564f8204-f6a8-4940-a39f-c238c4d69820@github.com>

On Mon, 13 Nov 2023 17:09:04 GMT, William Kemper <wkemper at openjdk.org> wrote:

> The test walks to close to the edge of an out of memory cliff. Intermittent failures are caused by [JDK-8316632](https://bugs.openjdk.org/browse/JDK-8316632). Further investigation is needed for Genshen. The intention of this PR is just to increase the setting `ShenandoahNoProgressThreshold` for this test to pass.

Marked as reviewed by ysr (Committer).

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

PR Review: https://git.openjdk.org/shenandoah/pull/356#pullrequestreview-1727917830

From wkemper at openjdk.org  Mon Nov 13 18:06:39 2023
From: wkemper at openjdk.org (William Kemper)
Date: Mon, 13 Nov 2023 18:06:39 GMT
Subject: Integrated: 8319931: GenShen: Increase no progress threshold for
 TestThreadFailure
In-Reply-To: <X7rwJXT2qWRV5nhseL0WXXk6CNB0LPdA-w0Z6YeJJXk=.d90d2e69-3c3c-4cd0-a02b-9b4e168596a7@github.com>
References: <X7rwJXT2qWRV5nhseL0WXXk6CNB0LPdA-w0Z6YeJJXk=.d90d2e69-3c3c-4cd0-a02b-9b4e168596a7@github.com>
Message-ID: <15ePUmSj_yCo6rtxRvDcL8LcCc48uF9tsFi1bSW1UZE=.22122d78-0bb3-447b-b4e2-d22735b16201@github.com>

On Mon, 13 Nov 2023 17:09:04 GMT, William Kemper <wkemper at openjdk.org> wrote:

> The test walks to close to the edge of an out of memory cliff. Intermittent failures are caused by [JDK-8316632](https://bugs.openjdk.org/browse/JDK-8316632). Further investigation is needed for Genshen. The intention of this PR is just to increase the setting `ShenandoahNoProgressThreshold` for this test to pass.

This pull request has now been integrated.

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

8319931: GenShen: Increase no progress threshold for TestThreadFailure

Reviewed-by: kdnilsen

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

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

From ysr at openjdk.org  Mon Nov 13 18:25:36 2023
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Mon, 13 Nov 2023 18:25:36 GMT
Subject: RFR: 8319342: GenShen: Reset the count of degenerated cycles in a
 row following Full GC [v3]
In-Reply-To: <SDgKwSOyNjwyBe1okGVAw-HmRUPnhl4BFCukJzRf2dU=.f743b040-5694-4bc7-b561-0de3bc395b18@github.com>
References: <rCs8Wg84Qlm7U040SDODaHg1RYJTj-m8yBFacF2xmsM=.f2e385ca-d02b-42b5-8f5a-2d79e83976c2@github.com>
 <SDgKwSOyNjwyBe1okGVAw-HmRUPnhl4BFCukJzRf2dU=.f743b040-5694-4bc7-b561-0de3bc395b18@github.com>
Message-ID: <0IkvH5QVsb7MAnYvEUnoPISj8kpd1jmCfFvTZdAIlH0=.4962b741-7f00-4631-ad6d-2ffb50f25396@github.com>

On Tue, 7 Nov 2023 22:02:51 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> After a Full GC completes, reset the count on consecutive degenerated cycles to zero.  This prevents automatic triggering of back-to-back Full GC.
>
> Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix typo

Marked as reviewed by ysr (Committer).

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

PR Review: https://git.openjdk.org/shenandoah/pull/352#pullrequestreview-1727949011

From kdnilsen at openjdk.org  Mon Nov 13 21:26:14 2023
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Mon, 13 Nov 2023 21:26:14 GMT
Subject: Integrated: 8319342: GenShen: Reset the count of degenerated cycles in
 a row following Full GC
In-Reply-To: <rCs8Wg84Qlm7U040SDODaHg1RYJTj-m8yBFacF2xmsM=.f2e385ca-d02b-42b5-8f5a-2d79e83976c2@github.com>
References: <rCs8Wg84Qlm7U040SDODaHg1RYJTj-m8yBFacF2xmsM=.f2e385ca-d02b-42b5-8f5a-2d79e83976c2@github.com>
Message-ID: <mQNzxlGE_p-ZWR4RvyG9B1ZWymqpd1Mc7kOhgmXyCe8=.52bb4932-3de3-491f-a83e-c148eae910e3@github.com>

On Fri, 3 Nov 2023 21:17:42 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

> After a Full GC completes, reset the count on consecutive degenerated cycles to zero.  This prevents automatic triggering of back-to-back Full GC.

This pull request has now been integrated.

Changeset: 81de88c5
Author:    Kelvin Nilsen <kdnilsen at openjdk.org>
URL:       https://git.openjdk.org/shenandoah/commit/81de88c59bbbd3e3ea2afbf8f563febc82797a5d
Stats:     41 lines in 7 files changed: 13 ins; 20 del; 8 mod

8319342: GenShen: Reset the count of degenerated cycles in a row following Full GC

Reviewed-by: wkemper, ysr

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

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

From iwalulya at openjdk.org  Tue Nov 14 19:57:28 2023
From: iwalulya at openjdk.org (Ivan Walulya)
Date: Tue, 14 Nov 2023 19:57:28 GMT
Subject: RFR: 8319439: Move BufferNode from PtrQueue files to new files
In-Reply-To: <zgfte_VjFQ56hJ2KGXvXtAhrjBaPvhPZ4t59eh-UN8U=.4beba8d0-dbe8-4582-93cb-b4a60b898bcf@github.com>
References: <zgfte_VjFQ56hJ2KGXvXtAhrjBaPvhPZ4t59eh-UN8U=.4beba8d0-dbe8-4582-93cb-b4a60b898bcf@github.com>
Message-ID: <pbcAhp2pGmK-svoJMDFWngvG1hn54Dyh2W3Ic2Ck2AU=.25902f52-7f8f-4f22-a9b6-de108a291857@github.com>

On Sat, 4 Nov 2023 11:25:05 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this simple (trivial?) change that moves the BufferNode class
> from share/gc/shared/ptrQueue.[ch]pp to new files
> share/gc/shared/bufferNode.[ch]pp.  The code (as opposed to the surrounding
> boiler plate and #include's) was moved unchanged.
> 
> This led to adding #include's of the new header file to a bunch of other files
> (include what you use), in some cases eliminating the need to #include
> ptrQueue.hpp.  Also tidied up the #include's for ptrQueue.[ch]pp to take
> advantage of the split.
> 
> Also, the gtest gc/shared/test_ptrQueueBufferAllocator.cpp is renamed to  
> gc/shared/test_bufferNodeAllocator.cpp, with some adjustments to includes and
> test naming.
> 
> Testing:
> mach5 tier1

Marked as reviewed by iwalulya (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/16506#pullrequestreview-1730648862

From wkemper at openjdk.org  Tue Nov 14 23:08:44 2023
From: wkemper at openjdk.org (William Kemper)
Date: Tue, 14 Nov 2023 23:08:44 GMT
Subject: RFR: 8320112 GenShen: Improve end of process report
Message-ID: <AHJbJGYjoUOIzTGwpo1jMnpIE9LsfWyVjeKk01txed0=.b3fc88ef-00e1-4f40-946a-8a4c52f82750@github.com>

When Shenandoah is shutdown, it logs a summary of its activity over the life of the process. This change adds percentages to the breakdown of the types and counts of cycles that executed. It also simplifies some of the logic around recording the various outcomes.

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

Commit messages:
 - Cleanup, count abbreviated concurrent separately from abbreviated degen
 - WIP: It builds (after merging)
 - Merge remote-tracking branch 'shenandoah/master' into improve-end-of-process-report
 - WIP: Add percentages, stop creating gc session when filling old regions

Changes: https://git.openjdk.org/shenandoah/pull/357/files
 Webrev: https://webrevs.openjdk.org/?repo=shenandoah&pr=357&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8320112
  Stats: 173 lines in 14 files changed: 41 ins; 54 del; 78 mod
  Patch: https://git.openjdk.org/shenandoah/pull/357.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah.git pull/357/head:pull/357

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

From wkemper at openjdk.org  Tue Nov 14 23:14:48 2023
From: wkemper at openjdk.org (William Kemper)
Date: Tue, 14 Nov 2023 23:14:48 GMT
Subject: RFR: 8320112 GenShen: Improve end of process report [v2]
In-Reply-To: <AHJbJGYjoUOIzTGwpo1jMnpIE9LsfWyVjeKk01txed0=.b3fc88ef-00e1-4f40-946a-8a4c52f82750@github.com>
References: <AHJbJGYjoUOIzTGwpo1jMnpIE9LsfWyVjeKk01txed0=.b3fc88ef-00e1-4f40-946a-8a4c52f82750@github.com>
Message-ID: <Mym1UN3bPeI1nJNBFXEhYyqhMqK0-ZlMo409liFWz1c=.05ba373e-7bdb-48b7-93b3-6dcc1945500a@github.com>

> When Shenandoah is shutdown, it logs a summary of its activity over the life of the process. This change adds percentages to the breakdown of the types and counts of cycles that executed. It also simplifies some of the logic around recording the various outcomes.

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

 - Reduce visibility of new methods
 - Fix accidental whitespace change

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

Changes:
  - all: https://git.openjdk.org/shenandoah/pull/357/files
  - new: https://git.openjdk.org/shenandoah/pull/357/files/3ea5e980..410c731d

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

  Stats: 24 lines in 4 files changed: 1 ins; 5 del; 18 mod
  Patch: https://git.openjdk.org/shenandoah/pull/357.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah.git pull/357/head:pull/357

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

From wkemper at openjdk.org  Wed Nov 15 00:22:29 2023
From: wkemper at openjdk.org (William Kemper)
Date: Wed, 15 Nov 2023 00:22:29 GMT
Subject: RFR: 8320119: GenShen: Correct misspellings of parsable
Message-ID: <CsNVoDB30eJXiFU7pt3gVRB9XhvD-VR7hr4vvITI910=.d6bef41c-b0b4-4938-ac93-9fc2c252e7d7@github.com>

There should be no 'e' in the word that describes something that is able to be parsed.

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

Commit messages:
 - Correct misspellings of parsable

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

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

From kbarrett at openjdk.org  Wed Nov 15 01:04:17 2023
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 15 Nov 2023 01:04:17 GMT
Subject: RFR: 8319439: Move BufferNode from PtrQueue files to new files
 [v2]
In-Reply-To: <zgfte_VjFQ56hJ2KGXvXtAhrjBaPvhPZ4t59eh-UN8U=.4beba8d0-dbe8-4582-93cb-b4a60b898bcf@github.com>
References: <zgfte_VjFQ56hJ2KGXvXtAhrjBaPvhPZ4t59eh-UN8U=.4beba8d0-dbe8-4582-93cb-b4a60b898bcf@github.com>
Message-ID: <5K288rm4MtykYCyHrEPdanQsctdzzPeFeTA8EvHUAUI=.c8bfc38a-f926-408f-a158-084b07864170@github.com>

> Please review this simple (trivial?) change that moves the BufferNode class
> from share/gc/shared/ptrQueue.[ch]pp to new files
> share/gc/shared/bufferNode.[ch]pp.  The code (as opposed to the surrounding
> boiler plate and #include's) was moved unchanged.
> 
> This led to adding #include's of the new header file to a bunch of other files
> (include what you use), in some cases eliminating the need to #include
> ptrQueue.hpp.  Also tidied up the #include's for ptrQueue.[ch]pp to take
> advantage of the split.
> 
> Also, the gtest gc/shared/test_ptrQueueBufferAllocator.cpp is renamed to  
> gc/shared/test_bufferNodeAllocator.cpp, with some adjustments to includes and
> test naming.
> 
> Testing:
> mach5 tier1

Kim Barrett has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits:

 - Merge branch 'master' into buffer-node
 - fixup gtest after rename
 - move test
 - move BufferNode to new files

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

Changes: https://git.openjdk.org/jdk/pull/16506/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16506&range=01
  Stats: 383 lines in 17 files changed: 223 ins; 152 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/16506.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16506/head:pull/16506

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

From kbarrett at openjdk.org  Wed Nov 15 01:11:49 2023
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 15 Nov 2023 01:11:49 GMT
Subject: RFR: 8319439: Move BufferNode from PtrQueue files to new files
 [v2]
In-Reply-To: <geFOSqiqFQaNgL5ojPLRWMy3gyETSybCpKeHdoOrO8k=.5fe9c8d9-fafe-4f74-b938-524b50d73507@github.com>
References: <zgfte_VjFQ56hJ2KGXvXtAhrjBaPvhPZ4t59eh-UN8U=.4beba8d0-dbe8-4582-93cb-b4a60b898bcf@github.com>
 <geFOSqiqFQaNgL5ojPLRWMy3gyETSybCpKeHdoOrO8k=.5fe9c8d9-fafe-4f74-b938-524b50d73507@github.com>
Message-ID: <rPrGwQNIL-FAbF240e67Jhthkdd0bwsUu12VG-5qM6o=.9fe1c502-ea2c-47b3-9bf0-16da63bc01a6@github.com>

On Tue, 7 Nov 2023 11:19:03 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 pull request now contains four commits:
>> 
>>  - Merge branch 'master' into buffer-node
>>  - fixup gtest after rename
>>  - move test
>>  - move BufferNode to new files
>
> lgtm

Thanks @tschatzl and @walulyai for reviews.

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

PR Comment: https://git.openjdk.org/jdk/pull/16506#issuecomment-1811638624

From kbarrett at openjdk.org  Wed Nov 15 01:11:52 2023
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 15 Nov 2023 01:11:52 GMT
Subject: Integrated: 8319439: Move BufferNode from PtrQueue files to new files
In-Reply-To: <zgfte_VjFQ56hJ2KGXvXtAhrjBaPvhPZ4t59eh-UN8U=.4beba8d0-dbe8-4582-93cb-b4a60b898bcf@github.com>
References: <zgfte_VjFQ56hJ2KGXvXtAhrjBaPvhPZ4t59eh-UN8U=.4beba8d0-dbe8-4582-93cb-b4a60b898bcf@github.com>
Message-ID: <5I5wDXCF5lDItoDQ594oZX8VrEEk1WDX-LvvkhJQphk=.d55c81a9-841b-49b7-8b05-51b8f18945f5@github.com>

On Sat, 4 Nov 2023 11:25:05 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this simple (trivial?) change that moves the BufferNode class
> from share/gc/shared/ptrQueue.[ch]pp to new files
> share/gc/shared/bufferNode.[ch]pp.  The code (as opposed to the surrounding
> boiler plate and #include's) was moved unchanged.
> 
> This led to adding #include's of the new header file to a bunch of other files
> (include what you use), in some cases eliminating the need to #include
> ptrQueue.hpp.  Also tidied up the #include's for ptrQueue.[ch]pp to take
> advantage of the split.
> 
> Also, the gtest gc/shared/test_ptrQueueBufferAllocator.cpp is renamed to  
> gc/shared/test_bufferNodeAllocator.cpp, with some adjustments to includes and
> test naming.
> 
> Testing:
> mach5 tier1

This pull request has now been integrated.

Changeset: 1e76ba0c
Author:    Kim Barrett <kbarrett at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1e76ba0cd0de38da6fc2b8147627496ee2f2837b
Stats:     383 lines in 17 files changed: 223 ins; 152 del; 8 mod

8319439: Move BufferNode from PtrQueue files to new files

Reviewed-by: tschatzl, iwalulya

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

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

From kdnilsen at openjdk.org  Wed Nov 15 01:50:05 2023
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Wed, 15 Nov 2023 01:50:05 GMT
Subject: RFR: 8320119: GenShen: Correct misspellings of parsable
In-Reply-To: <CsNVoDB30eJXiFU7pt3gVRB9XhvD-VR7hr4vvITI910=.d6bef41c-b0b4-4938-ac93-9fc2c252e7d7@github.com>
References: <CsNVoDB30eJXiFU7pt3gVRB9XhvD-VR7hr4vvITI910=.d6bef41c-b0b4-4938-ac93-9fc2c252e7d7@github.com>
Message-ID: <8lMaQT-bcUax53Rd9P66LkAlXDee2IhXbUjB32eMjus=.ed897f82-e240-4588-aaca-010b3c249b2f@github.com>

On Wed, 15 Nov 2023 00:15:43 GMT, William Kemper <wkemper at openjdk.org> wrote:

> There should be no 'e' in the word that describes something that is able to be parsed.

Marked as reviewed by kdnilsen (Committer).

Not sure it is necessary to change spelling: https://en.wiktionary.org/wiki/parseable

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

PR Review: https://git.openjdk.org/shenandoah/pull/358#pullrequestreview-1731097975
PR Comment: https://git.openjdk.org/shenandoah/pull/358#issuecomment-1811670146

From kdnilsen at openjdk.org  Wed Nov 15 01:59:11 2023
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Wed, 15 Nov 2023 01:59:11 GMT
Subject: RFR: 8320112 GenShen: Improve end of process report [v2]
In-Reply-To: <Mym1UN3bPeI1nJNBFXEhYyqhMqK0-ZlMo409liFWz1c=.05ba373e-7bdb-48b7-93b3-6dcc1945500a@github.com>
References: <AHJbJGYjoUOIzTGwpo1jMnpIE9LsfWyVjeKk01txed0=.b3fc88ef-00e1-4f40-946a-8a4c52f82750@github.com>
 <Mym1UN3bPeI1nJNBFXEhYyqhMqK0-ZlMo409liFWz1c=.05ba373e-7bdb-48b7-93b3-6dcc1945500a@github.com>
Message-ID: <mX-T3PVOGr0u9Lu_7KVuPMFCQjfkLb6KjsV9gv2JPh4=.03fa500d-3e6f-4514-bbe0-2ac37c68398c@github.com>

On Tue, 14 Nov 2023 23:14:48 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> When Shenandoah is shutdown, it logs a summary of its activity over the life of the process. This change adds percentages to the breakdown of the types and counts of cycles that executed. It also simplifies some of the logic around recording the various outcomes.
>
> William Kemper has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Reduce visibility of new methods
>  - Fix accidental whitespace change

I haven't digested all the control paths.  Some of the changes make me a bit nervous.  When degen young "upgrades to full", we have special handling.  For example, we update the live-at-end-of-last-old-mark variable, and we reset the count of consecutive degenerated cycles.  Do these changes preserve both of those behaviors?

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

PR Review: https://git.openjdk.org/shenandoah/pull/357#pullrequestreview-1731105463

From ysr at openjdk.org  Wed Nov 15 07:23:10 2023
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Wed, 15 Nov 2023 07:23:10 GMT
Subject: RFR: 8320119: GenShen: Correct misspellings of parsable
In-Reply-To: <CsNVoDB30eJXiFU7pt3gVRB9XhvD-VR7hr4vvITI910=.d6bef41c-b0b4-4938-ac93-9fc2c252e7d7@github.com>
References: <CsNVoDB30eJXiFU7pt3gVRB9XhvD-VR7hr4vvITI910=.d6bef41c-b0b4-4938-ac93-9fc2c252e7d7@github.com>
Message-ID: <onG3RjQU0ECo-XB-QLyXcYDuws6b7lAuXl3U7KHUzo0=.9f00b2f9-57b7-4e80-bcac-5b6add9811b8@github.com>

On Wed, 15 Nov 2023 00:15:43 GMT, William Kemper <wkemper at openjdk.org> wrote:

> There should be no 'e' in the word that describes something that is able to be parsed.

Marked as reviewed by ysr (Committer).

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

PR Review: https://git.openjdk.org/shenandoah/pull/358#pullrequestreview-1731384054

From ysr at openjdk.org  Wed Nov 15 17:21:27 2023
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Wed, 15 Nov 2023 17:21:27 GMT
Subject: RFR: 8320119: GenShen: Correct misspellings of parsable
In-Reply-To: <8lMaQT-bcUax53Rd9P66LkAlXDee2IhXbUjB32eMjus=.ed897f82-e240-4588-aaca-010b3c249b2f@github.com>
References: <CsNVoDB30eJXiFU7pt3gVRB9XhvD-VR7hr4vvITI910=.d6bef41c-b0b4-4938-ac93-9fc2c252e7d7@github.com>
 <8lMaQT-bcUax53Rd9P66LkAlXDee2IhXbUjB32eMjus=.ed897f82-e240-4588-aaca-010b3c249b2f@github.com>
Message-ID: <f_j1OTXv_6QMJtCPVkkGURkXZ8205TtaSGYJBiD8Gz0=.6b47800d-c26e-4f93-9279-692d7f34c3fc@github.com>

On Wed, 15 Nov 2023 01:47:37 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

> Not sure it is necessary to change spelling: https://en.wiktionary.org/wiki/parseable

That's interesting and informative! I didn't know that.

Still, may be the slight harmonizing towards the more common spelling won't really hurt, I think:

% find . -type f -name "*pp" | xargs grep -i parseable | wc -l 
21

% find . -type f -name "*pp" | xargs grep -i parsable | wc -l 
123



Although to your point, the work will not likely ever be complete: :-)


% find . -type f -name "*.java" | xargs grep -i parsable | wc -l
268

% find . -type f -name "*.java" | xargs grep -i parseable | wc -l
91

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

PR Comment: https://git.openjdk.org/shenandoah/pull/358#issuecomment-1812947690

From wkemper at openjdk.org  Wed Nov 15 18:16:15 2023
From: wkemper at openjdk.org (William Kemper)
Date: Wed, 15 Nov 2023 18:16:15 GMT
Subject: RFR: 8320119: GenShen: Correct misspellings of parsable
In-Reply-To: <CsNVoDB30eJXiFU7pt3gVRB9XhvD-VR7hr4vvITI910=.d6bef41c-b0b4-4938-ac93-9fc2c252e7d7@github.com>
References: <CsNVoDB30eJXiFU7pt3gVRB9XhvD-VR7hr4vvITI910=.d6bef41c-b0b4-4938-ac93-9fc2c252e7d7@github.com>
Message-ID: <hq5ugKJuc8gpBwyvFSrrHLPpXJcj3w_TNZKGL6xOpJY=.4a40ecd1-5071-4c44-af50-4f1afa72f477@github.com>

On Wed, 15 Nov 2023 00:15:43 GMT, William Kemper <wkemper at openjdk.org> wrote:

> There should be no 'e' in the word that describes something that is able to be parsed.

Well, they both look wrong to me ;) I'm making the change for better consistency with the rest of the code base.

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

PR Comment: https://git.openjdk.org/shenandoah/pull/358#issuecomment-1813021461

From wkemper at openjdk.org  Wed Nov 15 18:16:15 2023
From: wkemper at openjdk.org (William Kemper)
Date: Wed, 15 Nov 2023 18:16:15 GMT
Subject: Integrated: 8320119: GenShen: Correct misspellings of parsable
In-Reply-To: <CsNVoDB30eJXiFU7pt3gVRB9XhvD-VR7hr4vvITI910=.d6bef41c-b0b4-4938-ac93-9fc2c252e7d7@github.com>
References: <CsNVoDB30eJXiFU7pt3gVRB9XhvD-VR7hr4vvITI910=.d6bef41c-b0b4-4938-ac93-9fc2c252e7d7@github.com>
Message-ID: <_lHMuG6kg5ZUKA10AYyk_lHDN-R5LkOKUTCoNfyTgcU=.786e8470-04ab-4640-b2b3-1584f35fbd70@github.com>

On Wed, 15 Nov 2023 00:15:43 GMT, William Kemper <wkemper at openjdk.org> wrote:

> There should be no 'e' in the word that describes something that is able to be parsed.

This pull request has now been integrated.

Changeset: fcc99ad2
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.org/shenandoah/commit/fcc99ad2f63219bf1fa721712b081000dd12bec6
Stats:     7 lines in 6 files changed: 0 ins; 0 del; 7 mod

8320119: GenShen: Correct misspellings of parsable

Reviewed-by: kdnilsen, ysr

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

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

From wkemper at openjdk.org  Wed Nov 15 18:28:13 2023
From: wkemper at openjdk.org (William Kemper)
Date: Wed, 15 Nov 2023 18:28:13 GMT
Subject: RFR: 8320112 GenShen: Improve end of process report [v2]
In-Reply-To: <Mym1UN3bPeI1nJNBFXEhYyqhMqK0-ZlMo409liFWz1c=.05ba373e-7bdb-48b7-93b3-6dcc1945500a@github.com>
References: <AHJbJGYjoUOIzTGwpo1jMnpIE9LsfWyVjeKk01txed0=.b3fc88ef-00e1-4f40-946a-8a4c52f82750@github.com>
 <Mym1UN3bPeI1nJNBFXEhYyqhMqK0-ZlMo409liFWz1c=.05ba373e-7bdb-48b7-93b3-6dcc1945500a@github.com>
Message-ID: <KmVvfB_r-nJ31faHqncy5t35GF0ZJy6nvrx-vWF085E=.862c00a6-29b9-49ce-9d93-8c90cec72f85@github.com>

On Tue, 14 Nov 2023 23:14:48 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> When Shenandoah is shutdown, it logs a summary of its activity over the life of the process. This change adds percentages to the breakdown of the types and counts of cycles that executed. It also simplifies some of the logic around recording the various outcomes.
>
> William Kemper has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Reduce visibility of new methods
>  - Fix accidental whitespace change

src/hotspot/share/gc/shenandoah/shenandoahControlThread.cpp line 805:

> 803:     assert(_degen_generation->is_young(), "Expected degenerated young cycle, if not global.");
> 804:     ShenandoahOldGeneration* old = heap->old_generation();
> 805:     if (old->state() == ShenandoahOldGeneration::BOOTSTRAPPING) {

An assert has been added in `ShenandoahFullGC` to be certain the old generation is put in the `WAITING_FOR_BOOTSTRAP` state after a Full GC>

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

PR Review Comment: https://git.openjdk.org/shenandoah/pull/357#discussion_r1394614574

From wkemper at openjdk.org  Wed Nov 15 18:34:31 2023
From: wkemper at openjdk.org (William Kemper)
Date: Wed, 15 Nov 2023 18:34:31 GMT
Subject: RFR: 8320112 GenShen: Improve end of process report [v2]
In-Reply-To: <Mym1UN3bPeI1nJNBFXEhYyqhMqK0-ZlMo409liFWz1c=.05ba373e-7bdb-48b7-93b3-6dcc1945500a@github.com>
References: <AHJbJGYjoUOIzTGwpo1jMnpIE9LsfWyVjeKk01txed0=.b3fc88ef-00e1-4f40-946a-8a4c52f82750@github.com>
 <Mym1UN3bPeI1nJNBFXEhYyqhMqK0-ZlMo409liFWz1c=.05ba373e-7bdb-48b7-93b3-6dcc1945500a@github.com>
Message-ID: <P356H1tg4_9u26Vk2-YpFseVz5PHZel35RxfSSQhGNo=.7c434a4b-a482-49f6-a1ad-556dd8d1706e@github.com>

On Tue, 14 Nov 2023 23:14:48 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> When Shenandoah is shutdown, it logs a summary of its activity over the life of the process. This change adds percentages to the breakdown of the types and counts of cycles that executed. It also simplifies some of the logic around recording the various outcomes.
>
> William Kemper has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Reduce visibility of new methods
>  - Fix accidental whitespace change

We had special handling for upgraded degen cycles because the handling was in the control thread's `service_stw_degenerated_cycle` function that didn't have direct knowledge of full GCs the same way `service_stw_full_cycle` did.  With this change the special handling for upgraded cycles and the handling for regular full GCs has been consolidated in `ShenandoahFullGC`. 

The `live-at-end-of-last-old-mark` is updated at the end of a full GC (no change here) and at the end of old marking (no change here either). The number of consecutive degenerated cycles is reset whenever a full GC or a concurrent GC completes.  

I also discovered that upgraded degen cycles were not being counted as full GCs - which is perhaps a fix we should make upstream?

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

PR Comment: https://git.openjdk.org/shenandoah/pull/357#issuecomment-1813047868

From duke at openjdk.org  Thu Nov 16 12:18:50 2023
From: duke at openjdk.org (duke)
Date: Thu, 16 Nov 2023 12:18:50 GMT
Subject: Withdrawn: 8305895: Implementation: JEP 450: Compact Object Headers
 (Experimental)
In-Reply-To: <v2emO_lbVeQr6FArSo4y6krhG5b0pzaX9GPGo0A_A5M=.831590ab-3f21-454b-b100-655d44cc3b60@github.com>
References: <v2emO_lbVeQr6FArSo4y6krhG5b0pzaX9GPGo0A_A5M=.831590ab-3f21-454b-b100-655d44cc3b60@github.com>
Message-ID: <r5pIlVj5mhPnMhr0eABk-CbhaniN8Nzy_NrDwgE39Vo=.242c4a1b-dd34-4879-b75a-6e94d372eb16@github.com>

On Fri, 12 May 2023 17:27:25 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> This is the main body of the JEP 450: Compact Object Headers (Experimental).
> 
> Main changes:
>  - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag.
>  - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are building on #10907, #13582 and #13779 to protect the relevant (upper 32) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word, and dealing with (monitor-)locked objects. When the object is monitor-locked, we load the displaced mark-word from the monitor, and load the compressed Klass* from there. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded, and/or reach through to the monitor when the object is locked by a monitor.
>  - The identity hash-code is narrowed to 25 bits.
>  - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16).
>  - Arrays will can now store their length at offset 8. Due to alignment restrictions, array elements will still start at offset 16. #11044 will resolve that restriction and allow array elements to start at offset 12 (except for long, double and uncompressed oops, which are still required to start at an element-aligned offset).
>  - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders.
> 
> Testing:
>  (+UseCompactObjectHeaders tests are run with the flag hard-patched into the build, to also catch @flagless tests, and to avoid mismatches with CDS - see above.)
>  - [x] tier1 (x86_64)
>  - [x] tier2 (x86_64)
>  - [x] tier3 (x86_64)
>  - [ ] tier4 (x86_64)
>  - [x] tier1 (aarch64)
>  - [x] tier2 (aarch64)
>  - [x] tier3 (aarch64)
>  - [ ] tier4 (aarch64)
>  - [ ] tier1 (x86_64) +UseCompactObjectHeaders
>  - [ ] tier2 (x86_64) +UseCompactObjectHeaders
>  - [ ] tier3 (x86_64) +UseCompactObjectHeaders
>  - [ ] tier4 (x86_64) +UseCompactObjectHeaders
>  - [ ] tier1 (aarch64) +UseCompactObjectHeaders
>  - [ ] tier2 (aarch64) +UseCompactObjectHeaders
>  - [ ] tier3 (aarch64) +UseCompactObjectHeaders
>  - [ ] tier4 (aarch64) +UseCompactObjectHeaders

This pull request has been closed without being integrated.

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

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

From wkemper at openjdk.org  Thu Nov 16 14:16:44 2023
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 16 Nov 2023 14:16:44 GMT
Subject: RFR: Merge openjdk/jdk:master
Message-ID: <DBv7q5uKkUDQqR9SyymCLXZOlAyWQKln9lfTVFQewAM=.490048f1-4cd8-40d4-bd25-ce77562f8335@github.com>

Merges tag jdk-22+24

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

Commit messages:
 - 8301997: Move method resolution information out of the cpCache
 - 8319986: Invalid/inconsistent description and example for DateFormat
 - 8320130: Problemlist 2 vmTestbase/nsk/jdi/StepRequest/addClassFilter_rt tests with Xcomp
 - 8319187: Add three eMudhra emSign roots
 - 8318219: RISC-V: C2 ExpandBits
 - 8320053: GHA: Cross-compile gtest code
 - 8319966: AIX: expected [[0:i4]] but found [[0:I4]] after JDK-8319882
 - 8318671: Potential uninitialized uintx value after JDK-8317683
 - 8319781: RISC-V: Refactor UseRVV related checks
 - 8313672: C2: PhaseCCP does not correctly track analysis dependencies involving shift, convert, and mask
 - ... and 79 more: https://git.openjdk.org/shenandoah/compare/8555e0f6...ffa35d8c

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

Changes: https://git.openjdk.org/shenandoah/pull/360/files
  Stats: 619015 lines in 974 files changed: 82836 ins; 475201 del; 60978 mod
  Patch: https://git.openjdk.org/shenandoah/pull/360.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah.git pull/360/head:pull/360

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

From kdnilsen at openjdk.org  Fri Nov 17 17:21:26 2023
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Fri, 17 Nov 2023 17:21:26 GMT
Subject: RFR: JDK-8320336: GenShen: Reduce proactive humongous defragmentation
 efforts
Message-ID: <t4RcJHkwcMqSIwVAz6aiqYjppqbRqUNctcNWc5uaCkY=.a9eb5e6c-9e72-46c6-b9c4-9f9321a2d2e4@github.com>

Only trigger defragmentation of old-gen memory if JVM is configured to reserve a certain amount of the heap to support humongous objects.  Even when the JVM is so configured, be slightly less aggressive in triggering defragmentation of old-gen memory.

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

Commit messages:
 - Make old-gen fragmentation triggers less sensitive

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

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

From kdnilsen at openjdk.org  Fri Nov 17 17:41:13 2023
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Fri, 17 Nov 2023 17:41:13 GMT
Subject: RFR: 8320112 GenShen: Improve end of process report [v2]
In-Reply-To: <Mym1UN3bPeI1nJNBFXEhYyqhMqK0-ZlMo409liFWz1c=.05ba373e-7bdb-48b7-93b3-6dcc1945500a@github.com>
References: <AHJbJGYjoUOIzTGwpo1jMnpIE9LsfWyVjeKk01txed0=.b3fc88ef-00e1-4f40-946a-8a4c52f82750@github.com>
 <Mym1UN3bPeI1nJNBFXEhYyqhMqK0-ZlMo409liFWz1c=.05ba373e-7bdb-48b7-93b3-6dcc1945500a@github.com>
Message-ID: <X_rIGkfipku-dv8tNfkzS0NqvmkxXYBARSKxYWf-Dyg=.c29d40f7-66e2-43c8-b47b-f579879e4901@github.com>

On Tue, 14 Nov 2023 23:14:48 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> When Shenandoah is shutdown, it logs a summary of its activity over the life of the process. This change adds percentages to the breakdown of the types and counts of cycles that executed. It also simplifies some of the logic around recording the various outcomes.
>
> William Kemper has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Reduce visibility of new methods
>  - Fix accidental whitespace change

Thanks for clarifying my confusion, and thanks for these improvements.

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

Marked as reviewed by kdnilsen (Committer).

PR Review: https://git.openjdk.org/shenandoah/pull/357#pullrequestreview-1737556582

From wkemper at openjdk.org  Fri Nov 17 22:35:12 2023
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 17 Nov 2023 22:35:12 GMT
Subject: RFR: JDK-8320336: GenShen: Reduce proactive humongous
 defragmentation efforts
In-Reply-To: <t4RcJHkwcMqSIwVAz6aiqYjppqbRqUNctcNWc5uaCkY=.a9eb5e6c-9e72-46c6-b9c4-9f9321a2d2e4@github.com>
References: <t4RcJHkwcMqSIwVAz6aiqYjppqbRqUNctcNWc5uaCkY=.a9eb5e6c-9e72-46c6-b9c4-9f9321a2d2e4@github.com>
Message-ID: <gwYc9q_-6Alxxs_SrzHk7bHgyw3wOli7gRxUUVQ1HDs=.bb3468fd-1790-4666-b6c0-70ead55c9790@github.com>

On Fri, 17 Nov 2023 17:15:32 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

> Only trigger defragmentation of old-gen memory if JVM is configured to reserve a certain amount of the heap to support humongous objects.  Even when the JVM is so configured, be slightly less aggressive in triggering defragmentation of old-gen memory.

Looks good to me.

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

Marked as reviewed by wkemper (Committer).

PR Review: https://git.openjdk.org/shenandoah/pull/361#pullrequestreview-1738041538

From wkemper at openjdk.org  Fri Nov 17 22:38:04 2023
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 17 Nov 2023 22:38:04 GMT
Subject: Integrated: 8320112 GenShen: Improve end of process report
In-Reply-To: <AHJbJGYjoUOIzTGwpo1jMnpIE9LsfWyVjeKk01txed0=.b3fc88ef-00e1-4f40-946a-8a4c52f82750@github.com>
References: <AHJbJGYjoUOIzTGwpo1jMnpIE9LsfWyVjeKk01txed0=.b3fc88ef-00e1-4f40-946a-8a4c52f82750@github.com>
Message-ID: <rSAq66okpPGSjyjaT7FBdWCeccsz248eh2AG_mJep5w=.74427fba-a5d9-43d1-8663-c4ecef2af0fe@github.com>

On Tue, 14 Nov 2023 23:03:09 GMT, William Kemper <wkemper at openjdk.org> wrote:

> When Shenandoah is shutdown, it logs a summary of its activity over the life of the process. This change adds percentages to the breakdown of the types and counts of cycles that executed. It also simplifies some of the logic around recording the various outcomes.

This pull request has now been integrated.

Changeset: d80a17d5
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.org/shenandoah/commit/d80a17d506836acc677ae4e8105d60eb7f6f6fa0
Stats:     159 lines in 14 files changed: 41 ins; 58 del; 60 mod

8320112: GenShen: Improve end of process report

Reviewed-by: kdnilsen

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

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

From wkemper at openjdk.org  Fri Nov 17 22:43:02 2023
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 17 Nov 2023 22:43:02 GMT
Subject: RFR: Merge openjdk/jdk:master [v2]
In-Reply-To: <DBv7q5uKkUDQqR9SyymCLXZOlAyWQKln9lfTVFQewAM=.490048f1-4cd8-40d4-bd25-ce77562f8335@github.com>
References: <DBv7q5uKkUDQqR9SyymCLXZOlAyWQKln9lfTVFQewAM=.490048f1-4cd8-40d4-bd25-ce77562f8335@github.com>
Message-ID: <w86Vh4WTmIFzCO2-u3C6TLyzM-67icPtS8jLo58MNxo=.512e0349-a584-407f-88e2-4419d3eb6dfb@github.com>

> Merges tag jdk-22+24

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

 - Merge remote-tracking branch 'shenandoah/master' into merge-jdk-22+24
 - 8301997: Move method resolution information out of the cpCache
   
   Co-authored-by: Gui Cao <gcao at openjdk.org>
   Co-authored-by: Fei Yang <fyang at openjdk.org>
   Co-authored-by: Martin Doerr <mdoerr at openjdk.org>
   Co-authored-by: Amit Kumar <amitkumar at openjdk.org>
   Reviewed-by: coleenp, adinn, fparain
 - 8319986: Invalid/inconsistent description and example for DateFormat
   
   Reviewed-by: joehw, rriggs, jlu, iris, lancea
 - 8320130: Problemlist 2 vmTestbase/nsk/jdi/StepRequest/addClassFilter_rt tests with Xcomp
   
   Reviewed-by: cjplummer, dcubed
 - 8319187: Add three eMudhra emSign roots
   
   Reviewed-by: mullan
 - 8318219: RISC-V: C2 ExpandBits
   
   Reviewed-by: fyang
 - 8320053: GHA: Cross-compile gtest code
   
   Reviewed-by: ihse, stuefe
 - 8319966: AIX: expected [[0:i4]] but found [[0:I4]] after JDK-8319882
   
   Reviewed-by: mdoerr
 - 8318671: Potential uninitialized uintx value after JDK-8317683
   
   Reviewed-by: thartmann, shade
 - 8319781: RISC-V: Refactor UseRVV related checks
   
   Reviewed-by: rehn, fyang
 - ... and 80 more: https://git.openjdk.org/shenandoah/compare/d80a17d5...2db62747

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

Changes: https://git.openjdk.org/shenandoah/pull/360/files
 Webrev: https://webrevs.openjdk.org/?repo=shenandoah&pr=360&range=01
  Stats: 619015 lines in 974 files changed: 82836 ins; 475201 del; 60978 mod
  Patch: https://git.openjdk.org/shenandoah/pull/360.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah.git pull/360/head:pull/360

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

From wkemper at openjdk.org  Mon Nov 20 18:21:58 2023
From: wkemper at openjdk.org (William Kemper)
Date: Mon, 20 Nov 2023 18:21:58 GMT
Subject: Integrated: Merge openjdk/jdk:master
In-Reply-To: <DBv7q5uKkUDQqR9SyymCLXZOlAyWQKln9lfTVFQewAM=.490048f1-4cd8-40d4-bd25-ce77562f8335@github.com>
References: <DBv7q5uKkUDQqR9SyymCLXZOlAyWQKln9lfTVFQewAM=.490048f1-4cd8-40d4-bd25-ce77562f8335@github.com>
Message-ID: <w8mzkfK_Tci8kXx4CBwp_OmOCBlVM-JkKM_anSpsA78=.f7dfdf42-6d1b-437a-b196-039d4bddb401@github.com>

On Thu, 16 Nov 2023 14:09:58 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Merges tag jdk-22+24

This pull request has now been integrated.

Changeset: 22280c12
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.org/shenandoah/commit/22280c1228c51d10db19a89979bdd66001d34336
Stats:     619015 lines in 974 files changed: 82836 ins; 475201 del; 60978 mod

Merge

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

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

From ysr at openjdk.org  Mon Nov 20 23:39:48 2023
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Mon, 20 Nov 2023 23:39:48 GMT
Subject: RFR: JDK-8320336: GenShen: Reduce proactive humongous
 defragmentation efforts
In-Reply-To: <t4RcJHkwcMqSIwVAz6aiqYjppqbRqUNctcNWc5uaCkY=.a9eb5e6c-9e72-46c6-b9c4-9f9321a2d2e4@github.com>
References: <t4RcJHkwcMqSIwVAz6aiqYjppqbRqUNctcNWc5uaCkY=.a9eb5e6c-9e72-46c6-b9c4-9f9321a2d2e4@github.com>
Message-ID: <dXPW7SXNvRwDCcYanLjIaKRh9D-VG0BMfZfQYwAx2oM=.e8152615-cb93-490b-a05b-b5bf241f8263@github.com>

On Fri, 17 Nov 2023 17:15:32 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

> Only trigger defragmentation of old-gen memory if JVM is configured to reserve a certain amount of the heap to support humongous objects.  Even when the JVM is so configured, be slightly less aggressive in triggering defragmentation of old-gen memory.

Sorry for the delay. LGTM.

One question relating to the performance changes stemming from this fix:
- Effectively, it seems that the density/span based triggering is now disabled by default (because of the change at line 3129 and the default setting of humongous reserve at 0)
- Does this effectively win back the difference caused by the original change?
- However, were you to enable it, say by an appropriate positive value for the humongous reserve, does the less aggressive triggering result in a performance improvement?
- Are there any (rough) performance numbers, by chance, to share for the two changes separately?

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

Marked as reviewed by ysr (Committer).

PR Review: https://git.openjdk.org/shenandoah/pull/361#pullrequestreview-1740872293

From kdnilsen at openjdk.org  Tue Nov 21 00:51:04 2023
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Tue, 21 Nov 2023 00:51:04 GMT
Subject: Integrated: JDK-8320336: GenShen: Reduce proactive humongous
 defragmentation efforts
In-Reply-To: <t4RcJHkwcMqSIwVAz6aiqYjppqbRqUNctcNWc5uaCkY=.a9eb5e6c-9e72-46c6-b9c4-9f9321a2d2e4@github.com>
References: <t4RcJHkwcMqSIwVAz6aiqYjppqbRqUNctcNWc5uaCkY=.a9eb5e6c-9e72-46c6-b9c4-9f9321a2d2e4@github.com>
Message-ID: <2_Gmtt8rQYNaKaDRvA1kP7vG863MMAkug11Hhxw7_eQ=.995a8b46-31c2-402a-8054-652a26b27a83@github.com>

On Fri, 17 Nov 2023 17:15:32 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

> Only trigger defragmentation of old-gen memory if JVM is configured to reserve a certain amount of the heap to support humongous objects.  Even when the JVM is so configured, be slightly less aggressive in triggering defragmentation of old-gen memory.

This pull request has now been integrated.

Changeset: ff8d5313
Author:    Kelvin Nilsen <kdnilsen at openjdk.org>
URL:       https://git.openjdk.org/shenandoah/commit/ff8d5313b065e99176cd3b8b6ca247352dd22200
Stats:     12 lines in 1 file changed: 4 ins; 1 del; 7 mod

8320336: GenShen: Reduce proactive humongous defragmentation efforts

Reviewed-by: wkemper, ysr

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

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

From kdnilsen at openjdk.org  Tue Nov 21 00:51:02 2023
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Tue, 21 Nov 2023 00:51:02 GMT
Subject: RFR: JDK-8320336: GenShen: Reduce proactive humongous
 defragmentation efforts
In-Reply-To: <t4RcJHkwcMqSIwVAz6aiqYjppqbRqUNctcNWc5uaCkY=.a9eb5e6c-9e72-46c6-b9c4-9f9321a2d2e4@github.com>
References: <t4RcJHkwcMqSIwVAz6aiqYjppqbRqUNctcNWc5uaCkY=.a9eb5e6c-9e72-46c6-b9c4-9f9321a2d2e4@github.com>
Message-ID: <03WswFyuF3J8zUqQiKQzMOhWCMnkP3qPy3P1cY-gcZ8=.5d368a13-83e8-46a1-bede-5fe357cdf54d@github.com>

On Fri, 17 Nov 2023 17:15:32 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

> Only trigger defragmentation of old-gen memory if JVM is configured to reserve a certain amount of the heap to support humongous objects.  Even when the JVM is so configured, be slightly less aggressive in triggering defragmentation of old-gen memory.

The trigger is disabled by default.  Humongous fragmentation is one of the issues that results in very high variability in performance on some workloads.  Humongous memory gets fragmented when humongous objects happen to be allocated in "the middle" of the heap instead of getting allocated at the start of the heap.  It is difficult to predict or even contrive programs that will cause this to happen.  But the typical scenario is:

1. We are operating near the "cliff's edge" so young gen consumes all of the available heap.
2. Some number of young-gen regions residing near the bottom of heap which are not necessarily contiguous are promoted in place rather than getting compacted.
3. Free regions are now scattered between these promoted-in-place heap regions, and we have no sufficiently long run of consecutive free regions to satisfy an allocation request.

With this change: We will still endeavor to defragment the old-gen memory whenever we perform a concurrent marking effort.  Concurrent marking efforts are now triggered by guaranteed interval or by growth since previous old mark.

If a service desires to keep memory defragmented because they expect frequent allocation of humongous objects, they would be wise to set -XX:ShenandoahGenerationalHumongousReserve=5 (or any value grater than 0).

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

PR Comment: https://git.openjdk.org/shenandoah/pull/361#issuecomment-1820037408

From dholmes at openjdk.org  Tue Nov 21 05:24:33 2023
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 21 Nov 2023 05:24:33 GMT
Subject: RFR: 8318776: Require supports_cx8 to always be true [v4]
In-Reply-To: <oIBgmqm_tcBgAzRlR-vLLnW9ky7pTgNwKy0463UZw5Q=.87894004-0e8a-4d75-bb8f-be6602a09a97@github.com>
References: <oIBgmqm_tcBgAzRlR-vLLnW9ky7pTgNwKy0463UZw5Q=.87894004-0e8a-4d75-bb8f-be6602a09a97@github.com>
Message-ID: <J1TWPnz-iQ3n-68dY3YgbuH6Qa2bd3mZKCULSHIVJL4=.497d4a3a-5682-4410-8b16-fc2d426f5231@github.com>

> As discussed in JBS all platforms (some tweaks to Zero are in progress) actually do support `cx8` i.e. 64-bit compare-and-exchange, so we can strip out the locked-based alternatives to using it and just add a guarantee that it is true at runtime. And all platforms except some ARM variants set `SUPPORTS_NATIVE_CX8`, so we can greatly simplify things. Summary of changes:
> - `_supports_cx8` field is only needed when `SUPPORTS_NATIVE_CX8` is not defined
> - Assertions for `supports_cx8()` are removed
> - Compiler predicates requiring `supports_cx8()` are removed
> - Access backend is greatly simplified without the need for lock-based alternative
> - `java.util.concurrent.AtomicLongFieldUpdater` is simplified without the need for a lock-based alternative
> 
> I did consider moving all the ARM `kuser_helper` related code to be only defined when `SUPPORTS_NATIVE_CX8` is not defined, but there was a theoretical risk this could change the behaviour if ARMv7 binaries were run on other ARM CPU's. I added a note to that effect in vm_version_linux_arm32.cpp so the ARM port maintainers could clean this up further if desired.
> 
> Testing:
> - All Oracle tiers 1-5 builds (which includes an ARMv7 build)
> - GHA builds/tests
> - Oracle tiers 1-3 sanity testing
> 
> Zero changes coming in via [JDK-8319777](https://bugs.openjdk.org/browse/JDK-8319777) will be merged when they arrive.
> 
> Thanks.

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

  Remove unnecessary includes of vm_version.hpp.
  Fix copyright years.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16625/files
  - new: https://git.openjdk.org/jdk/pull/16625/files/65871144..597cef53

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

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

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

From eosterlund at openjdk.org  Tue Nov 21 06:06:11 2023
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Tue, 21 Nov 2023 06:06:11 GMT
Subject: RFR: 8318776: Require supports_cx8 to always be true [v4]
In-Reply-To: <J1TWPnz-iQ3n-68dY3YgbuH6Qa2bd3mZKCULSHIVJL4=.497d4a3a-5682-4410-8b16-fc2d426f5231@github.com>
References: <oIBgmqm_tcBgAzRlR-vLLnW9ky7pTgNwKy0463UZw5Q=.87894004-0e8a-4d75-bb8f-be6602a09a97@github.com>
 <J1TWPnz-iQ3n-68dY3YgbuH6Qa2bd3mZKCULSHIVJL4=.497d4a3a-5682-4410-8b16-fc2d426f5231@github.com>
Message-ID: <S_bLfuPh3YULfZYwOmlX4rmxR2u6xEoaeNVZz2ZHLVE=.595a04db-9de3-45e8-bdf1-b2fbb784802b@github.com>

On Tue, 21 Nov 2023 05:24:33 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> As discussed in JBS all platforms (some tweaks to Zero are in progress) actually do support `cx8` i.e. 64-bit compare-and-exchange, so we can strip out the locked-based alternatives to using it and just add a guarantee that it is true at runtime. And all platforms except some ARM variants set `SUPPORTS_NATIVE_CX8`, so we can greatly simplify things. Summary of changes:
>> - `_supports_cx8` field is only needed when `SUPPORTS_NATIVE_CX8` is not defined
>> - Assertions for `supports_cx8()` are removed
>> - Compiler predicates requiring `supports_cx8()` are removed
>> - Access backend is greatly simplified without the need for lock-based alternative
>> - `java.util.concurrent.AtomicLongFieldUpdater` is simplified without the need for a lock-based alternative
>> 
>> I did consider moving all the ARM `kuser_helper` related code to be only defined when `SUPPORTS_NATIVE_CX8` is not defined, but there was a theoretical risk this could change the behaviour if ARMv7 binaries were run on other ARM CPU's. I added a note to that effect in vm_version_linux_arm32.cpp so the ARM port maintainers could clean this up further if desired.
>> 
>> Testing:
>> - All Oracle tiers 1-5 builds (which includes an ARMv7 build)
>> - GHA builds/tests
>> - Oracle tiers 1-3 sanity testing
>> 
>> Zero changes coming in via [JDK-8319777](https://bugs.openjdk.org/browse/JDK-8319777) will be merged when they arrive.
>> 
>> Thanks.
>
> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove unnecessary includes of vm_version.hpp.
>   Fix copyright years.

This looks great!

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

Marked as reviewed by eosterlund (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16625#pullrequestreview-1741175703

From dholmes at openjdk.org  Tue Nov 21 11:00:11 2023
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 21 Nov 2023 11:00:11 GMT
Subject: RFR: 8318776: Require supports_cx8 to always be true [v4]
In-Reply-To: <S_bLfuPh3YULfZYwOmlX4rmxR2u6xEoaeNVZz2ZHLVE=.595a04db-9de3-45e8-bdf1-b2fbb784802b@github.com>
References: <oIBgmqm_tcBgAzRlR-vLLnW9ky7pTgNwKy0463UZw5Q=.87894004-0e8a-4d75-bb8f-be6602a09a97@github.com>
 <J1TWPnz-iQ3n-68dY3YgbuH6Qa2bd3mZKCULSHIVJL4=.497d4a3a-5682-4410-8b16-fc2d426f5231@github.com>
 <S_bLfuPh3YULfZYwOmlX4rmxR2u6xEoaeNVZz2ZHLVE=.595a04db-9de3-45e8-bdf1-b2fbb784802b@github.com>
Message-ID: <lvn2tjS4vQ8xd36TSJ0we1yBU_NoeTR-OiwgEGh_WW8=.29a0d99a-cdd7-4dfa-8fc2-15a1430e41cc@github.com>

On Tue, 21 Nov 2023 06:03:38 GMT, Erik ?sterlund <eosterlund at openjdk.org> wrote:

>> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove unnecessary includes of vm_version.hpp.
>>   Fix copyright years.
>
> This looks great!

Thanks for the review @fisk ! I have to wait for a few Zero related PRs to get integrated then re-merge, before I can integrate.

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

PR Comment: https://git.openjdk.org/jdk/pull/16625#issuecomment-1820689855

From tschatzl at openjdk.org  Tue Nov 21 16:09:29 2023
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Tue, 21 Nov 2023 16:09:29 GMT
Subject: RFR: 8317809: Insertion of free code blobs into code cache can be very
 slow during class unloading
Message-ID: <_dcFF70_w7IXSjb6w-HuHCBkPyS3a6NlzejtqdfdYnM=.74e0f9df-eca3-49b0-be68-2d5824c16003@github.com>

Insert code blobs in a sorted fashion to exploit the finger-optimization when adding, making this procedure O(n) instead of O(n^2)

Introduces a globally available ClassUnloadingContext that contains common methods pertaining to class and code unloading. GCs may use it to efficiently manage unlinked class loader datas and nmethods to allow use of common methods (unlink/merge).

The steps typically are registering a new to be unlinked CLD/nmethod, and then purge its memory later. STW collectors perform this work in one big chunk taking the CodeCache_lock, for the entire duration, while concurrent collectors lock/unlock for every insertion to allow for concurrent users for the lock to progress.

Some care has been taken to stay consistent with an "unloading = unlinking + purge" scheme; however particularly the existing CLD handling API (still) mixes unlinking and purging in its CLD::unload() call. To simplify this change that is mostly geared towards separating nmethod unlinking from purging, to make code blob freeing O(n) instead of O(n^2).

Upcoming changes will
* separate nmethod unregistering from nmethod purging to allow doing that in bulk (for the STW collectors); that can significantly reduce code purging time for the STW collectors.
* better name the second stage of unlinking (called "cleaning" throughout, e.g. the work done in `G1CollectedHeap::complete_cleaning`)
* untangle CLD unlinking and what's called "cleaning" now to allow moving more stuff into the second unlinking stage for better parallelism
* G1: move some significant tasks from the remark pause to concurrent (unregistering nmethods, freeing code blobs and cld/metaspace purging)
* Maybe move Serial/Parallel GC metaspace purging closer to other unlinking/purging code to keep things local and allow easier logging.

Please also first looking into the (small) PR this depends on.

The crash on linux-x86 is fixed by PR#16766 which I split out for quicker reviews.

Testing: tier1-7

Thanks,
  Thomas

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

Depends on: https://git.openjdk.org/jdk/pull/16733

Commit messages:
 - 8317809 Insert code blobs in a sorted fashion to exploit the finger-optimization when adding, making this procedure O(n) instead of O(n^2)

Changes: https://git.openjdk.org/jdk/pull/16759/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16759&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8317809
  Stats: 495 lines in 28 files changed: 368 ins; 83 del; 44 mod
  Patch: https://git.openjdk.org/jdk/pull/16759.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16759/head:pull/16759

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

From shade at openjdk.org  Tue Nov 21 17:01:12 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 21 Nov 2023 17:01:12 GMT
Subject: RFR: 8318776: Require supports_cx8 to always be true [v4]
In-Reply-To: <S_bLfuPh3YULfZYwOmlX4rmxR2u6xEoaeNVZz2ZHLVE=.595a04db-9de3-45e8-bdf1-b2fbb784802b@github.com>
References: <oIBgmqm_tcBgAzRlR-vLLnW9ky7pTgNwKy0463UZw5Q=.87894004-0e8a-4d75-bb8f-be6602a09a97@github.com>
 <J1TWPnz-iQ3n-68dY3YgbuH6Qa2bd3mZKCULSHIVJL4=.497d4a3a-5682-4410-8b16-fc2d426f5231@github.com>
 <S_bLfuPh3YULfZYwOmlX4rmxR2u6xEoaeNVZz2ZHLVE=.595a04db-9de3-45e8-bdf1-b2fbb784802b@github.com>
Message-ID: <xxzHExpfg7dRBWuPDSJZpTYVAGtbsiKzfHbtkJuPve8=.b7493d33-e12e-4b6c-8e2f-37e5e9750c77@github.com>

On Tue, 21 Nov 2023 06:03:38 GMT, Erik ?sterlund <eosterlund at openjdk.org> wrote:

>> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove unnecessary includes of vm_version.hpp.
>>   Fix copyright years.
>
> This looks great!

> Thanks for the review @fisk ! I have to wait for a few Zero related PRs to get integrated then re-merge, before I can integrate.

Zero patches were pushed, please re-merge. I checked current mainline works well with at least linux-arm-zero-fastdebug, and I would like to re-test it with this patch.

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

PR Comment: https://git.openjdk.org/jdk/pull/16625#issuecomment-1821309132

From cslucas at openjdk.org  Tue Nov 21 17:58:35 2023
From: cslucas at openjdk.org (Cesar Soares Lucas)
Date: Tue, 21 Nov 2023 17:58:35 GMT
Subject: RFR: JDK-8241503: C2: Share MacroAssembler between mach nodes
 during code emission [v2]
In-Reply-To: <ExCrwPns55nw2P62UI3vzSVTmFCh3dzJq7u3Kugp9EA=.c20cd86c-2c16-4869-ba7f-76f2a53821d0@github.com>
References: <ExCrwPns55nw2P62UI3vzSVTmFCh3dzJq7u3Kugp9EA=.c20cd86c-2c16-4869-ba7f-76f2a53821d0@github.com>
Message-ID: <eNpS7tbWtMBTrYSjB8UmDJOf3Qno02YB4VZTFNUjVSg=.857e56be-2e67-4379-a300-cb31abac4c22@github.com>

> # Description
> 
> Please review this PR with a patch to re-use the same C2_MacroAssembler object to emit all instructions in the same compilation unit.
> 
> Overall, the change is pretty simple. However, due to the renaming of the variable to access C2_MacroAssembler, from `_masm.` to `masm->`, and also some method prototype changes, the patch became quite large.
> 
> # Help Needed for Testing
> 
> I don't have access to all platforms necessary to test this. I hope some other folks can help with testing on `S390`, `RISC-V` and `PPC`.
> 
> # Testing status
> 
> ## tier1
> 
> |          |   Win   |   Mac   |  Linux  |
> |----------|---------|---------|---------|
> | ARM64    |         |         |         |
> | ARM32    |         |         |         |
> | x86      |         |         |         |
> | x64      |         |         |         |
> | PPC64    |         |         |         |
> | S390x    |         |         |         |
> | RiscV    |         |         |         |

Cesar Soares Lucas has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:

 - Catch up with changes on master
 - Reuse same C2_MacroAssembler object to emit instructions.

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

Changes: https://git.openjdk.org/jdk/pull/16484/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16484&range=01
  Stats: 3356 lines in 60 files changed: 1039 ins; 426 del; 1891 mod
  Patch: https://git.openjdk.org/jdk/pull/16484.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16484/head:pull/16484

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

From dholmes at openjdk.org  Wed Nov 22 02:09:38 2023
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 22 Nov 2023 02:09:38 GMT
Subject: RFR: 8318776: Require supports_cx8 to always be true [v5]
In-Reply-To: <oIBgmqm_tcBgAzRlR-vLLnW9ky7pTgNwKy0463UZw5Q=.87894004-0e8a-4d75-bb8f-be6602a09a97@github.com>
References: <oIBgmqm_tcBgAzRlR-vLLnW9ky7pTgNwKy0463UZw5Q=.87894004-0e8a-4d75-bb8f-be6602a09a97@github.com>
Message-ID: <DqoMRLjwHcgi9FzwK-SnX1Cyq6UO6rIgYb6DjSvx-YQ=.60431f1c-42f7-4859-ac0f-76be5f07c0d2@github.com>

> As discussed in JBS all platforms (some tweaks to Zero are in progress) actually do support `cx8` i.e. 64-bit compare-and-exchange, so we can strip out the locked-based alternatives to using it and just add a guarantee that it is true at runtime. And all platforms except some ARM variants set `SUPPORTS_NATIVE_CX8`, so we can greatly simplify things. Summary of changes:
> - `_supports_cx8` field is only needed when `SUPPORTS_NATIVE_CX8` is not defined
> - Assertions for `supports_cx8()` are removed
> - Compiler predicates requiring `supports_cx8()` are removed
> - Access backend is greatly simplified without the need for lock-based alternative
> - `java.util.concurrent.AtomicLongFieldUpdater` is simplified without the need for a lock-based alternative
> 
> I did consider moving all the ARM `kuser_helper` related code to be only defined when `SUPPORTS_NATIVE_CX8` is not defined, but there was a theoretical risk this could change the behaviour if ARMv7 binaries were run on other ARM CPU's. I added a note to that effect in vm_version_linux_arm32.cpp so the ARM port maintainers could clean this up further if desired.
> 
> Testing:
> - All Oracle tiers 1-5 builds (which includes an ARMv7 build)
> - GHA builds/tests
> - Oracle tiers 1-3 sanity testing
> 
> Zero changes coming in via [JDK-8319777](https://bugs.openjdk.org/browse/JDK-8319777) will be merged when they arrive.
> 
> Thanks.

David Holmes 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 seven additional commits since the last revision:

 - Merge with master and update Zero code accordingly
 - Merge branch 'master' into 8318776-supports_cx8
 - Remove unnecessary includes of vm_version.hpp.
   Fix copyright years.
 - Remove cx8 comment as no longer relevant (the spinlock is used regardless of cx8)
 - Remove suports_cx8() checks from gtest
 - Remove test for VMSupportsCX8
 - 8318776: Require supports_cx8 to always be true

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16625/files
  - new: https://git.openjdk.org/jdk/pull/16625/files/597cef53..aad0a4c4

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

  Stats: 621905 lines in 1279 files changed: 89413 ins; 471113 del; 61379 mod
  Patch: https://git.openjdk.org/jdk/pull/16625.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16625/head:pull/16625

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

From dholmes at openjdk.org  Wed Nov 22 02:21:05 2023
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 22 Nov 2023 02:21:05 GMT
Subject: RFR: 8318776: Require supports_cx8 to always be true [v4]
In-Reply-To: <xxzHExpfg7dRBWuPDSJZpTYVAGtbsiKzfHbtkJuPve8=.b7493d33-e12e-4b6c-8e2f-37e5e9750c77@github.com>
References: <oIBgmqm_tcBgAzRlR-vLLnW9ky7pTgNwKy0463UZw5Q=.87894004-0e8a-4d75-bb8f-be6602a09a97@github.com>
 <J1TWPnz-iQ3n-68dY3YgbuH6Qa2bd3mZKCULSHIVJL4=.497d4a3a-5682-4410-8b16-fc2d426f5231@github.com>
 <S_bLfuPh3YULfZYwOmlX4rmxR2u6xEoaeNVZz2ZHLVE=.595a04db-9de3-45e8-bdf1-b2fbb784802b@github.com>
 <xxzHExpfg7dRBWuPDSJZpTYVAGtbsiKzfHbtkJuPve8=.b7493d33-e12e-4b6c-8e2f-37e5e9750c77@github.com>
Message-ID: <JZCNyaDFpHiyER3Wzo8xVGNB_L4djdAuii1ot5NUFwA=.75457bd2-f104-4f1c-baa3-7e62a88c8da4@github.com>

On Tue, 21 Nov 2023 16:58:21 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> This looks great!
>
>> Thanks for the review @fisk ! I have to wait for a few Zero related PRs to get integrated then re-merge, before I can integrate.
> 
> Zero patches were pushed, please re-merge. I checked current mainline works well with at least linux-arm-zero-fastdebug, and I would like to re-test it with this patch.

@shipilev  I have re-merged and update the Zero changes (ifdef around `_saupports_cx8`).

@viktorklang-ora and/or @DougLea could I ask you to look at the `java.util.concurrent.AtomicLongFieldUpdater` changes please.

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

PR Comment: https://git.openjdk.org/jdk/pull/16625#issuecomment-1821983975

From shade at openjdk.org  Wed Nov 22 09:00:13 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 22 Nov 2023 09:00:13 GMT
Subject: RFR: 8318776: Require supports_cx8 to always be true [v5]
In-Reply-To: <DqoMRLjwHcgi9FzwK-SnX1Cyq6UO6rIgYb6DjSvx-YQ=.60431f1c-42f7-4859-ac0f-76be5f07c0d2@github.com>
References: <oIBgmqm_tcBgAzRlR-vLLnW9ky7pTgNwKy0463UZw5Q=.87894004-0e8a-4d75-bb8f-be6602a09a97@github.com>
 <DqoMRLjwHcgi9FzwK-SnX1Cyq6UO6rIgYb6DjSvx-YQ=.60431f1c-42f7-4859-ac0f-76be5f07c0d2@github.com>
Message-ID: <wR3ZQTpHpwUFhoeE-DC5_04XzuuG2YzKJT4MMPOZ1to=.b6a6c468-dac2-47d9-8ded-23e710ce18ca@github.com>

On Wed, 22 Nov 2023 02:09:38 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> As discussed in JBS all platforms (some tweaks to Zero are in progress) actually do support `cx8` i.e. 64-bit compare-and-exchange, so we can strip out the locked-based alternatives to using it and just add a guarantee that it is true at runtime. And all platforms except some ARM variants set `SUPPORTS_NATIVE_CX8`, so we can greatly simplify things. Summary of changes:
>> - `_supports_cx8` field is only needed when `SUPPORTS_NATIVE_CX8` is not defined
>> - Assertions for `supports_cx8()` are removed
>> - Compiler predicates requiring `supports_cx8()` are removed
>> - Access backend is greatly simplified without the need for lock-based alternative
>> - `java.util.concurrent.AtomicLongFieldUpdater` is simplified without the need for a lock-based alternative
>> 
>> I did consider moving all the ARM `kuser_helper` related code to be only defined when `SUPPORTS_NATIVE_CX8` is not defined, but there was a theoretical risk this could change the behaviour if ARMv7 binaries were run on other ARM CPU's. I added a note to that effect in vm_version_linux_arm32.cpp so the ARM port maintainers could clean this up further if desired.
>> 
>> Testing:
>> - All Oracle tiers 1-5 builds (which includes an ARMv7 build)
>> - GHA builds/tests
>> - Oracle tiers 1-3 sanity testing
>> 
>> Zero changes coming in via [JDK-8319777](https://bugs.openjdk.org/browse/JDK-8319777) will be merged when they arrive.
>> 
>> Thanks.
>
> David Holmes 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 seven additional commits since the last revision:
> 
>  - Merge with master and update Zero code accordingly
>  - Merge branch 'master' into 8318776-supports_cx8
>  - Remove unnecessary includes of vm_version.hpp.
>    Fix copyright years.
>  - Remove cx8 comment as no longer relevant (the spinlock is used regardless of cx8)
>  - Remove suports_cx8() checks from gtest
>  - Remove test for VMSupportsCX8
>  - 8318776: Require supports_cx8 to always be true

Thanks! Zero tests are running. The PR looks great, except extra safety suggestion in x86 part:

src/hotspot/cpu/x86/vm_version_x86.cpp line 819:

> 817:   }
> 818: 
> 819:   _supports_cx8 = supports_cmpxchg8();

I think we should leave the runtime check here (under `ifndef`, like in ARM?). This covers the remaining case of running on legacy x86 without CX8 implemented: the init guarantee would then fire and prevent any other surprises at runtime. Sure, it would be hard to come up with such a platform today, but it would be safer to refuse to run there right away on the off-chance someone actually has it :)

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

PR Review: https://git.openjdk.org/jdk/pull/16625#pullrequestreview-1743847107
PR Review Comment: https://git.openjdk.org/jdk/pull/16625#discussion_r1401696816

From shade at openjdk.org  Wed Nov 22 09:27:11 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 22 Nov 2023 09:27:11 GMT
Subject: RFR: 8318776: Require supports_cx8 to always be true [v5]
In-Reply-To: <DqoMRLjwHcgi9FzwK-SnX1Cyq6UO6rIgYb6DjSvx-YQ=.60431f1c-42f7-4859-ac0f-76be5f07c0d2@github.com>
References: <oIBgmqm_tcBgAzRlR-vLLnW9ky7pTgNwKy0463UZw5Q=.87894004-0e8a-4d75-bb8f-be6602a09a97@github.com>
 <DqoMRLjwHcgi9FzwK-SnX1Cyq6UO6rIgYb6DjSvx-YQ=.60431f1c-42f7-4859-ac0f-76be5f07c0d2@github.com>
Message-ID: <T1PaxEyz9PCX7lz4ztqT4E-qJlGWZSunDihIJzeY0MU=.62653076-01f2-4f34-86d8-0157395f4148@github.com>

On Wed, 22 Nov 2023 02:09:38 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> As discussed in JBS all platforms (some tweaks to Zero are in progress) actually do support `cx8` i.e. 64-bit compare-and-exchange, so we can strip out the locked-based alternatives to using it and just add a guarantee that it is true at runtime. And all platforms except some ARM variants set `SUPPORTS_NATIVE_CX8`, so we can greatly simplify things. Summary of changes:
>> - `_supports_cx8` field is only needed when `SUPPORTS_NATIVE_CX8` is not defined
>> - Assertions for `supports_cx8()` are removed
>> - Compiler predicates requiring `supports_cx8()` are removed
>> - Access backend is greatly simplified without the need for lock-based alternative
>> - `java.util.concurrent.AtomicLongFieldUpdater` is simplified without the need for a lock-based alternative
>> 
>> I did consider moving all the ARM `kuser_helper` related code to be only defined when `SUPPORTS_NATIVE_CX8` is not defined, but there was a theoretical risk this could change the behaviour if ARMv7 binaries were run on other ARM CPU's. I added a note to that effect in vm_version_linux_arm32.cpp so the ARM port maintainers could clean this up further if desired.
>> 
>> Testing:
>> - All Oracle tiers 1-5 builds (which includes an ARMv7 build)
>> - GHA builds/tests
>> - Oracle tiers 1-3 sanity testing
>> 
>> Zero changes coming in via [JDK-8319777](https://bugs.openjdk.org/browse/JDK-8319777) will be merged when they arrive.
>> 
>> Thanks.
>
> David Holmes 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 seven additional commits since the last revision:
> 
>  - Merge with master and update Zero code accordingly
>  - Merge branch 'master' into 8318776-supports_cx8
>  - Remove unnecessary includes of vm_version.hpp.
>    Fix copyright years.
>  - Remove cx8 comment as no longer relevant (the spinlock is used regardless of cx8)
>  - Remove suports_cx8() checks from gtest
>  - Remove test for VMSupportsCX8
>  - 8318776: Require supports_cx8 to always be true

src/hotspot/share/runtime/vm_version.cpp line 33:

> 31: void VM_Version_init() {
> 32:   VM_Version::initialize();
> 33:   guarantee(VM_Version::supports_cx8(), "Support for 64-bit atomic operations in required in this release");

Typo: "in required in". Also, no need to mention "this release" at all?
Suggestion for message: "JVM requires platform support for 64-bit atomic operations"

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16625#discussion_r1401743607

From shade at openjdk.org  Wed Nov 22 10:38:08 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 22 Nov 2023 10:38:08 GMT
Subject: RFR: 8318776: Require supports_cx8 to always be true [v5]
In-Reply-To: <wR3ZQTpHpwUFhoeE-DC5_04XzuuG2YzKJT4MMPOZ1to=.b6a6c468-dac2-47d9-8ded-23e710ce18ca@github.com>
References: <oIBgmqm_tcBgAzRlR-vLLnW9ky7pTgNwKy0463UZw5Q=.87894004-0e8a-4d75-bb8f-be6602a09a97@github.com>
 <DqoMRLjwHcgi9FzwK-SnX1Cyq6UO6rIgYb6DjSvx-YQ=.60431f1c-42f7-4859-ac0f-76be5f07c0d2@github.com>
 <wR3ZQTpHpwUFhoeE-DC5_04XzuuG2YzKJT4MMPOZ1to=.b6a6c468-dac2-47d9-8ded-23e710ce18ca@github.com>
Message-ID: <Ifq6Tt0aiSa4ZCs2U4Og7AirGV0jP446B67jZJSL3ls=.9ad9014d-d37b-4d0d-9d28-7dc4b665cb86@github.com>

On Wed, 22 Nov 2023 08:57:11 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Zero tests are running. 

Caught the `guarantee` on linux-arm-zero-fastdebug! But that is actually the fault in my previous patch: #16779.

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

PR Comment: https://git.openjdk.org/jdk/pull/16625#issuecomment-1822510325

From dl at openjdk.org  Wed Nov 22 15:53:12 2023
From: dl at openjdk.org (Doug Lea)
Date: Wed, 22 Nov 2023 15:53:12 GMT
Subject: RFR: 8318776: Require supports_cx8 to always be true [v5]
In-Reply-To: <DqoMRLjwHcgi9FzwK-SnX1Cyq6UO6rIgYb6DjSvx-YQ=.60431f1c-42f7-4859-ac0f-76be5f07c0d2@github.com>
References: <oIBgmqm_tcBgAzRlR-vLLnW9ky7pTgNwKy0463UZw5Q=.87894004-0e8a-4d75-bb8f-be6602a09a97@github.com>
 <DqoMRLjwHcgi9FzwK-SnX1Cyq6UO6rIgYb6DjSvx-YQ=.60431f1c-42f7-4859-ac0f-76be5f07c0d2@github.com>
Message-ID: <UtRI11C54KtBEBZn_N9rnB86FcMjr60uE7pSyjYEtEI=.01688d27-9e6d-4dd3-889c-c530b11d1b89@github.com>

On Wed, 22 Nov 2023 02:09:38 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> As discussed in JBS all platforms (some tweaks to Zero are in progress) actually do support `cx8` i.e. 64-bit compare-and-exchange, so we can strip out the locked-based alternatives to using it and just add a guarantee that it is true at runtime. And all platforms except some ARM variants set `SUPPORTS_NATIVE_CX8`, so we can greatly simplify things. Summary of changes:
>> - `_supports_cx8` field is only needed when `SUPPORTS_NATIVE_CX8` is not defined
>> - Assertions for `supports_cx8()` are removed
>> - Compiler predicates requiring `supports_cx8()` are removed
>> - Access backend is greatly simplified without the need for lock-based alternative
>> - `java.util.concurrent.AtomicLongFieldUpdater` is simplified without the need for a lock-based alternative
>> 
>> I did consider moving all the ARM `kuser_helper` related code to be only defined when `SUPPORTS_NATIVE_CX8` is not defined, but there was a theoretical risk this could change the behaviour if ARMv7 binaries were run on other ARM CPU's. I added a note to that effect in vm_version_linux_arm32.cpp so the ARM port maintainers could clean this up further if desired.
>> 
>> Testing:
>> - All Oracle tiers 1-5 builds (which includes an ARMv7 build)
>> - GHA builds/tests
>> - Oracle tiers 1-3 sanity testing
>> 
>> Zero changes coming in via [JDK-8319777](https://bugs.openjdk.org/browse/JDK-8319777) will be merged when they arrive.
>> 
>> Thanks.
>
> David Holmes 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 seven additional commits since the last revision:
> 
>  - Merge with master and update Zero code accordingly
>  - Merge branch 'master' into 8318776-supports_cx8
>  - Remove unnecessary includes of vm_version.hpp.
>    Fix copyright years.
>  - Remove cx8 comment as no longer relevant (the spinlock is used regardless of cx8)
>  - Remove suports_cx8() checks from gtest
>  - Remove test for VMSupportsCX8
>  - 8318776: Require supports_cx8 to always be true

The deletion of backup code and the check for it in java.util.concurrent.AtomicLongFieldUpdater are clearly OK. We always thought the need for it was transient.

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

PR Comment: https://git.openjdk.org/jdk/pull/16625#issuecomment-1823026095

From tschatzl at openjdk.org  Wed Nov 22 16:09:27 2023
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Wed, 22 Nov 2023 16:09:27 GMT
Subject: RFR: 8317809: Insertion of free code blobs into code cache can be
 very slow during class unloading [v2]
In-Reply-To: <_dcFF70_w7IXSjb6w-HuHCBkPyS3a6NlzejtqdfdYnM=.74e0f9df-eca3-49b0-be68-2d5824c16003@github.com>
References: <_dcFF70_w7IXSjb6w-HuHCBkPyS3a6NlzejtqdfdYnM=.74e0f9df-eca3-49b0-be68-2d5824c16003@github.com>
Message-ID: <TyffrQASEQ9r4UzVzJ7m4TqsjYNGvIEWzrMYBQHbhqg=.73d475d8-8a4b-4e2f-a8c3-df7a05a4383e@github.com>

> Insert code blobs in a sorted fashion to exploit the finger-optimization when adding, making this procedure O(n) instead of O(n^2)
> 
> Introduces a globally available ClassUnloadingContext that contains common methods pertaining to class and code unloading. GCs may use it to efficiently manage unlinked class loader datas and nmethods to allow use of common methods (unlink/merge).
> 
> The steps typically are registering a new to be unlinked CLD/nmethod, and then purge its memory later. STW collectors perform this work in one big chunk taking the CodeCache_lock, for the entire duration, while concurrent collectors lock/unlock for every insertion to allow for concurrent users for the lock to progress.
> 
> Some care has been taken to stay consistent with an "unloading = unlinking + purge" scheme; however particularly the existing CLD handling API (still) mixes unlinking and purging in its CLD::unload() call. To simplify this change that is mostly geared towards separating nmethod unlinking from purging, to make code blob freeing O(n) instead of O(n^2).
> 
> Upcoming changes will
> * separate nmethod unregistering from nmethod purging to allow doing that in bulk (for the STW collectors); that can significantly reduce code purging time for the STW collectors.
> * better name the second stage of unlinking (called "cleaning" throughout, e.g. the work done in `G1CollectedHeap::complete_cleaning`)
> * untangle CLD unlinking and what's called "cleaning" now to allow moving more stuff into the second unlinking stage for better parallelism
> * G1: move some significant tasks from the remark pause to concurrent (unregistering nmethods, freeing code blobs and cld/metaspace purging)
> * Maybe move Serial/Parallel GC metaspace purging closer to other unlinking/purging code to keep things local and allow easier logging.
> 
> Please also first looking into the (small) PR this depends on.
> 
> The crash on linux-x86 is fixed by PR#16766 which I split out for quicker reviews.
> 
> Testing: tier1-7
> 
> Thanks,
>   Thomas

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

  iwalulya review, naming

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16759/files
  - new: https://git.openjdk.org/jdk/pull/16759/files/d63ff4a4..448232df

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

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

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

From tschatzl at openjdk.org  Wed Nov 22 16:55:08 2023
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Wed, 22 Nov 2023 16:55:08 GMT
Subject: RFR: 8317809: Insertion of free code blobs into code cache can be
 very slow during class unloading [v2]
In-Reply-To: <TyffrQASEQ9r4UzVzJ7m4TqsjYNGvIEWzrMYBQHbhqg=.73d475d8-8a4b-4e2f-a8c3-df7a05a4383e@github.com>
References: <_dcFF70_w7IXSjb6w-HuHCBkPyS3a6NlzejtqdfdYnM=.74e0f9df-eca3-49b0-be68-2d5824c16003@github.com>
 <TyffrQASEQ9r4UzVzJ7m4TqsjYNGvIEWzrMYBQHbhqg=.73d475d8-8a4b-4e2f-a8c3-df7a05a4383e@github.com>
Message-ID: <HCdLsb3vkXTG3DU-4kbWNgjqcnH7CdJw2_sbm87d6qE=.a2ed53b4-7ecd-4d5d-9f6f-7e70fad1b740@github.com>

On Wed, 22 Nov 2023 16:09:27 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Insert code blobs in a sorted fashion to exploit the finger-optimization when adding, making this procedure O(n) instead of O(n^2)
>> 
>> Introduces a globally available ClassUnloadingContext that contains common methods pertaining to class and code unloading. GCs may use it to efficiently manage unlinked class loader datas and nmethods to allow use of common methods (unlink/merge).
>> 
>> The steps typically are registering a new to be unlinked CLD/nmethod, and then purge its memory later. STW collectors perform this work in one big chunk taking the CodeCache_lock, for the entire duration, while concurrent collectors lock/unlock for every insertion to allow for concurrent users for the lock to progress.
>> 
>> Some care has been taken to stay consistent with an "unloading = unlinking + purge" scheme; however particularly the existing CLD handling API (still) mixes unlinking and purging in its CLD::unload() call. To simplify this change that is mostly geared towards separating nmethod unlinking from purging, to make code blob freeing O(n) instead of O(n^2).
>> 
>> Upcoming changes will
>> * separate nmethod unregistering from nmethod purging to allow doing that in bulk (for the STW collectors); that can significantly reduce code purging time for the STW collectors.
>> * better name the second stage of unlinking (called "cleaning" throughout, e.g. the work done in `G1CollectedHeap::complete_cleaning`)
>> * untangle CLD unlinking and what's called "cleaning" now to allow moving more stuff into the second unlinking stage for better parallelism
>> * G1: move some significant tasks from the remark pause to concurrent (unregistering nmethods, freeing code blobs and cld/metaspace purging)
>> * Maybe move Serial/Parallel GC metaspace purging closer to other unlinking/purging code to keep things local and allow easier logging.
>> 
>> These are the reason for the class hierarchy for `ClassUnloadingContext`: the goal is to ultimately have about this phasing (for G1):
>> 1. collect all dead CLDs, using the `register_unloading_class_loader_data` method *only*
>> 2. parallelize the stuff in `ClassLoaderData::unload()` in one way or another, adding them to the `complete_cleaning` (parallel) phase.
>> 3. `purge_nmethods`, `free_code_blobs` and the `remove_unlinked_nmethods_from_code_root_set` (from JDK-8317007) will be concurrent.
>> 
>> Particularly the split of `SystemDictionary::do_unloading` into "only" traversing the CLDs to find the dead ones and then in parallel process them in 2. a...
>
> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:
> 
>   iwalulya review, naming

I added some explanation of why there is a class hierarchy for `ClassUnloadingContext` in the description (and some further background).

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

PR Comment: https://git.openjdk.org/jdk/pull/16759#issuecomment-1823139932

From dcubed at openjdk.org  Wed Nov 22 18:39:10 2023
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Wed, 22 Nov 2023 18:39:10 GMT
Subject: RFR: 8318776: Require supports_cx8 to always be true [v5]
In-Reply-To: <DqoMRLjwHcgi9FzwK-SnX1Cyq6UO6rIgYb6DjSvx-YQ=.60431f1c-42f7-4859-ac0f-76be5f07c0d2@github.com>
References: <oIBgmqm_tcBgAzRlR-vLLnW9ky7pTgNwKy0463UZw5Q=.87894004-0e8a-4d75-bb8f-be6602a09a97@github.com>
 <DqoMRLjwHcgi9FzwK-SnX1Cyq6UO6rIgYb6DjSvx-YQ=.60431f1c-42f7-4859-ac0f-76be5f07c0d2@github.com>
Message-ID: <6TkAoQRK_49MtT6wjb_JAwFzUATAvAx_rX9yxMa9Vfs=.7d1d5bf6-f088-44df-9d01-cc336bdeecaa@github.com>

On Wed, 22 Nov 2023 02:09:38 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> As discussed in JBS all platforms (some tweaks to Zero are in progress) actually do support `cx8` i.e. 64-bit compare-and-exchange, so we can strip out the locked-based alternatives to using it and just add a guarantee that it is true at runtime. And all platforms except some ARM variants set `SUPPORTS_NATIVE_CX8`, so we can greatly simplify things. Summary of changes:
>> - `_supports_cx8` field is only needed when `SUPPORTS_NATIVE_CX8` is not defined
>> - Assertions for `supports_cx8()` are removed
>> - Compiler predicates requiring `supports_cx8()` are removed
>> - Access backend is greatly simplified without the need for lock-based alternative
>> - `java.util.concurrent.AtomicLongFieldUpdater` is simplified without the need for a lock-based alternative
>> 
>> I did consider moving all the ARM `kuser_helper` related code to be only defined when `SUPPORTS_NATIVE_CX8` is not defined, but there was a theoretical risk this could change the behaviour if ARMv7 binaries were run on other ARM CPU's. I added a note to that effect in vm_version_linux_arm32.cpp so the ARM port maintainers could clean this up further if desired.
>> 
>> Testing:
>> - All Oracle tiers 1-5 builds (which includes an ARMv7 build)
>> - GHA builds/tests
>> - Oracle tiers 1-3 sanity testing
>> 
>> Zero changes coming in via [JDK-8319777](https://bugs.openjdk.org/browse/JDK-8319777) will be merged when they arrive.
>> 
>> Thanks.
>
> David Holmes 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 seven additional commits since the last revision:
> 
>  - Merge with master and update Zero code accordingly
>  - Merge branch 'master' into 8318776-supports_cx8
>  - Remove unnecessary includes of vm_version.hpp.
>    Fix copyright years.
>  - Remove cx8 comment as no longer relevant (the spinlock is used regardless of cx8)
>  - Remove suports_cx8() checks from gtest
>  - Remove test for VMSupportsCX8
>  - 8318776: Require supports_cx8 to always be true

Wow! This PR is much larger than I expected.

Thumbs up!

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

Marked as reviewed by dcubed (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16625#pullrequestreview-1745089631

From dcubed at openjdk.org  Wed Nov 22 18:39:15 2023
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Wed, 22 Nov 2023 18:39:15 GMT
Subject: RFR: 8318776: Require supports_cx8 to always be true [v5]
In-Reply-To: <wR3ZQTpHpwUFhoeE-DC5_04XzuuG2YzKJT4MMPOZ1to=.b6a6c468-dac2-47d9-8ded-23e710ce18ca@github.com>
References: <oIBgmqm_tcBgAzRlR-vLLnW9ky7pTgNwKy0463UZw5Q=.87894004-0e8a-4d75-bb8f-be6602a09a97@github.com>
 <DqoMRLjwHcgi9FzwK-SnX1Cyq6UO6rIgYb6DjSvx-YQ=.60431f1c-42f7-4859-ac0f-76be5f07c0d2@github.com>
 <wR3ZQTpHpwUFhoeE-DC5_04XzuuG2YzKJT4MMPOZ1to=.b6a6c468-dac2-47d9-8ded-23e710ce18ca@github.com>
Message-ID: <Yq021jorCaQpCWEI_qRnUNGwmb8iLh7RS5A2AILFK5o=.a0814777-0545-419f-a074-a86fa1357629@github.com>

On Wed, 22 Nov 2023 08:48:09 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> David Holmes 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 seven additional commits since the last revision:
>> 
>>  - Merge with master and update Zero code accordingly
>>  - Merge branch 'master' into 8318776-supports_cx8
>>  - Remove unnecessary includes of vm_version.hpp.
>>    Fix copyright years.
>>  - Remove cx8 comment as no longer relevant (the spinlock is used regardless of cx8)
>>  - Remove suports_cx8() checks from gtest
>>  - Remove test for VMSupportsCX8
>>  - 8318776: Require supports_cx8 to always be true
>
> src/hotspot/cpu/x86/vm_version_x86.cpp line 819:
> 
>> 817:   }
>> 818: 
>> 819:   _supports_cx8 = supports_cmpxchg8();
> 
> I think we should leave the runtime check here (under `ifndef`, like in ARM?). This covers the remaining case of running on legacy x86 without CX8 implemented: the init guarantee would then fire and prevent any other surprises at runtime. Sure, it would be hard to come up with such a platform today, but it would be safer to refuse to run there right away on the off-chance someone actually has it :)

@shipilev - Do you have a particular legacy x86 in mind?

> src/hotspot/share/runtime/vm_version.cpp line 33:
> 
>> 31: void VM_Version_init() {
>> 32:   VM_Version::initialize();
>> 33:   guarantee(VM_Version::supports_cx8(), "Support for 64-bit atomic operations in required in this release");
> 
> Typo: "in required in". Also, no need to mention "this release" at all?
> Suggestion for message: "JVM requires platform support for 64-bit atomic operations"

Or the simpler change:
s/in required/is required/

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16625#discussion_r1402515036
PR Review Comment: https://git.openjdk.org/jdk/pull/16625#discussion_r1402528045

From shade at openjdk.org  Wed Nov 22 21:46:09 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 22 Nov 2023 21:46:09 GMT
Subject: RFR: 8318776: Require supports_cx8 to always be true [v5]
In-Reply-To: <Yq021jorCaQpCWEI_qRnUNGwmb8iLh7RS5A2AILFK5o=.a0814777-0545-419f-a074-a86fa1357629@github.com>
References: <oIBgmqm_tcBgAzRlR-vLLnW9ky7pTgNwKy0463UZw5Q=.87894004-0e8a-4d75-bb8f-be6602a09a97@github.com>
 <DqoMRLjwHcgi9FzwK-SnX1Cyq6UO6rIgYb6DjSvx-YQ=.60431f1c-42f7-4859-ac0f-76be5f07c0d2@github.com>
 <wR3ZQTpHpwUFhoeE-DC5_04XzuuG2YzKJT4MMPOZ1to=.b6a6c468-dac2-47d9-8ded-23e710ce18ca@github.com>
 <Yq021jorCaQpCWEI_qRnUNGwmb8iLh7RS5A2AILFK5o=.a0814777-0545-419f-a074-a86fa1357629@github.com>
Message-ID: <nPIaVNXcWvNO03_i8RwFskOXWC8MBx7AzTza2Be8acM=.9a3a5390-bbd0-425b-b88d-84226f8c2f52@github.com>

On Wed, 22 Nov 2023 18:26:12 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> src/hotspot/cpu/x86/vm_version_x86.cpp line 819:
>> 
>>> 817:   }
>>> 818: 
>>> 819:   _supports_cx8 = supports_cmpxchg8();
>> 
>> I think we should leave the runtime check here (under `ifndef`, like in ARM?). This covers the remaining case of running on legacy x86 without CX8 implemented: the init guarantee would then fire and prevent any other surprises at runtime. Sure, it would be hard to come up with such a platform today, but it would be safer to refuse to run there right away on the off-chance someone actually has it :)
>
> @shipilev - Do you have a particular legacy x86 in mind?

My point is that it is such an easy thing to do: leave the "cx8" flag sensing code in, and keep setting up `_supports_cx8` based on it. This both provides more safety by failing cleanly on non-CX8 platform, and gives other platforms some guidance: if you can check something is supported, check it.

But now that you nerd-sniped me into this... I think non-CX8 platforms would probably predate Pentium. The oldest real machine my lab has is Z530, which already has CX8. But it was easy to also go to my QEMU-driven build-test server, ask for `i486` as platform there, and et voila, no `cx8` in CPU flags:


buildworker-debian12-32:~$ lscpu
Architecture:            i486
  CPU op-mode(s):        32-bit
  Address sizes:         36 bits physical, 32 bits virtual
  Byte Order:            Little Endian
CPU(s):                  4
  On-line CPU(s) list:   0-3
Vendor ID:               GenuineIntel
  Model name:            486 DX/4
    CPU family:          4
    Model:               8
    Thread(s) per core:  4
    Core(s) per socket:  1
    Socket(s):           1
    Stepping:            0
    BogoMIPS:            5699.99
    Flags:               fpu vme pse apic ht cpuid tsc_known_freq x2apic hypervisor cpuid_fault


And mainline JDK even starts there! (with interpreter, there are some asserts firing in compiler code, having to do with odd instruction selection on some paths):


$ jdk/bin/java -Xint -version
openjdk version "22-testing" 2024-03-19
OpenJDK Runtime Environment (fastdebug build 22-testing-builds.shipilev.net-openjdk-jdk-b627-20231121)
OpenJDK Server VM (fastdebug build 22-testing-builds.shipilev.net-openjdk-jdk-b627-20231121, interpreted mode, sharing)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16625#discussion_r1402738580

From dcubed at openjdk.org  Wed Nov 22 22:01:10 2023
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Wed, 22 Nov 2023 22:01:10 GMT
Subject: RFR: 8318776: Require supports_cx8 to always be true [v5]
In-Reply-To: <nPIaVNXcWvNO03_i8RwFskOXWC8MBx7AzTza2Be8acM=.9a3a5390-bbd0-425b-b88d-84226f8c2f52@github.com>
References: <oIBgmqm_tcBgAzRlR-vLLnW9ky7pTgNwKy0463UZw5Q=.87894004-0e8a-4d75-bb8f-be6602a09a97@github.com>
 <DqoMRLjwHcgi9FzwK-SnX1Cyq6UO6rIgYb6DjSvx-YQ=.60431f1c-42f7-4859-ac0f-76be5f07c0d2@github.com>
 <wR3ZQTpHpwUFhoeE-DC5_04XzuuG2YzKJT4MMPOZ1to=.b6a6c468-dac2-47d9-8ded-23e710ce18ca@github.com>
 <Yq021jorCaQpCWEI_qRnUNGwmb8iLh7RS5A2AILFK5o=.a0814777-0545-419f-a074-a86fa1357629@github.com>
 <nPIaVNXcWvNO03_i8RwFskOXWC8MBx7AzTza2Be8acM=.9a3a5390-bbd0-425b-b88d-84226f8c2f52@github.com>
Message-ID: <Ky2mZY1HA7fxxlk5Rzgg4mjDXA8oj7FdVYrt83oHHnE=.ee2bff68-5051-44c3-a728-a6bf56a93f0a@github.com>

On Wed, 22 Nov 2023 21:41:50 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> @shipilev - Do you have a particular legacy x86 in mind?
>
> My point is that it is such an easy thing to do: leave the "cx8" flag sensing code in, and keep setting up `_supports_cx8` based on it for `!_LP64` paths. This both provides more safety by failing cleanly on non-CX8 platform, and gives other platforms some guidance: if you can check something is supported, check it. I think we are generally trying to fail cleanly on unsupported configs, if that is easy to achieve.
> 
> But now that you nerd-sniped me into this... I think non-CX8 platforms would probably predate Pentium. The oldest real machine my lab has is Z530, which already has CX8. But it was easy to also go to my QEMU-driven build-test server, ask for `i486` as platform there, and et voila, no `cx8` in CPU flags:
> 
> 
> buildworker-debian12-32:~$ lscpu
> Architecture:            i486
>   CPU op-mode(s):        32-bit
>   Address sizes:         36 bits physical, 32 bits virtual
>   Byte Order:            Little Endian
> CPU(s):                  4
>   On-line CPU(s) list:   0-3
> Vendor ID:               GenuineIntel
>   Model name:            486 DX/4
>     CPU family:          4
>     Model:               8
>     Thread(s) per core:  4
>     Core(s) per socket:  1
>     Socket(s):           1
>     Stepping:            0
>     BogoMIPS:            5699.99
>     Flags:               fpu vme pse apic ht cpuid tsc_known_freq x2apic hypervisor cpuid_fault
> 
> 
> And mainline JDK even starts there! (with interpreter, there are some asserts firing in compiler code, having to do with odd instruction selection on some paths):
> 
> 
> $ jdk/bin/java -Xint -version
> openjdk version "22-testing" 2024-03-19
> OpenJDK Runtime Environment (fastdebug build 22-testing-builds.shipilev.net-openjdk-jdk-b627-20231121)
> OpenJDK Server VM (fastdebug build 22-testing-builds.shipilev.net-openjdk-jdk-b627-20231121, interpreted mode, sharing)

Nice spelunking... I was wondering if it was something that old. I wasn't trying to nerd-snipe...

I was in the dev lab at Intel when Xenix on the i386 first came up and sent its "Hello World!" email...
I left Intel for Sun in 1987 while i486 was still in development, but I still had periodic lunches with
folks that worked on those teams. Life was simpler back then...

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16625#discussion_r1402748121

From dholmes at openjdk.org  Thu Nov 23 03:14:27 2023
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 23 Nov 2023 03:14:27 GMT
Subject: RFR: 8318776: Require supports_cx8 to always be true [v6]
In-Reply-To: <oIBgmqm_tcBgAzRlR-vLLnW9ky7pTgNwKy0463UZw5Q=.87894004-0e8a-4d75-bb8f-be6602a09a97@github.com>
References: <oIBgmqm_tcBgAzRlR-vLLnW9ky7pTgNwKy0463UZw5Q=.87894004-0e8a-4d75-bb8f-be6602a09a97@github.com>
Message-ID: <q9shZu655QOFYhbZfZen5ZQBSUofac4m42baAxaWvVc=.7ed27d22-dbf4-4fd8-89b0-b9b41b71bc39@github.com>

> As discussed in JBS all platforms (some tweaks to Zero are in progress) actually do support `cx8` i.e. 64-bit compare-and-exchange, so we can strip out the locked-based alternatives to using it and just add a guarantee that it is true at runtime. And all platforms except some ARM variants set `SUPPORTS_NATIVE_CX8`, so we can greatly simplify things. Summary of changes:
> - `_supports_cx8` field is only needed when `SUPPORTS_NATIVE_CX8` is not defined
> - Assertions for `supports_cx8()` are removed
> - Compiler predicates requiring `supports_cx8()` are removed
> - Access backend is greatly simplified without the need for lock-based alternative
> - `java.util.concurrent.AtomicLongFieldUpdater` is simplified without the need for a lock-based alternative
> 
> I did consider moving all the ARM `kuser_helper` related code to be only defined when `SUPPORTS_NATIVE_CX8` is not defined, but there was a theoretical risk this could change the behaviour if ARMv7 binaries were run on other ARM CPU's. I added a note to that effect in vm_version_linux_arm32.cpp so the ARM port maintainers could clean this up further if desired.
> 
> Testing:
> - All Oracle tiers 1-5 builds (which includes an ARMv7 build)
> - GHA builds/tests
> - Oracle tiers 1-3 sanity testing
> 
> Zero changes coming in via [JDK-8319777](https://bugs.openjdk.org/browse/JDK-8319777) will be merged when they arrive.
> 
> Thanks.

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

  Fix typo

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16625/files
  - new: https://git.openjdk.org/jdk/pull/16625/files/aad0a4c4..2393b9d4

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

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

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

From dholmes at openjdk.org  Thu Nov 23 03:14:32 2023
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 23 Nov 2023 03:14:32 GMT
Subject: RFR: 8318776: Require supports_cx8 to always be true [v5]
In-Reply-To: <UtRI11C54KtBEBZn_N9rnB86FcMjr60uE7pSyjYEtEI=.01688d27-9e6d-4dd3-889c-c530b11d1b89@github.com>
References: <oIBgmqm_tcBgAzRlR-vLLnW9ky7pTgNwKy0463UZw5Q=.87894004-0e8a-4d75-bb8f-be6602a09a97@github.com>
 <DqoMRLjwHcgi9FzwK-SnX1Cyq6UO6rIgYb6DjSvx-YQ=.60431f1c-42f7-4859-ac0f-76be5f07c0d2@github.com>
 <UtRI11C54KtBEBZn_N9rnB86FcMjr60uE7pSyjYEtEI=.01688d27-9e6d-4dd3-889c-c530b11d1b89@github.com>
Message-ID: <Q2W8wdlthqwJc4UPLhhC6GiCAeo8pkw0AyDFF3GHYLA=.5a59a954-b858-46e8-b4cf-596e9bb3911b@github.com>

On Wed, 22 Nov 2023 15:50:17 GMT, Doug Lea <dl at openjdk.org> wrote:

>> David Holmes 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 seven additional commits since the last revision:
>> 
>>  - Merge with master and update Zero code accordingly
>>  - Merge branch 'master' into 8318776-supports_cx8
>>  - Remove unnecessary includes of vm_version.hpp.
>>    Fix copyright years.
>>  - Remove cx8 comment as no longer relevant (the spinlock is used regardless of cx8)
>>  - Remove suports_cx8() checks from gtest
>>  - Remove test for VMSupportsCX8
>>  - 8318776: Require supports_cx8 to always be true
>
> The deletion of backup code and the check for it in java.util.concurrent.AtomicLongFieldUpdater are clearly OK. We always thought the need for it was transient.

Thanks for looking at this @DougLea !

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

PR Comment: https://git.openjdk.org/jdk/pull/16625#issuecomment-1823770525

From dholmes at openjdk.org  Thu Nov 23 03:14:34 2023
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 23 Nov 2023 03:14:34 GMT
Subject: RFR: 8318776: Require supports_cx8 to always be true [v5]
In-Reply-To: <6TkAoQRK_49MtT6wjb_JAwFzUATAvAx_rX9yxMa9Vfs=.7d1d5bf6-f088-44df-9d01-cc336bdeecaa@github.com>
References: <oIBgmqm_tcBgAzRlR-vLLnW9ky7pTgNwKy0463UZw5Q=.87894004-0e8a-4d75-bb8f-be6602a09a97@github.com>
 <DqoMRLjwHcgi9FzwK-SnX1Cyq6UO6rIgYb6DjSvx-YQ=.60431f1c-42f7-4859-ac0f-76be5f07c0d2@github.com>
 <6TkAoQRK_49MtT6wjb_JAwFzUATAvAx_rX9yxMa9Vfs=.7d1d5bf6-f088-44df-9d01-cc336bdeecaa@github.com>
Message-ID: <MvFsRQSTd4I5LMz2OL0JUOvokwBz0sZacSw3UOfm6bs=.99ca1590-bdef-4729-81de-7385510ba760@github.com>

On Wed, 22 Nov 2023 18:35:59 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> Wow! This PR is much larger than I expected.
> 
> Thumbs up!

Thanks for the Review Dan! Yes lots of code deletion engineering in this one - and even better I got to delete template code with meta-programming stuff! :D

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

PR Comment: https://git.openjdk.org/jdk/pull/16625#issuecomment-1823771180

From dholmes at openjdk.org  Thu Nov 23 03:14:36 2023
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 23 Nov 2023 03:14:36 GMT
Subject: RFR: 8318776: Require supports_cx8 to always be true [v6]
In-Reply-To: <Ky2mZY1HA7fxxlk5Rzgg4mjDXA8oj7FdVYrt83oHHnE=.ee2bff68-5051-44c3-a728-a6bf56a93f0a@github.com>
References: <oIBgmqm_tcBgAzRlR-vLLnW9ky7pTgNwKy0463UZw5Q=.87894004-0e8a-4d75-bb8f-be6602a09a97@github.com>
 <DqoMRLjwHcgi9FzwK-SnX1Cyq6UO6rIgYb6DjSvx-YQ=.60431f1c-42f7-4859-ac0f-76be5f07c0d2@github.com>
 <wR3ZQTpHpwUFhoeE-DC5_04XzuuG2YzKJT4MMPOZ1to=.b6a6c468-dac2-47d9-8ded-23e710ce18ca@github.com>
 <Yq021jorCaQpCWEI_qRnUNGwmb8iLh7RS5A2AILFK5o=.a0814777-0545-419f-a074-a86fa1357629@github.com>
 <nPIaVNXcWvNO03_i8RwFskOXWC8MBx7AzTza2Be8acM=.9a3a5390-bbd0-425b-b88d-84226f8c2f52@github.com>
 <Ky2mZY1HA7fxxlk5Rzgg4mjDXA8oj7FdVYrt83oHHnE=.ee2bff68-5051-44c3-a728-a6bf56a93f0a@github.com>
Message-ID: <gb84qQIwSdqiWhDKjr_okpB76Isg7clZlwlwqHgQ8fg=.d32aca29-0446-4dc7-a5f4-2800596f53fc@github.com>

On Wed, 22 Nov 2023 21:57:57 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> My point is that it is such an easy thing to do: leave the "cx8" flag sensing code in, and keep setting up `_supports_cx8` based on it for `!_LP64` paths. This both provides more safety by failing cleanly on non-CX8 platform, and gives other platforms some guidance: if you can check something is supported, check it. I think we are generally trying to fail cleanly on unsupported configs, if that is easy to achieve.
>> 
>> But now that you nerd-sniped me into this... I think non-CX8 platforms would probably predate Pentium. The oldest real machine my lab has is Z530, which already has CX8. But it was easy to also go to my QEMU-driven build-test server, ask for `i486` as platform there, and et voila, no `cx8` in CPU flags:
>> 
>> 
>> buildworker-debian12-32:~$ lscpu
>> Architecture:            i486
>>   CPU op-mode(s):        32-bit
>>   Address sizes:         36 bits physical, 32 bits virtual
>>   Byte Order:            Little Endian
>> CPU(s):                  4
>>   On-line CPU(s) list:   0-3
>> Vendor ID:               GenuineIntel
>>   Model name:            486 DX/4
>>     CPU family:          4
>>     Model:               8
>>     Thread(s) per core:  4
>>     Core(s) per socket:  1
>>     Socket(s):           1
>>     Stepping:            0
>>     BogoMIPS:            5699.99
>>     Flags:               fpu vme pse apic ht cpuid tsc_known_freq x2apic hypervisor cpuid_fault
>> 
>> 
>> And mainline JDK even starts there! (with interpreter, there are some asserts firing in compiler code, having to do with odd instruction selection on some paths):
>> 
>> 
>> $ jdk/bin/java -Xint -version
>> openjdk version "22-testing" 2024-03-19
>> OpenJDK Runtime Environment (fastdebug build 22-testing-builds.shipilev.net-openjdk-jdk-b627-20231121)
>> OpenJDK Server VM (fastdebug build 22-testing-builds.shipilev.net-openjdk-jdk-b627-20231121, interpreted mode, sharing)
>
> Nice spelunking... I was wondering if it was something that old. I wasn't trying to nerd-snipe...
> 
> I was in the dev lab at Intel when Xenix on the i386 first came up and sent its "Hello World!" email...
> I left Intel for Sun in 1987 while i486 was still in development, but I still had periodic lunches with
> folks that worked on those teams. Life was simpler back then...

I politely disagree. The whole point here is to leave the past behind as much as possible. We made a concession for ARM32 as there may still be old ARMv5 and ARMv6 systems in use. IIUC you need to go back to the i486 chip to not have cmpxchg8 support and I'd bet money on it that we can't run on such a chip any more for a whole swag of reasons. In any case I don't have an issue telling i486 machine owners they are stuck with JDK 21!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16625#discussion_r1402877044

From dholmes at openjdk.org  Thu Nov 23 03:14:37 2023
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 23 Nov 2023 03:14:37 GMT
Subject: RFR: 8318776: Require supports_cx8 to always be true [v5]
In-Reply-To: <Yq021jorCaQpCWEI_qRnUNGwmb8iLh7RS5A2AILFK5o=.a0814777-0545-419f-a074-a86fa1357629@github.com>
References: <oIBgmqm_tcBgAzRlR-vLLnW9ky7pTgNwKy0463UZw5Q=.87894004-0e8a-4d75-bb8f-be6602a09a97@github.com>
 <DqoMRLjwHcgi9FzwK-SnX1Cyq6UO6rIgYb6DjSvx-YQ=.60431f1c-42f7-4859-ac0f-76be5f07c0d2@github.com>
 <wR3ZQTpHpwUFhoeE-DC5_04XzuuG2YzKJT4MMPOZ1to=.b6a6c468-dac2-47d9-8ded-23e710ce18ca@github.com>
 <Yq021jorCaQpCWEI_qRnUNGwmb8iLh7RS5A2AILFK5o=.a0814777-0545-419f-a074-a86fa1357629@github.com>
Message-ID: <x15LFukyKev8svwwbaBdq0I-_tTLv04ALQT5X7t_w6M=.7cbadf7a-d397-4efb-949a-a93400aedec5@github.com>

On Wed, 22 Nov 2023 18:35:33 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> src/hotspot/share/runtime/vm_version.cpp line 33:
>> 
>>> 31: void VM_Version_init() {
>>> 32:   VM_Version::initialize();
>>> 33:   guarantee(VM_Version::supports_cx8(), "Support for 64-bit atomic operations in required in this release");
>> 
>> Typo: "in required in". Also, no need to mention "this release" at all?
>> Suggestion for message: "JVM requires platform support for 64-bit atomic operations"
>
> Or the simpler change:
> s/in required/is required/

Message tweaked: Support for 64-bit atomic operations is required

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16625#discussion_r1402877940

From amitkumar at openjdk.org  Thu Nov 23 05:10:08 2023
From: amitkumar at openjdk.org (Amit Kumar)
Date: Thu, 23 Nov 2023 05:10:08 GMT
Subject: RFR: 8317809: Insertion of free code blobs into code cache can be
 very slow during class unloading [v2]
In-Reply-To: <TyffrQASEQ9r4UzVzJ7m4TqsjYNGvIEWzrMYBQHbhqg=.73d475d8-8a4b-4e2f-a8c3-df7a05a4383e@github.com>
References: <_dcFF70_w7IXSjb6w-HuHCBkPyS3a6NlzejtqdfdYnM=.74e0f9df-eca3-49b0-be68-2d5824c16003@github.com>
 <TyffrQASEQ9r4UzVzJ7m4TqsjYNGvIEWzrMYBQHbhqg=.73d475d8-8a4b-4e2f-a8c3-df7a05a4383e@github.com>
Message-ID: <OXbRjhxQr0dB5r8kjA-QfKRPNA_M8dp3JeLeGpV-2XM=.8a69645f-158c-4e8d-9b11-e14631cfe595@github.com>

On Wed, 22 Nov 2023 16:09:27 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Insert code blobs in a sorted fashion to exploit the finger-optimization when adding, making this procedure O(n) instead of O(n^2)
>> 
>> Introduces a globally available ClassUnloadingContext that contains common methods pertaining to class and code unloading. GCs may use it to efficiently manage unlinked class loader datas and nmethods to allow use of common methods (unlink/merge).
>> 
>> The steps typically are registering a new to be unlinked CLD/nmethod, and then purge its memory later. STW collectors perform this work in one big chunk taking the CodeCache_lock, for the entire duration, while concurrent collectors lock/unlock for every insertion to allow for concurrent users for the lock to progress.
>> 
>> Some care has been taken to stay consistent with an "unloading = unlinking + purge" scheme; however particularly the existing CLD handling API (still) mixes unlinking and purging in its CLD::unload() call. To simplify this change that is mostly geared towards separating nmethod unlinking from purging, to make code blob freeing O(n) instead of O(n^2).
>> 
>> Upcoming changes will
>> * separate nmethod unregistering from nmethod purging to allow doing that in bulk (for the STW collectors); that can significantly reduce code purging time for the STW collectors.
>> * better name the second stage of unlinking (called "cleaning" throughout, e.g. the work done in `G1CollectedHeap::complete_cleaning`)
>> * untangle CLD unlinking and what's called "cleaning" now to allow moving more stuff into the second unlinking stage for better parallelism
>> * G1: move some significant tasks from the remark pause to concurrent (unregistering nmethods, freeing code blobs and cld/metaspace purging)
>> * Maybe move Serial/Parallel GC metaspace purging closer to other unlinking/purging code to keep things local and allow easier logging.
>> 
>> These are the reason for the class hierarchy for `ClassUnloadingContext`: the goal is to ultimately have about this phasing (for G1):
>> 1. collect all dead CLDs, using the `register_unloading_class_loader_data` method *only*
>> 2. parallelize the stuff in `ClassLoaderData::unload()` in one way or another, adding them to the `complete_cleaning` (parallel) phase.
>> 3. `purge_nmethods`, `free_code_blobs` and the `remove_unlinked_nmethods_from_code_root_set` (from JDK-8317007) will be concurrent.
>> 
>> Particularly the split of `SystemDictionary::do_unloading` into "only" traversing the CLDs to find the dead ones and then in parallel process them in 2. a...
>
> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:
> 
>   iwalulya review, naming

src/hotspot/share/classfile/classLoaderData.cpp line 602:

> 600: 
> 601:   // Clean up class dependencies and tell serviceability tools
> 602:   // these classes are unloading.  This must be called

Suggestion:

  // these classes are unloading. This must be called

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16759#discussion_r1402920337

From vklang at openjdk.org  Thu Nov 23 08:12:11 2023
From: vklang at openjdk.org (Viktor Klang)
Date: Thu, 23 Nov 2023 08:12:11 GMT
Subject: RFR: 8318776: Require supports_cx8 to always be true [v5]
In-Reply-To: <MvFsRQSTd4I5LMz2OL0JUOvokwBz0sZacSw3UOfm6bs=.99ca1590-bdef-4729-81de-7385510ba760@github.com>
References: <oIBgmqm_tcBgAzRlR-vLLnW9ky7pTgNwKy0463UZw5Q=.87894004-0e8a-4d75-bb8f-be6602a09a97@github.com>
 <DqoMRLjwHcgi9FzwK-SnX1Cyq6UO6rIgYb6DjSvx-YQ=.60431f1c-42f7-4859-ac0f-76be5f07c0d2@github.com>
 <6TkAoQRK_49MtT6wjb_JAwFzUATAvAx_rX9yxMa9Vfs=.7d1d5bf6-f088-44df-9d01-cc336bdeecaa@github.com>
 <MvFsRQSTd4I5LMz2OL0JUOvokwBz0sZacSw3UOfm6bs=.99ca1590-bdef-4729-81de-7385510ba760@github.com>
Message-ID: <a5Lr0G3TJPz5Xx2x16yHcd1bx7pGZ80o2sw1NmTeTSM=.07829aad-1b50-4332-a536-8172eb71c3cd@github.com>

On Thu, 23 Nov 2023 03:11:15 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Wow! This PR is much larger than I expected.
>> 
>> Thumbs up!
>
>> Wow! This PR is much larger than I expected.
>> 
>> Thumbs up!
> 
> Thanks for the Review Dan! Yes lots of code deletion engineering in this one - and even better I got to delete template code with meta-programming stuff! :D

@dholmes-ora Just passing by -- impressed by the thorough update!

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

PR Comment: https://git.openjdk.org/jdk/pull/16625#issuecomment-1823953312

From dholmes at openjdk.org  Thu Nov 23 08:16:11 2023
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 23 Nov 2023 08:16:11 GMT
Subject: RFR: 8318776: Require supports_cx8 to always be true [v5]
In-Reply-To: <a5Lr0G3TJPz5Xx2x16yHcd1bx7pGZ80o2sw1NmTeTSM=.07829aad-1b50-4332-a536-8172eb71c3cd@github.com>
References: <oIBgmqm_tcBgAzRlR-vLLnW9ky7pTgNwKy0463UZw5Q=.87894004-0e8a-4d75-bb8f-be6602a09a97@github.com>
 <DqoMRLjwHcgi9FzwK-SnX1Cyq6UO6rIgYb6DjSvx-YQ=.60431f1c-42f7-4859-ac0f-76be5f07c0d2@github.com>
 <6TkAoQRK_49MtT6wjb_JAwFzUATAvAx_rX9yxMa9Vfs=.7d1d5bf6-f088-44df-9d01-cc336bdeecaa@github.com>
 <MvFsRQSTd4I5LMz2OL0JUOvokwBz0sZacSw3UOfm6bs=.99ca1590-bdef-4729-81de-7385510ba760@github.com>
 <a5Lr0G3TJPz5Xx2x16yHcd1bx7pGZ80o2sw1NmTeTSM=.07829aad-1b50-4332-a536-8172eb71c3cd@github.com>
Message-ID: <Qd1vrH_-q5KtNUA1t7L2nm9zIRETZ5bn3HoyUUPTjZ8=.df831ba3-a7fb-4284-8dcb-75e54fe96848@github.com>

On Thu, 23 Nov 2023 08:09:44 GMT, Viktor Klang <vklang at openjdk.org> wrote:

>>> Wow! This PR is much larger than I expected.
>>> 
>>> Thumbs up!
>> 
>> Thanks for the Review Dan! Yes lots of code deletion engineering in this one - and even better I got to delete template code with meta-programming stuff! :D
>
> @dholmes-ora Just passing by -- impressed by the thorough update!

Thanks for taking a look @viktorklang-ora !

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

PR Comment: https://git.openjdk.org/jdk/pull/16625#issuecomment-1823957279

From shade at openjdk.org  Thu Nov 23 08:28:12 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 23 Nov 2023 08:28:12 GMT
Subject: RFR: 8318776: Require supports_cx8 to always be true [v6]
In-Reply-To: <q9shZu655QOFYhbZfZen5ZQBSUofac4m42baAxaWvVc=.7ed27d22-dbf4-4fd8-89b0-b9b41b71bc39@github.com>
References: <oIBgmqm_tcBgAzRlR-vLLnW9ky7pTgNwKy0463UZw5Q=.87894004-0e8a-4d75-bb8f-be6602a09a97@github.com>
 <q9shZu655QOFYhbZfZen5ZQBSUofac4m42baAxaWvVc=.7ed27d22-dbf4-4fd8-89b0-b9b41b71bc39@github.com>
Message-ID: <KauS_yTtgsSd-3Cf9viQjzwd1zMvL9VokTVaObSq5bk=.ac84c25d-0739-49ca-9128-840000673ff2@github.com>

On Thu, 23 Nov 2023 03:14:27 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> As discussed in JBS all platforms (some tweaks to Zero are in progress) actually do support `cx8` i.e. 64-bit compare-and-exchange, so we can strip out the locked-based alternatives to using it and just add a guarantee that it is true at runtime. And all platforms except some ARM variants set `SUPPORTS_NATIVE_CX8`, so we can greatly simplify things. Summary of changes:
>> - `_supports_cx8` field is only needed when `SUPPORTS_NATIVE_CX8` is not defined
>> - Assertions for `supports_cx8()` are removed
>> - Compiler predicates requiring `supports_cx8()` are removed
>> - Access backend is greatly simplified without the need for lock-based alternative
>> - `java.util.concurrent.AtomicLongFieldUpdater` is simplified without the need for a lock-based alternative
>> 
>> I did consider moving all the ARM `kuser_helper` related code to be only defined when `SUPPORTS_NATIVE_CX8` is not defined, but there was a theoretical risk this could change the behaviour if ARMv7 binaries were run on other ARM CPU's. I added a note to that effect in vm_version_linux_arm32.cpp so the ARM port maintainers could clean this up further if desired.
>> 
>> Testing:
>> - All Oracle tiers 1-5 builds (which includes an ARMv7 build)
>> - GHA builds/tests
>> - Oracle tiers 1-3 sanity testing
>> 
>> Zero changes coming in via [JDK-8319777](https://bugs.openjdk.org/browse/JDK-8319777) will be merged when they arrive.
>> 
>> Thanks.
>
> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix typo

Ran full jcstress on linux-arm-zero-release on RPi 4 without problem.

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

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16625#pullrequestreview-1745896266

From dholmes at openjdk.org  Thu Nov 23 12:09:27 2023
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 23 Nov 2023 12:09:27 GMT
Subject: RFR: 8318776: Require supports_cx8 to always be true [v7]
In-Reply-To: <oIBgmqm_tcBgAzRlR-vLLnW9ky7pTgNwKy0463UZw5Q=.87894004-0e8a-4d75-bb8f-be6602a09a97@github.com>
References: <oIBgmqm_tcBgAzRlR-vLLnW9ky7pTgNwKy0463UZw5Q=.87894004-0e8a-4d75-bb8f-be6602a09a97@github.com>
Message-ID: <tfmYvyOiv1tRrKiJcG4PuGvl5NH02TjSBwSnCRfksYo=.c80fea28-c871-46df-9265-ac24378bc5a4@github.com>

> As discussed in JBS all platforms (some tweaks to Zero are in progress) actually do support `cx8` i.e. 64-bit compare-and-exchange, so we can strip out the locked-based alternatives to using it and just add a guarantee that it is true at runtime. And all platforms except some ARM variants set `SUPPORTS_NATIVE_CX8`, so we can greatly simplify things. Summary of changes:
> - `_supports_cx8` field is only needed when `SUPPORTS_NATIVE_CX8` is not defined
> - Assertions for `supports_cx8()` are removed
> - Compiler predicates requiring `supports_cx8()` are removed
> - Access backend is greatly simplified without the need for lock-based alternative
> - `java.util.concurrent.AtomicLongFieldUpdater` is simplified without the need for a lock-based alternative
> 
> I did consider moving all the ARM `kuser_helper` related code to be only defined when `SUPPORTS_NATIVE_CX8` is not defined, but there was a theoretical risk this could change the behaviour if ARMv7 binaries were run on other ARM CPU's. I added a note to that effect in vm_version_linux_arm32.cpp so the ARM port maintainers could clean this up further if desired.
> 
> Testing:
> - All Oracle tiers 1-5 builds (which includes an ARMv7 build)
> - GHA builds/tests
> - Oracle tiers 1-3 sanity testing
> 
> Zero changes coming in via [JDK-8319777](https://bugs.openjdk.org/browse/JDK-8319777) will be merged when they arrive.
> 
> Thanks.

David Holmes has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits:

 - Merge
 - Fix typo
 - Merge with master and update Zero code accordingly
 - Merge branch 'master' into 8318776-supports_cx8
 - Remove unnecessary includes of vm_version.hpp.
   Fix copyright years.
 - Remove cx8 comment as no longer relevant (the spinlock is used regardless of cx8)
 - Remove suports_cx8() checks from gtest
 - Remove test for VMSupportsCX8
 - 8318776: Require supports_cx8 to always be true

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

Changes: https://git.openjdk.org/jdk/pull/16625/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16625&range=06
  Stats: 460 lines in 39 files changed: 16 ins; 429 del; 15 mod
  Patch: https://git.openjdk.org/jdk/pull/16625.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16625/head:pull/16625

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

From wkemper at openjdk.org  Thu Nov 23 14:16:09 2023
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 23 Nov 2023 14:16:09 GMT
Subject: RFR: Merge openjdk/jdk:master
Message-ID: <E1vD7QOVhProkE_vbpQGYMiDP4xecIJ2L3vpknQbjWk=.6f9af4aa-e706-4a35-b189-ba3f700dd4f8@github.com>

Merges tag jdk-22+25

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

Commit messages:
 - 8074211: javax.sound.midi: Error with send System Exclusive messages of different length
 - 8320278: ARM32 build is broken after JDK-8301997
 - 8318364: Add an FFM-based implementation of harfbuzz OpenType layout
 - 8319124: Update XML Security for Java to 3.0.3
 - 8317742: ISO Standard Date Format implementation consistency on DateTimeFormatter and String.format
 - 8320272: Make method_entry_barrier address shared
 - 8320526: Use title case in building.md
 - 8315969: compiler/rangechecks/TestRangeCheckHoistingScaledIV.java: make flagless
 - 8187591: -Werror turns incubator module warning to an error
 - 8310807: java/nio/channels/DatagramChannel/Connect.java timed out
 - ... and 66 more: https://git.openjdk.org/shenandoah/compare/ffa35d8c...e47cf611

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

Changes: https://git.openjdk.org/shenandoah/pull/362/files
  Stats: 15946 lines in 483 files changed: 8945 ins; 3487 del; 3514 mod
  Patch: https://git.openjdk.org/shenandoah/pull/362.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah.git pull/362/head:pull/362

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

From dholmes at openjdk.org  Thu Nov 23 22:26:20 2023
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 23 Nov 2023 22:26:20 GMT
Subject: RFR: 8318776: Require supports_cx8 to always be true [v7]
In-Reply-To: <tfmYvyOiv1tRrKiJcG4PuGvl5NH02TjSBwSnCRfksYo=.c80fea28-c871-46df-9265-ac24378bc5a4@github.com>
References: <oIBgmqm_tcBgAzRlR-vLLnW9ky7pTgNwKy0463UZw5Q=.87894004-0e8a-4d75-bb8f-be6602a09a97@github.com>
 <tfmYvyOiv1tRrKiJcG4PuGvl5NH02TjSBwSnCRfksYo=.c80fea28-c871-46df-9265-ac24378bc5a4@github.com>
Message-ID: <Em7b74ue9y2sBlIdXwNFuXciNvm1CEwvfAAPP5pceIQ=.a8a71d04-d715-471f-b016-2898cf4dab92@github.com>

On Thu, 23 Nov 2023 12:09:27 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> As discussed in JBS all platforms (some tweaks to Zero are in progress) actually do support `cx8` i.e. 64-bit compare-and-exchange, so we can strip out the locked-based alternatives to using it and just add a guarantee that it is true at runtime. And all platforms except some ARM variants set `SUPPORTS_NATIVE_CX8`, so we can greatly simplify things. Summary of changes:
>> - `_supports_cx8` field is only needed when `SUPPORTS_NATIVE_CX8` is not defined
>> - Assertions for `supports_cx8()` are removed
>> - Compiler predicates requiring `supports_cx8()` are removed
>> - Access backend is greatly simplified without the need for lock-based alternative
>> - `java.util.concurrent.AtomicLongFieldUpdater` is simplified without the need for a lock-based alternative
>> 
>> I did consider moving all the ARM `kuser_helper` related code to be only defined when `SUPPORTS_NATIVE_CX8` is not defined, but there was a theoretical risk this could change the behaviour if ARMv7 binaries were run on other ARM CPU's. I added a note to that effect in vm_version_linux_arm32.cpp so the ARM port maintainers could clean this up further if desired.
>> 
>> Testing:
>> - All Oracle tiers 1-5 builds (which includes an ARMv7 build)
>> - GHA builds/tests
>> - Oracle tiers 1-3 sanity testing
>> 
>> Zero changes coming in via [JDK-8319777](https://bugs.openjdk.org/browse/JDK-8319777) will be merged when they arrive.
>> 
>> Thanks.
>
> David Holmes has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits:
> 
>  - Merge
>  - Fix typo
>  - Merge with master and update Zero code accordingly
>  - Merge branch 'master' into 8318776-supports_cx8
>  - Remove unnecessary includes of vm_version.hpp.
>    Fix copyright years.
>  - Remove cx8 comment as no longer relevant (the spinlock is used regardless of cx8)
>  - Remove suports_cx8() checks from gtest
>  - Remove test for VMSupportsCX8
>  - 8318776: Require supports_cx8 to always be true

Thanks for all the reviews. Integrating now.

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

PR Comment: https://git.openjdk.org/jdk/pull/16625#issuecomment-1824966904

From dholmes at openjdk.org  Thu Nov 23 22:26:22 2023
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 23 Nov 2023 22:26:22 GMT
Subject: Integrated: 8318776: Require supports_cx8 to always be true
In-Reply-To: <oIBgmqm_tcBgAzRlR-vLLnW9ky7pTgNwKy0463UZw5Q=.87894004-0e8a-4d75-bb8f-be6602a09a97@github.com>
References: <oIBgmqm_tcBgAzRlR-vLLnW9ky7pTgNwKy0463UZw5Q=.87894004-0e8a-4d75-bb8f-be6602a09a97@github.com>
Message-ID: <l-c6Vz7Qi-shQhjg8aqcn99KGIBX76srDu0DWxLdj1E=.c7ea8a0d-8ccf-431e-b8a5-5606be9c6258@github.com>

On Mon, 13 Nov 2023 04:38:35 GMT, David Holmes <dholmes at openjdk.org> wrote:

> As discussed in JBS all platforms (some tweaks to Zero are in progress) actually do support `cx8` i.e. 64-bit compare-and-exchange, so we can strip out the locked-based alternatives to using it and just add a guarantee that it is true at runtime. And all platforms except some ARM variants set `SUPPORTS_NATIVE_CX8`, so we can greatly simplify things. Summary of changes:
> - `_supports_cx8` field is only needed when `SUPPORTS_NATIVE_CX8` is not defined
> - Assertions for `supports_cx8()` are removed
> - Compiler predicates requiring `supports_cx8()` are removed
> - Access backend is greatly simplified without the need for lock-based alternative
> - `java.util.concurrent.AtomicLongFieldUpdater` is simplified without the need for a lock-based alternative
> 
> I did consider moving all the ARM `kuser_helper` related code to be only defined when `SUPPORTS_NATIVE_CX8` is not defined, but there was a theoretical risk this could change the behaviour if ARMv7 binaries were run on other ARM CPU's. I added a note to that effect in vm_version_linux_arm32.cpp so the ARM port maintainers could clean this up further if desired.
> 
> Testing:
> - All Oracle tiers 1-5 builds (which includes an ARMv7 build)
> - GHA builds/tests
> - Oracle tiers 1-3 sanity testing
> 
> Zero changes coming in via [JDK-8319777](https://bugs.openjdk.org/browse/JDK-8319777) will be merged when they arrive.
> 
> Thanks.

This pull request has now been integrated.

Changeset: c75c3887
Author:    David Holmes <dholmes at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c75c38871ee7b5c9f7f0c195d649c16967f786bb
Stats:     460 lines in 39 files changed: 16 ins; 429 del; 15 mod

8318776: Require supports_cx8 to always be true

Reviewed-by: eosterlund, shade, dcubed

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

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

From tschatzl at openjdk.org  Fri Nov 24 09:18:25 2023
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Fri, 24 Nov 2023 09:18:25 GMT
Subject: RFR: 8317809: Insertion of free code blobs into code cache can be
 very slow during class unloading [v3]
In-Reply-To: <_dcFF70_w7IXSjb6w-HuHCBkPyS3a6NlzejtqdfdYnM=.74e0f9df-eca3-49b0-be68-2d5824c16003@github.com>
References: <_dcFF70_w7IXSjb6w-HuHCBkPyS3a6NlzejtqdfdYnM=.74e0f9df-eca3-49b0-be68-2d5824c16003@github.com>
Message-ID: <wPKk7I8G7gknAGGQhrOurDNO1ekzXk3HMxHhlW_S5oc=.ee4e09e7-b4eb-40a6-a149-7b5a30ff42f9@github.com>

> Insert code blobs in a sorted fashion to exploit the finger-optimization when adding, making this procedure O(n) instead of O(n^2)
> 
> Introduces a globally available ClassUnloadingContext that contains common methods pertaining to class and code unloading. GCs may use it to efficiently manage unlinked class loader datas and nmethods to allow use of common methods (unlink/merge).
> 
> The steps typically are registering a new to be unlinked CLD/nmethod, and then purge its memory later. STW collectors perform this work in one big chunk taking the CodeCache_lock, for the entire duration, while concurrent collectors lock/unlock for every insertion to allow for concurrent users for the lock to progress.
> 
> Some care has been taken to stay consistent with an "unloading = unlinking + purge" scheme; however particularly the existing CLD handling API (still) mixes unlinking and purging in its CLD::unload() call. To simplify this change that is mostly geared towards separating nmethod unlinking from purging, to make code blob freeing O(n) instead of O(n^2).
> 
> Upcoming changes will
> * separate nmethod unregistering from nmethod purging to allow doing that in bulk (for the STW collectors); that can significantly reduce code purging time for the STW collectors.
> * better name the second stage of unlinking (called "cleaning" throughout, e.g. the work done in `G1CollectedHeap::complete_cleaning`)
> * untangle CLD unlinking and what's called "cleaning" now to allow moving more stuff into the second unlinking stage for better parallelism
> * G1: move some significant tasks from the remark pause to concurrent (unregistering nmethods, freeing code blobs and cld/metaspace purging)
> * Maybe move Serial/Parallel GC metaspace purging closer to other unlinking/purging code to keep things local and allow easier logging.
> 
> These are the reason for the class hierarchy for `ClassUnloadingContext`: the goal is to ultimately have about this phasing (for G1):
> 1. collect all dead CLDs, using the `register_unloading_class_loader_data` method *only*
> 2. parallelize the stuff in `ClassLoaderData::unload()` in one way or another, adding them to the `complete_cleaning` (parallel) phase.
> 3. `purge_nmethods`, `free_code_blobs` and the `remove_unlinked_nmethods_from_code_root_set` (from JDK-8317007) will be concurrent.
> 
> Particularly the split of `SystemDictionary::do_unloading` into "only" traversing the CLDs to find the dead ones and then in parallel process them in 2. above warrants a separate `ClassUnloadingCo...

Thomas Schatzl has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:

 - Merge branch 'master' into mergeme
 - iwalulya review, naming
 - 8317809 Insert code blobs in a sorted fashion to exploit the finger-optimization when adding, making this procedure O(n) instead of O(n^2)
   
   Introduce a globally available ClassUnloadingContext that contains common methods pertaining to class and code unloading.
   GCs may use it to efficiently manage unlinked class loader datas and nmethods to allow use of common methods (unlink/merge).
   
   The steps typically are registering a new to be unlinked CLD/nmethod, and then purge its memory later. STW collectors perform
   this work in one big chunk taking the CodeCache_lock, for the entire duration, while concurrent collectors lock/unlock for every
   insertion to allow for concurrent users for the lock to progress.
   
   Some care has been taken to stay consistent with an "unloading = unlinking + purge" scheme; however particularly the existing
   CLD handling API (still) mixes unlinking and purging in its CLD::unload() call. To simplify this change that is mostly geared
   towards separating nmethod unlinking from purging, to make code blob freeing O(n) instead of O(n^2).
   
   Upcoming changes will
   * separate nmethod unregistering from nmethod purging to allow doing that in bulk (for the STW collectors); that can significantly
     reduce code purging time for the STW collectors.
   * better name the second stage of unlinking (called "cleaning" throughout, e.g. the work done in `G1CollectedHeap::complete_cleaning`)
   * untangle CLD unlinking and what's called "cleaning" now to allow moving more stuff into the second unlinking stage for better
     parallelism
   * G1: move some signifcant tasks from the remark pause to concurrent (unregistering nmethods, freeing code blobs and cld/metaspace purging)
   * Maybe move Serial/Parallel GC metaspace purging closer to other unlinking/purging code to keep things local and allow easier logging.
 - Only run test case on debug VMs, sufficient
 - 8320331 g1 full gc "during" verification accesses half-unloaded metadata

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

Changes: https://git.openjdk.org/jdk/pull/16759/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16759&range=02
  Stats: 495 lines in 28 files changed: 368 ins; 83 del; 44 mod
  Patch: https://git.openjdk.org/jdk/pull/16759.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16759/head:pull/16759

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

From tschatzl at openjdk.org  Fri Nov 24 09:18:28 2023
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Fri, 24 Nov 2023 09:18:28 GMT
Subject: RFR: 8317809: Insertion of free code blobs into code cache can be
 very slow during class unloading [v2]
In-Reply-To: <OXbRjhxQr0dB5r8kjA-QfKRPNA_M8dp3JeLeGpV-2XM=.8a69645f-158c-4e8d-9b11-e14631cfe595@github.com>
References: <_dcFF70_w7IXSjb6w-HuHCBkPyS3a6NlzejtqdfdYnM=.74e0f9df-eca3-49b0-be68-2d5824c16003@github.com>
 <TyffrQASEQ9r4UzVzJ7m4TqsjYNGvIEWzrMYBQHbhqg=.73d475d8-8a4b-4e2f-a8c3-df7a05a4383e@github.com>
 <OXbRjhxQr0dB5r8kjA-QfKRPNA_M8dp3JeLeGpV-2XM=.8a69645f-158c-4e8d-9b11-e14631cfe595@github.com>
Message-ID: <X4ZywK9xWVz8M8PQA55YbPb0D3DE9vOYx0rp95-qqm4=.caff5d0d-066e-49af-a88d-352bb569824a@github.com>

On Thu, 23 Nov 2023 05:06:53 GMT, Amit Kumar <amitkumar at openjdk.org> wrote:

>> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   iwalulya review, naming
>
> src/hotspot/share/classfile/classLoaderData.cpp line 602:
> 
>> 600: 
>> 601:   // Clean up class dependencies and tell serviceability tools
>> 602:   // these classes are unloading.  This must be called
> 
> Suggestion:
> 
>   // these classes are unloading. This must be called

Hotspot code style allows comments with both two spaces and one space between sentences in a paragraph. I did not want to change the style there.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16759#discussion_r1404116626

From iwalulya at openjdk.org  Mon Nov 27 14:59:13 2023
From: iwalulya at openjdk.org (Ivan Walulya)
Date: Mon, 27 Nov 2023 14:59:13 GMT
Subject: RFR: 8317809: Insertion of free code blobs into code cache can be
 very slow during class unloading [v3]
In-Reply-To: <wPKk7I8G7gknAGGQhrOurDNO1ekzXk3HMxHhlW_S5oc=.ee4e09e7-b4eb-40a6-a149-7b5a30ff42f9@github.com>
References: <_dcFF70_w7IXSjb6w-HuHCBkPyS3a6NlzejtqdfdYnM=.74e0f9df-eca3-49b0-be68-2d5824c16003@github.com>
 <wPKk7I8G7gknAGGQhrOurDNO1ekzXk3HMxHhlW_S5oc=.ee4e09e7-b4eb-40a6-a149-7b5a30ff42f9@github.com>
Message-ID: <c9-oWPuSkv0oNoZ2iJryeKErjdAYW1cXFOjzxT3cgzU=.0da93cc2-9fe7-41b4-b65e-e53ae4a40c51@github.com>

On Fri, 24 Nov 2023 09:18:25 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Insert code blobs in a sorted fashion to exploit the finger-optimization when adding, making this procedure O(n) instead of O(n^2)
>> 
>> Introduces a globally available ClassUnloadingContext that contains common methods pertaining to class and code unloading. GCs may use it to efficiently manage unlinked class loader datas and nmethods to allow use of common methods (unlink/merge).
>> 
>> The steps typically are registering a new to be unlinked CLD/nmethod, and then purge its memory later. STW collectors perform this work in one big chunk taking the CodeCache_lock, for the entire duration, while concurrent collectors lock/unlock for every insertion to allow for concurrent users for the lock to progress.
>> 
>> Some care has been taken to stay consistent with an "unloading = unlinking + purge" scheme; however particularly the existing CLD handling API (still) mixes unlinking and purging in its CLD::unload() call. To simplify this change that is mostly geared towards separating nmethod unlinking from purging, to make code blob freeing O(n) instead of O(n^2).
>> 
>> Upcoming changes will
>> * separate nmethod unregistering from nmethod purging to allow doing that in bulk (for the STW collectors); that can significantly reduce code purging time for the STW collectors.
>> * better name the second stage of unlinking (called "cleaning" throughout, e.g. the work done in `G1CollectedHeap::complete_cleaning`)
>> * untangle CLD unlinking and what's called "cleaning" now to allow moving more stuff into the second unlinking stage for better parallelism
>> * G1: move some significant tasks from the remark pause to concurrent (unregistering nmethods, freeing code blobs and cld/metaspace purging)
>> * Maybe move Serial/Parallel GC metaspace purging closer to other unlinking/purging code to keep things local and allow easier logging.
>> 
>> These are the reason for the class hierarchy for `ClassUnloadingContext`: the goal is to ultimately have about this phasing (for G1):
>> 1. collect all dead CLDs, using the `register_unloading_class_loader_data` method *only*
>> 2. parallelize the stuff in `ClassLoaderData::unload()` in one way or another, adding them to the `complete_cleaning` (parallel) phase.
>> 3. `purge_nmethods`, `free_code_blobs` and the `remove_unlinked_nmethods_from_code_root_set` (from JDK-8317007) will be concurrent.
>> 
>> Particularly the split of `SystemDictionary::do_unloading` into "only" traversing the CLDs to find the dead ones and then in parallel process them in 2. a...
>
> Thomas Schatzl has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:
> 
>  - Merge branch 'master' into mergeme
>  - iwalulya review, naming
>  - 8317809 Insert code blobs in a sorted fashion to exploit the finger-optimization when adding, making this procedure O(n) instead of O(n^2)
>    
>    Introduce a globally available ClassUnloadingContext that contains common methods pertaining to class and code unloading.
>    GCs may use it to efficiently manage unlinked class loader datas and nmethods to allow use of common methods (unlink/merge).
>    
>    The steps typically are registering a new to be unlinked CLD/nmethod, and then purge its memory later. STW collectors perform
>    this work in one big chunk taking the CodeCache_lock, for the entire duration, while concurrent collectors lock/unlock for every
>    insertion to allow for concurrent users for the lock to progress.
>    
>    Some care has been taken to stay consistent with an "unloading = unlinking + purge" scheme; however particularly the existing
>    CLD handling API (still) mixes unlinking and purging in its CLD::unload() call. To simplify this change that is mostly geared
>    towards separating nmethod unlinking from purging, to make code blob freeing O(n) instead of O(n^2).
>    
>    Upcoming changes will
>    * separate nmethod unregistering from nmethod purging to allow doing that in bulk (for the STW collectors); that can significantly
>      reduce code purging time for the STW collectors.
>    * better name the second stage of unlinking (called "cleaning" throughout, e.g. the work done in `G1CollectedHeap::complete_cleaning`)
>    * untangle CLD unlinking and what's called "cleaning" now to allow moving more stuff into the second unlinking stage for better
>      parallelism
>    * G1: move some signifcant tasks from the remark pause to concurrent (unregistering nmethods, freeing code blobs and cld/metaspace purging)
>    * Maybe move Serial/Parallel GC metaspace purging closer to other unlinking/purging code to keep things local and allow easier logging.
>  - Only run test case on debug VMs, sufficient
>  - 8320331 g1 full gc "during" verification accesses half-unloaded metadata

Changes requested by iwalulya (Reviewer).

src/hotspot/share/gc/shared/classUnloadingContext.cpp line 138:

> 136:   NMethodSet* nmethod_set = nullptr;
> 137: 
> 138:   bool is_parallel = _num_nmethod_unlink_workers != 1;

Suggestion:

  bool is_parallel = _num_nmethod_unlink_workers > 1;

Seems more intuitive.

src/hotspot/share/gc/shared/classUnloadingContext.hpp line 66:

> 64:   ClassLoaderData* volatile _cld_head;
> 65: 
> 66:   uint _num_nmethod_unlink_workers;

probably better to set `_num_nmethod_unlink_workers;` as const, the destructor depends on this being const through the lifetime of the object.

src/hotspot/share/gc/shared/classUnloadingContext.hpp line 95:

> 93: };
> 94: 
> 95: #endif // SHARE_GC_SHARED_CLASSUNLOADINGCONTEXT_HPP

trailing space warning*

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

PR Review: https://git.openjdk.org/jdk/pull/16759#pullrequestreview-1750594239
PR Review Comment: https://git.openjdk.org/jdk/pull/16759#discussion_r1406283555
PR Review Comment: https://git.openjdk.org/jdk/pull/16759#discussion_r1406260568
PR Review Comment: https://git.openjdk.org/jdk/pull/16759#discussion_r1406268113

From ayang at openjdk.org  Mon Nov 27 14:59:17 2023
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Mon, 27 Nov 2023 14:59:17 GMT
Subject: RFR: 8317809: Insertion of free code blobs into code cache can be
 very slow during class unloading [v3]
In-Reply-To: <wPKk7I8G7gknAGGQhrOurDNO1ekzXk3HMxHhlW_S5oc=.ee4e09e7-b4eb-40a6-a149-7b5a30ff42f9@github.com>
References: <_dcFF70_w7IXSjb6w-HuHCBkPyS3a6NlzejtqdfdYnM=.74e0f9df-eca3-49b0-be68-2d5824c16003@github.com>
 <wPKk7I8G7gknAGGQhrOurDNO1ekzXk3HMxHhlW_S5oc=.ee4e09e7-b4eb-40a6-a149-7b5a30ff42f9@github.com>
Message-ID: <ym4bAn9bR2uEMqltEKTgRltmBToMF0GVFIruX5CRTOM=.8209d394-bf68-4d4d-8e97-cea4a0d67c14@github.com>

On Fri, 24 Nov 2023 09:18:25 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Insert code blobs in a sorted fashion to exploit the finger-optimization when adding, making this procedure O(n) instead of O(n^2)
>> 
>> Introduces a globally available ClassUnloadingContext that contains common methods pertaining to class and code unloading. GCs may use it to efficiently manage unlinked class loader datas and nmethods to allow use of common methods (unlink/merge).
>> 
>> The steps typically are registering a new to be unlinked CLD/nmethod, and then purge its memory later. STW collectors perform this work in one big chunk taking the CodeCache_lock, for the entire duration, while concurrent collectors lock/unlock for every insertion to allow for concurrent users for the lock to progress.
>> 
>> Some care has been taken to stay consistent with an "unloading = unlinking + purge" scheme; however particularly the existing CLD handling API (still) mixes unlinking and purging in its CLD::unload() call. To simplify this change that is mostly geared towards separating nmethod unlinking from purging, to make code blob freeing O(n) instead of O(n^2).
>> 
>> Upcoming changes will
>> * separate nmethod unregistering from nmethod purging to allow doing that in bulk (for the STW collectors); that can significantly reduce code purging time for the STW collectors.
>> * better name the second stage of unlinking (called "cleaning" throughout, e.g. the work done in `G1CollectedHeap::complete_cleaning`)
>> * untangle CLD unlinking and what's called "cleaning" now to allow moving more stuff into the second unlinking stage for better parallelism
>> * G1: move some significant tasks from the remark pause to concurrent (unregistering nmethods, freeing code blobs and cld/metaspace purging)
>> * Maybe move Serial/Parallel GC metaspace purging closer to other unlinking/purging code to keep things local and allow easier logging.
>> 
>> These are the reason for the class hierarchy for `ClassUnloadingContext`: the goal is to ultimately have about this phasing (for G1):
>> 1. collect all dead CLDs, using the `register_unloading_class_loader_data` method *only*
>> 2. parallelize the stuff in `ClassLoaderData::unload()` in one way or another, adding them to the `complete_cleaning` (parallel) phase.
>> 3. `purge_nmethods`, `free_code_blobs` and the `remove_unlinked_nmethods_from_code_root_set` (from JDK-8317007) will be concurrent.
>> 
>> Particularly the split of `SystemDictionary::do_unloading` into "only" traversing the CLDs to find the dead ones and then in parallel process them in 2. a...
>
> Thomas Schatzl has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:
> 
>  - Merge branch 'master' into mergeme
>  - iwalulya review, naming
>  - 8317809 Insert code blobs in a sorted fashion to exploit the finger-optimization when adding, making this procedure O(n) instead of O(n^2)
>    
>    Introduce a globally available ClassUnloadingContext that contains common methods pertaining to class and code unloading.
>    GCs may use it to efficiently manage unlinked class loader datas and nmethods to allow use of common methods (unlink/merge).
>    
>    The steps typically are registering a new to be unlinked CLD/nmethod, and then purge its memory later. STW collectors perform
>    this work in one big chunk taking the CodeCache_lock, for the entire duration, while concurrent collectors lock/unlock for every
>    insertion to allow for concurrent users for the lock to progress.
>    
>    Some care has been taken to stay consistent with an "unloading = unlinking + purge" scheme; however particularly the existing
>    CLD handling API (still) mixes unlinking and purging in its CLD::unload() call. To simplify this change that is mostly geared
>    towards separating nmethod unlinking from purging, to make code blob freeing O(n) instead of O(n^2).
>    
>    Upcoming changes will
>    * separate nmethod unregistering from nmethod purging to allow doing that in bulk (for the STW collectors); that can significantly
>      reduce code purging time for the STW collectors.
>    * better name the second stage of unlinking (called "cleaning" throughout, e.g. the work done in `G1CollectedHeap::complete_cleaning`)
>    * untangle CLD unlinking and what's called "cleaning" now to allow moving more stuff into the second unlinking stage for better
>      parallelism
>    * G1: move some signifcant tasks from the remark pause to concurrent (unregistering nmethods, freeing code blobs and cld/metaspace purging)
>    * Maybe move Serial/Parallel GC metaspace purging closer to other unlinking/purging code to keep things local and allow easier logging.
>  - Only run test case on debug VMs, sufficient
>  - 8320331 g1 full gc "during" verification accesses half-unloaded metadata

src/hotspot/share/gc/shared/classUnloadingContext.cpp line 120:

> 118:   for (uint i = 0; i < _num_nmethod_unlink_workers; ++i) {
> 119:     NMethodSet* set = _unlinked_nmethods[i];
> 120:     for (int j = 0; j < set->length(); ++j) {

I wonder if one can use range-based for loop here.

src/hotspot/share/gc/shared/classUnloadingContext.cpp line 171:

> 169:       ConditionalMutexLocker ml_inner(CodeCache_lock, _lock_codeblob_free_separately, Mutex::_no_safepoint_check_flag);
> 170:       CodeCache::free(nmethod_set->at(i));
> 171:     }

I feel it would be clearer if the for-loop is duplicated to handle either case separately.

src/hotspot/share/gc/shared/classUnloadingContext.hpp line 63:

> 61: };
> 62: 
> 63: class DefaultClassUnloadingContext : public ClassUnloadingContext {

I don't understand why they need to be two classes, even after reading "These are the reason for the class hierarchy for...". The reference to future/other PR(s) in the description doesn't really help -- it's unclear what is *necessary* for the current PR and what is preparation for future PR(s).

src/hotspot/share/gc/shared/classUnloadingContext.hpp line 95:

> 93: };
> 94: 
> 95: #endif // SHARE_GC_SHARED_CLASSUNLOADINGCONTEXT_HPP

Seems missing a newline.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16759#discussion_r1406262742
PR Review Comment: https://git.openjdk.org/jdk/pull/16759#discussion_r1406264755
PR Review Comment: https://git.openjdk.org/jdk/pull/16759#discussion_r1406282829
PR Review Comment: https://git.openjdk.org/jdk/pull/16759#discussion_r1406283473

From wkemper at openjdk.org  Mon Nov 27 20:34:26 2023
From: wkemper at openjdk.org (William Kemper)
Date: Mon, 27 Nov 2023 20:34:26 GMT
Subject: RFR: Merge openjdk/jdk:master [v2]
In-Reply-To: <E1vD7QOVhProkE_vbpQGYMiDP4xecIJ2L3vpknQbjWk=.6f9af4aa-e706-4a35-b189-ba3f700dd4f8@github.com>
References: <E1vD7QOVhProkE_vbpQGYMiDP4xecIJ2L3vpknQbjWk=.6f9af4aa-e706-4a35-b189-ba3f700dd4f8@github.com>
Message-ID: <Z5lG3oXXifuQqU7_9xzCgJDIU4OCdEr6DDbDNGXnAmw=.0082531a-69c3-401e-b5cb-4bc11d5f3f46@github.com>

> Merges tag jdk-22+25

William Kemper has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase.

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

Changes:
  - all: https://git.openjdk.org/shenandoah/pull/362/files
  - new: https://git.openjdk.org/shenandoah/pull/362/files/e47cf611..e47cf611

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

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

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

From wkemper at openjdk.org  Mon Nov 27 20:34:29 2023
From: wkemper at openjdk.org (William Kemper)
Date: Mon, 27 Nov 2023 20:34:29 GMT
Subject: Integrated: Merge openjdk/jdk:master
In-Reply-To: <E1vD7QOVhProkE_vbpQGYMiDP4xecIJ2L3vpknQbjWk=.6f9af4aa-e706-4a35-b189-ba3f700dd4f8@github.com>
References: <E1vD7QOVhProkE_vbpQGYMiDP4xecIJ2L3vpknQbjWk=.6f9af4aa-e706-4a35-b189-ba3f700dd4f8@github.com>
Message-ID: <mZH3o3hTEgu1oCd4Q9k3OiO5mYIIoN2QHYfou9gRWp0=.b53e98a3-a186-489b-879f-90db8604efd9@github.com>

On Thu, 23 Nov 2023 14:09:50 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Merges tag jdk-22+25

This pull request has now been integrated.

Changeset: baa7b18e
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.org/shenandoah/commit/baa7b18ee6c9872be65db1078bb1d1101baa14a9
Stats:     15946 lines in 483 files changed: 8945 ins; 3487 del; 3514 mod

Merge

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

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

From mdoerr at openjdk.org  Mon Nov 27 21:59:27 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Mon, 27 Nov 2023 21:59:27 GMT
Subject: RFR: 8320807: [PPC64][ZGC] C1 generates wrong code for atomics
Message-ID: <v-FCLDOczU-2OY24-dq1ntRH75OUI2Soe6mOQuu8io4=.9c79f615-4766-441c-8667-3ee4307578e4@github.com>

Debugging test failures on PPC64 in java/lang/Thread/virtual/stress/Skynet.java#ZGenerational has shown that the ldarx+stdcx_ loop for uncompressed Oops in `LIR_Assembler::atomic_op` is wrong: `__ mr(Rtmp, Robj);` is inside of the ldarx+stdcx_ loop, but must be outside of it. Repeated execution leads to wrong store value.
In addition, zBarrierSetC1.cpp expects `cas_obj` and `xchg` to contain all necessary memory barriers. That doesn't fit to the current PPC64 design which inserts memory barriers on LIR level instead. I've changed this and moved them into the assembler code for all GCs.
While debugging, I have optimized out an unnecessary branch in `ZBarrierSetAssembler::store_barrier_medium`.

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

Commit messages:
 - [PPC64][ZGC] C1 generates wrong code for atomics

Changes: https://git.openjdk.org/jdk/pull/16835/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16835&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8320807
  Stats: 121 lines in 4 files changed: 42 ins; 70 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/16835.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16835/head:pull/16835

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

From shade at openjdk.org  Tue Nov 28 14:21:20 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 28 Nov 2023 14:21:20 GMT
Subject: RFR: 8320888: Shenandoah: Enable ShenandoahVerifyOptoBarriers in debug
 builds
Message-ID: <4V4ijEJlqyoqZ7UjiX3613qsBPw5R4k9yv9lv1eqcaw=.aee775ba-a393-4f2c-9978-8aac011317f9@github.com>

Flag cleanup. Current barrier verification code is opt-in, and it is selected for a few tests. For extra safety, we want to have it enabled by default in debug builds. This also simplifies test configurations.

Additional testing:
 - [x] Linux x86_64 server fastdebug, `hotspot_gc_shenandoah`
 - [x] Linux AArch64 server fastdebug, `hotspot_gc_shenandoah`
 - [ ] Linux x86_64 server fastdebug, `tier{1,2,3,4}` with `-XX:+UseShenandoahGC`
 - [ ] Linux AArch64 server fastdebug, `tier{1,2,3,4}` with `-XX:+UseShenandoahGC`

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

Commit messages:
 - Fix

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

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

From shade at openjdk.org  Tue Nov 28 15:46:17 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 28 Nov 2023 15:46:17 GMT
Subject: RFR: 8320907: Shenandoah: Remove ShenandoahSelfFixing flag
Message-ID: <EcRbhDl7tQL8BYdk-OoHXEye4_C6G2C_N4tCX_V9AkQ=.4849fcd1-bcc6-4998-91d5-495a00411dad@github.com>

We added `ShenandoahSelfFixing` flag during LRB work to exercise LRB mid-paths better during stress tests. Today, we do not need the flag. Actually, if we ever call LRB for the side-effect of updating the location (e.g. somewhere in roots), then disabling this flag would introduce more bugs. Therefore, we need to remove the flag and make self-fixing unconditional. 

Additional testing:
 - [x] MacOS AArch64 server fastdebug, `hotspot_gc_shenandoah`

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

Commit messages:
 - Fix

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

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

From wkemper at openjdk.org  Tue Nov 28 16:30:05 2023
From: wkemper at openjdk.org (William Kemper)
Date: Tue, 28 Nov 2023 16:30:05 GMT
Subject: RFR: 8320888: Shenandoah: Enable ShenandoahVerifyOptoBarriers in
 debug builds
In-Reply-To: <4V4ijEJlqyoqZ7UjiX3613qsBPw5R4k9yv9lv1eqcaw=.aee775ba-a393-4f2c-9978-8aac011317f9@github.com>
References: <4V4ijEJlqyoqZ7UjiX3613qsBPw5R4k9yv9lv1eqcaw=.aee775ba-a393-4f2c-9978-8aac011317f9@github.com>
Message-ID: <doUPUQeOpsokKvByVWeQMCUI5oqZes-pVK-T15lamL8=.8e46e11b-cd0c-43ce-b0ed-c0ef72d29048@github.com>

On Tue, 28 Nov 2023 12:40:41 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Flag cleanup. Current barrier verification code is opt-in, and it is selected for a few tests. For extra safety, we want to have it enabled by default in debug builds. This also simplifies test configurations.
> 
> Additional testing:
>  - [x] Linux x86_64 server fastdebug, `hotspot_gc_shenandoah`
>  - [x] Linux AArch64 server fastdebug, `hotspot_gc_shenandoah`
>  - [ ] Linux x86_64 server fastdebug, `tier{1,2,3,4}` with `-XX:+UseShenandoahGC`
>  - [ ] Linux AArch64 server fastdebug, `tier{1,2,3,4}` with `-XX:+UseShenandoahGC`

Marked as reviewed by wkemper (Author).

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

PR Review: https://git.openjdk.org/jdk/pull/16849#pullrequestreview-1753352215

From wkemper at openjdk.org  Tue Nov 28 16:31:04 2023
From: wkemper at openjdk.org (William Kemper)
Date: Tue, 28 Nov 2023 16:31:04 GMT
Subject: RFR: 8320907: Shenandoah: Remove ShenandoahSelfFixing flag
In-Reply-To: <EcRbhDl7tQL8BYdk-OoHXEye4_C6G2C_N4tCX_V9AkQ=.4849fcd1-bcc6-4998-91d5-495a00411dad@github.com>
References: <EcRbhDl7tQL8BYdk-OoHXEye4_C6G2C_N4tCX_V9AkQ=.4849fcd1-bcc6-4998-91d5-495a00411dad@github.com>
Message-ID: <xwxinykvBgdYW6s5OrcmDoIbto0Eqx_qGrOz52hKbhY=.9ceb34f9-7a1f-4602-9bfc-25ccc27e319a@github.com>

On Tue, 28 Nov 2023 15:40:24 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> We added `ShenandoahSelfFixing` flag during LRB work to exercise LRB mid-paths better during stress tests. Today, we do not need the flag. Actually, if we ever call LRB for the side-effect of updating the location (e.g. somewhere in roots), then disabling this flag would introduce more bugs. Therefore, we need to remove the flag and make self-fixing unconditional. 
> 
> Additional testing:
>  - [x] MacOS AArch64 server fastdebug, `hotspot_gc_shenandoah`

Marked as reviewed by wkemper (Author).

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

PR Review: https://git.openjdk.org/jdk/pull/16855#pullrequestreview-1753353777

From wkemper at openjdk.org  Tue Nov 28 16:44:37 2023
From: wkemper at openjdk.org (William Kemper)
Date: Tue, 28 Nov 2023 16:44:37 GMT
Subject: RFR: 8320913: GenShen: Bootstrap 21u backports repo
Message-ID: <wMKS5O5c-5rWrQ7l6C6rf64RNpgLbXswk-7EtDMZv4E=.ea46c327-1697-480c-a372-749cafbc84e3@github.com>

Merges the generational mode for Shenandoah to a jdk21u based repo.

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

Commit messages:
 - Remove corretto files
 - Add a generational mode to the Shenandoah garbage collector
 - 8314610: hotspot can't compile with the latest of gtest because of <iomanip>

Changes: https://git.openjdk.org/shenandoah-jdk21u/pull/1/files
 Webrev: https://webrevs.openjdk.org/?repo=shenandoah-jdk21u&pr=1&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8320913
  Stats: 21645 lines in 219 files changed: 19682 ins; 930 del; 1033 mod
  Patch: https://git.openjdk.org/shenandoah-jdk21u/pull/1.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah-jdk21u.git pull/1/head:pull/1

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

From zgu at openjdk.org  Tue Nov 28 16:50:09 2023
From: zgu at openjdk.org (Zhengyu Gu)
Date: Tue, 28 Nov 2023 16:50:09 GMT
Subject: RFR: 8320907: Shenandoah: Remove ShenandoahSelfFixing flag
In-Reply-To: <EcRbhDl7tQL8BYdk-OoHXEye4_C6G2C_N4tCX_V9AkQ=.4849fcd1-bcc6-4998-91d5-495a00411dad@github.com>
References: <EcRbhDl7tQL8BYdk-OoHXEye4_C6G2C_N4tCX_V9AkQ=.4849fcd1-bcc6-4998-91d5-495a00411dad@github.com>
Message-ID: <WQz-FBKe_o8jqc1v7giU-6LaNUXAx2cUDr46v7YMMOU=.f0e77306-523f-4c68-9ff3-df8e1c95c352@github.com>

On Tue, 28 Nov 2023 15:40:24 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> We added `ShenandoahSelfFixing` flag during LRB work to exercise LRB mid-paths better during stress tests. Today, we do not need the flag. Actually, if we ever call LRB for the side-effect of updating the location (e.g. somewhere in roots), then disabling this flag would introduce more bugs. Therefore, we need to remove the flag and make self-fixing unconditional. 
> 
> 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/16855#pullrequestreview-1753394728

From shade at openjdk.org  Tue Nov 28 17:52:21 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 28 Nov 2023 17:52:21 GMT
Subject: RFR: 8320877: Shenandoah: Remove ShenandoahUnloadClassesFrequency
 support
Message-ID: <La397iKMbwNiZP4jtclteabx4qwQKXIrhrzzP_SDfcc=.a55c7a05-95e8-47f4-b46f-83127b769599@github.com>

Flag cleanup. `ShenandoahUnloadClassesFrequency` was added long time ago when Shenandoah did not support concurrent class unloading. We kept it in to simplify backports. At this point, most releases support concurrent class unloading, and there is no reason to keep the flag in. The default is "1" since [JDK-8228720](https://bugs.openjdk.org/browse/JDK-8228720).

Additional testing:
 - [x] MacOS AArch64 server fastdebug, `hotspot_gc_shenandoah`

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

Commit messages:
 - Revert incorrect cleanup
 - More cleanups
 - Fix

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

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

From wkemper at openjdk.org  Tue Nov 28 17:52:21 2023
From: wkemper at openjdk.org (William Kemper)
Date: Tue, 28 Nov 2023 17:52:21 GMT
Subject: RFR: 8320877: Shenandoah: Remove ShenandoahUnloadClassesFrequency
 support
In-Reply-To: <La397iKMbwNiZP4jtclteabx4qwQKXIrhrzzP_SDfcc=.a55c7a05-95e8-47f4-b46f-83127b769599@github.com>
References: <La397iKMbwNiZP4jtclteabx4qwQKXIrhrzzP_SDfcc=.a55c7a05-95e8-47f4-b46f-83127b769599@github.com>
Message-ID: <BZD7Mit-CIOZUKjV1EYkznnmOuMV7jDLSjiBIE2RqQo=.5cd92eff-aa4d-440b-bd71-95aea9e8e212@github.com>

On Tue, 28 Nov 2023 12:05:16 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Flag cleanup. `ShenandoahUnloadClassesFrequency` was added long time ago when Shenandoah did not support concurrent class unloading. We kept it in to simplify backports. At this point, most releases support concurrent class unloading, and there is no reason to keep the flag in. The default is "1" since [JDK-8228720](https://bugs.openjdk.org/browse/JDK-8228720).
> 
> Additional testing:
>  - [x] MacOS AArch64 server fastdebug, `hotspot_gc_shenandoah`

Marked as reviewed by wkemper (Author).

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

PR Review: https://git.openjdk.org/jdk/pull/16847#pullrequestreview-1753348581

From ysr at openjdk.org  Tue Nov 28 18:18:23 2023
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Tue, 28 Nov 2023 18:18:23 GMT
Subject: RFR: 8316226: GenShen: Consider forcing auto-tenure age to be greater
 than 1
Message-ID: <FvXeeCS6jnc4iijeQR_zhDkqXpnL9dm3T-44Mggncz0=.4ced2a17-4a32-4d88-a051-b18051353bc6@github.com>

I've corrected some off-by-one issues with the existing computation of tenuring age that would cause premature promotion. Also fixed the support for "never tenure" and for an approximation of "always tenure", as well as fixing guardrails around the setting for the controlling flags for min and max tenuring age.

**Epilogue:** Testing with the Extremem configuration from Kelvin indicates that our current strategy for adapting the tenuring threshold based solely on historical mortality on a per-cohort basis falling below a preset is sub-optimal because it doesn't consider the twin costs of premature promotion of objects that might soon die, viz.
1. the shrinkage of young generation and concomitant increase in minor gc cycle frequency
2. the growth of old generation and concomitant increase in the major cycle frequency

The current algorithm tends to reduce the tenuring threshold too rapidly since it does not have much idea of future mortality of cohorts that are either promoted or identified for promotion in earlier cycles (but which may not have been promoted for other considerations such as garbage density). More commentary can be found in the ticket.

Specifically for the Extremem workload, we found that flipping the current setting of `ShenandoahGenerationalCensusIgnoreOldCohorts` to false softened this effect somewhat and improved the tenuring behavior a little, although it didn't match min=15,max=15, or min=7,max=7. The specjbb configuration wasn't affected much because objects didn't display long lifetimes and the current algorithm was able to find the appropriate low tenuring age (in reality varying the tenuring age made little difference here, although with smaller fixed size younger generations, it might start to show a difference).

As a result of all of this, I am planning to just check-in a minimal change for now, while I investigate further tweaks to this algorithm in a separate PR. In particular, to avoid sudden and surprising changes in behavior, I am still leaving `ShenandoahGenerationalCensusIgnoreOldCohorts` at its current `true` setting for now, although flipping it showed some benefits with the Extremem workload.

**Testing:**
- GHA & Codepipeline tests on x86 and aarch64
- also tested (including performance) with specjbb2015 and with extremem with default settings, min=2, min=max=7, min=max=15, never ternure (min=max=16), always tenure (min=max=1)

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

Commit messages:
 - Don't promote objects in the cohort that has high mortality; instead
 - Merge branch 'master' into min_tenuring
 - Merge branch 'master' into min_tenuring
 - We aren't currently set up to promote age 0 objects. Place a floor of 1
 - Correct a documentation comment
 - Comments in shenandoah_globals.hpp
 - Fix more edge cases
 - Merge branch 'master' into min_tenuring
 - Fix another couple of off-by-1's
 - MinTenuringAge cannot be less than 1
 - ... and 10 more: https://git.openjdk.org/shenandoah/compare/d80a17d5...7cb1d459

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

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

From ysr at openjdk.org  Tue Nov 28 18:19:15 2023
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Tue, 28 Nov 2023 18:19:15 GMT
Subject: RFR: 8320913: GenShen: Bootstrap 21u backports repo
In-Reply-To: <wMKS5O5c-5rWrQ7l6C6rf64RNpgLbXswk-7EtDMZv4E=.ea46c327-1697-480c-a372-749cafbc84e3@github.com>
References: <wMKS5O5c-5rWrQ7l6C6rf64RNpgLbXswk-7EtDMZv4E=.ea46c327-1697-480c-a372-749cafbc84e3@github.com>
Message-ID: <2AmSo6sYS71dK40yWPvOszkPNe06oheNs8nMO9FoiMw=.edd7c84e-b8ff-4403-bb0c-8a8b6d0ef5a5@github.com>

On Mon, 27 Nov 2023 20:18:52 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Merges the generational mode for Shenandoah to a jdk21u based repo.

I did a quick scan, and it looks good to me.

How does testing look? A brief testing note would be great.

Reviewed! ?

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

Marked as reviewed by ysr (Reviewer).

PR Review: https://git.openjdk.org/shenandoah-jdk21u/pull/1#pullrequestreview-1753580345

From kdnilsen at openjdk.org  Tue Nov 28 18:27:58 2023
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Tue, 28 Nov 2023 18:27:58 GMT
Subject: RFR: 8320913: GenShen: Bootstrap 21u backports repo
In-Reply-To: <wMKS5O5c-5rWrQ7l6C6rf64RNpgLbXswk-7EtDMZv4E=.ea46c327-1697-480c-a372-749cafbc84e3@github.com>
References: <wMKS5O5c-5rWrQ7l6C6rf64RNpgLbXswk-7EtDMZv4E=.ea46c327-1697-480c-a372-749cafbc84e3@github.com>
Message-ID: <V5rPICdwIH5pNZVYDnqzrN5Nzbbcq5WUJ4WXwy8n0zc=.14248fd8-5a1f-46e4-8189-038147498cad@github.com>

On Mon, 27 Nov 2023 20:18:52 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Merges the generational mode for Shenandoah to a jdk21u based repo.

Marked as reviewed by kdnilsen (no project role).

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

PR Review: https://git.openjdk.org/shenandoah-jdk21u/pull/1#pullrequestreview-1753598951

From kdnilsen at openjdk.org  Tue Nov 28 18:30:05 2023
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Tue, 28 Nov 2023 18:30:05 GMT
Subject: RFR: 8320877: Shenandoah: Remove ShenandoahUnloadClassesFrequency
 support
In-Reply-To: <La397iKMbwNiZP4jtclteabx4qwQKXIrhrzzP_SDfcc=.a55c7a05-95e8-47f4-b46f-83127b769599@github.com>
References: <La397iKMbwNiZP4jtclteabx4qwQKXIrhrzzP_SDfcc=.a55c7a05-95e8-47f4-b46f-83127b769599@github.com>
Message-ID: <Y5EQU90HXFOJugjldrOlJ7POALMW-nlSXT6083B2Sp8=.120ad887-7d3d-4588-9fb5-3ff455290d9f@github.com>

On Tue, 28 Nov 2023 12:05:16 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Flag cleanup. `ShenandoahUnloadClassesFrequency` was added long time ago when Shenandoah did not support concurrent class unloading. We kept it in to simplify backports. At this point, most releases support concurrent class unloading, and there is no reason to keep the flag in. The default is "1" since [JDK-8228720](https://bugs.openjdk.org/browse/JDK-8228720).
> 
> Additional testing:
>  - [x] MacOS AArch64 server fastdebug, `hotspot_gc_shenandoah`

Marked as reviewed by kdnilsen (no project role).

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

PR Review: https://git.openjdk.org/jdk/pull/16847#pullrequestreview-1753605554

From kdnilsen at openjdk.org  Tue Nov 28 18:31:06 2023
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Tue, 28 Nov 2023 18:31:06 GMT
Subject: RFR: 8320888: Shenandoah: Enable ShenandoahVerifyOptoBarriers in
 debug builds
In-Reply-To: <4V4ijEJlqyoqZ7UjiX3613qsBPw5R4k9yv9lv1eqcaw=.aee775ba-a393-4f2c-9978-8aac011317f9@github.com>
References: <4V4ijEJlqyoqZ7UjiX3613qsBPw5R4k9yv9lv1eqcaw=.aee775ba-a393-4f2c-9978-8aac011317f9@github.com>
Message-ID: <65DZRaGoYyRdchfgnNcIweLjK35xMJlrswDaXP-zIdA=.f9be9f05-cd6a-4e53-9640-b22bac03b0d2@github.com>

On Tue, 28 Nov 2023 12:40:41 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Flag cleanup. Current barrier verification code is opt-in, and it is selected for a few tests. For extra safety, we want to have it enabled by default in debug builds. This also simplifies test configurations.
> 
> Additional testing:
>  - [x] Linux x86_64 server fastdebug, `hotspot_gc_shenandoah`
>  - [x] Linux AArch64 server fastdebug, `hotspot_gc_shenandoah`
>  - [ ] Linux x86_64 server fastdebug, `tier{1,2,3,4}` with `-XX:+UseShenandoahGC`
>  - [ ] Linux AArch64 server fastdebug, `tier{1,2,3,4}` with `-XX:+UseShenandoahGC`

Marked as reviewed by kdnilsen (no project role).

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

PR Review: https://git.openjdk.org/jdk/pull/16849#pullrequestreview-1753612732

From kdnilsen at openjdk.org  Tue Nov 28 18:31:13 2023
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Tue, 28 Nov 2023 18:31:13 GMT
Subject: RFR: 8320907: Shenandoah: Remove ShenandoahSelfFixing flag
In-Reply-To: <EcRbhDl7tQL8BYdk-OoHXEye4_C6G2C_N4tCX_V9AkQ=.4849fcd1-bcc6-4998-91d5-495a00411dad@github.com>
References: <EcRbhDl7tQL8BYdk-OoHXEye4_C6G2C_N4tCX_V9AkQ=.4849fcd1-bcc6-4998-91d5-495a00411dad@github.com>
Message-ID: <ijMfAnSizp3qHdvt5uEAT6IBtxkGdW8oP1TLXQK5_9s=.bc54efbc-c4cf-4c69-895b-983e403eddaa@github.com>

On Tue, 28 Nov 2023 15:40:24 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> We added `ShenandoahSelfFixing` flag during LRB work to exercise LRB mid-paths better during stress tests. Today, we do not need the flag. Actually, if we ever call LRB for the side-effect of updating the location (e.g. somewhere in roots), then disabling this flag would introduce more bugs. Therefore, we need to remove the flag and make self-fixing unconditional. 
> 
> Additional testing:
>  - [x] MacOS AArch64 server fastdebug, `hotspot_gc_shenandoah`

Marked as reviewed by kdnilsen (no project role).

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

PR Review: https://git.openjdk.org/jdk/pull/16855#pullrequestreview-1753617205

From wkemper at openjdk.org  Tue Nov 28 21:36:47 2023
From: wkemper at openjdk.org (William Kemper)
Date: Tue, 28 Nov 2023 21:36:47 GMT
Subject: RFR: 8320913: GenShen: Bootstrap 21u backports repo
In-Reply-To: <2AmSo6sYS71dK40yWPvOszkPNe06oheNs8nMO9FoiMw=.edd7c84e-b8ff-4403-bb0c-8a8b6d0ef5a5@github.com>
References: <wMKS5O5c-5rWrQ7l6C6rf64RNpgLbXswk-7EtDMZv4E=.ea46c327-1697-480c-a372-749cafbc84e3@github.com>
 <2AmSo6sYS71dK40yWPvOszkPNe06oheNs8nMO9FoiMw=.edd7c84e-b8ff-4403-bb0c-8a8b6d0ef5a5@github.com>
Message-ID: <_meyLHhENdyMsIJfr1FJklpRglzYhU6OgHWMc7a7V1w=.50a3f658-b61a-4bc8-b39f-caca2131d0a4@github.com>

On Tue, 28 Nov 2023 18:16:20 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

> How does testing look?

This is the same patch originally applied to our corretto-21 repo, but I'll this PR through the pipeline just to be sure.

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

PR Comment: https://git.openjdk.org/shenandoah-jdk21u/pull/1#issuecomment-1830784944

From ysr at openjdk.org  Wed Nov 29 00:41:03 2023
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Wed, 29 Nov 2023 00:41:03 GMT
Subject: RFR: 8316226: GenShen: Consider forcing auto-tenure age to be
 greater than 1 [v2]
In-Reply-To: <FvXeeCS6jnc4iijeQR_zhDkqXpnL9dm3T-44Mggncz0=.4ced2a17-4a32-4d88-a051-b18051353bc6@github.com>
References: <FvXeeCS6jnc4iijeQR_zhDkqXpnL9dm3T-44Mggncz0=.4ced2a17-4a32-4d88-a051-b18051353bc6@github.com>
Message-ID: <TjfbqgvWTeitKGo5XJQNC8NB-OsX8G6kzj_cgTHnIrU=.1d375220-4ef5-41c0-9c3f-d0e7dfb35de2@github.com>

> I've corrected some off-by-one issues with the existing computation of tenuring age that would cause premature promotion. Also fixed the support for "never tenure" and for an approximation of "always tenure", as well as fixing guardrails around the setting for the controlling flags for min and max tenuring age.
> 
> **Epilogue:** Testing with the Extremem configuration from Kelvin indicates that our current strategy for adapting the tenuring threshold based solely on historical mortality on a per-cohort basis falling below a preset is sub-optimal because it doesn't consider the twin costs of premature promotion of objects that might soon die, viz.
> 1. the shrinkage of young generation and concomitant increase in minor gc cycle frequency
> 2. the growth of old generation and concomitant increase in the major cycle frequency
> 
> The current algorithm tends to reduce the tenuring threshold too rapidly since it does not have much idea of future mortality of cohorts that are either promoted or identified for promotion in earlier cycles (but which may not have been promoted for other considerations such as garbage density). More commentary can be found in the ticket.
> 
> Specifically for the Extremem workload, we found that flipping the current setting of `ShenandoahGenerationalCensusIgnoreOldCohorts` to false softened this effect somewhat and improved the tenuring behavior a little, although it didn't match min=15,max=15, or min=7,max=7. The specjbb configuration wasn't affected much because objects didn't display long lifetimes and the current algorithm was able to find the appropriate low tenuring age (in reality varying the tenuring age made little difference here, although with smaller fixed size younger generations, it might start to show a difference).
> 
> As a result of all of this, I am planning to just check-in a minimal change for now, while I investigate further tweaks to this algorithm in a separate PR. In particular, to avoid sudden and surprising changes in behavior, I am still leaving `ShenandoahGenerationalCensusIgnoreOldCohorts` at its current `true` setting for now, although flipping it showed some benefits with the Extremem workload.
> 
> **Testing:**
> - GHA & Codepipeline tests on x86 and aarch64
> - also tested (including performance) with specjbb2015 and with extremem with default settings, min=2, min=max=7, min=max=15, never ternure (min=max=16), always tenure (min=max=1)

Y. Srinivas Ramakrishna 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 21 additional commits since the last revision:

 - Merge branch 'master' into min_tenuring
 - Don't promote objects in the cohort that has high mortality; instead
   use the next older age to avoid premature promotion.
 - Merge branch 'master' into min_tenuring
 - Merge branch 'master' into min_tenuring
 - We aren't currently set up to promote age 0 objects. Place a floor of 1
   under the tenuring ages.
 - Correct a documentation comment
 - Comments in shenandoah_globals.hpp
 - Fix more edge cases
 - Merge branch 'master' into min_tenuring
 - Fix another couple of off-by-1's
 - ... and 11 more: https://git.openjdk.org/shenandoah/compare/853a5798...fb54fdd1

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

Changes:
  - all: https://git.openjdk.org/shenandoah/pull/359/files
  - new: https://git.openjdk.org/shenandoah/pull/359/files/7cb1d459..fb54fdd1

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

  Stats: 634945 lines in 1406 files changed: 91773 ins; 478677 del; 64495 mod
  Patch: https://git.openjdk.org/shenandoah/pull/359.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah.git pull/359/head:pull/359

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

From wkemper at openjdk.org  Wed Nov 29 00:44:45 2023
From: wkemper at openjdk.org (William Kemper)
Date: Wed, 29 Nov 2023 00:44:45 GMT
Subject: RFR: 8316226: GenShen: Consider forcing auto-tenure age to be
 greater than 1 [v2]
In-Reply-To: <TjfbqgvWTeitKGo5XJQNC8NB-OsX8G6kzj_cgTHnIrU=.1d375220-4ef5-41c0-9c3f-d0e7dfb35de2@github.com>
References: <FvXeeCS6jnc4iijeQR_zhDkqXpnL9dm3T-44Mggncz0=.4ced2a17-4a32-4d88-a051-b18051353bc6@github.com>
 <TjfbqgvWTeitKGo5XJQNC8NB-OsX8G6kzj_cgTHnIrU=.1d375220-4ef5-41c0-9c3f-d0e7dfb35de2@github.com>
Message-ID: <r7wgoH7px3x7rnIF38mKdEYuxGj0SBAbHsQ6OqJrYyg=.37ec7e16-d7a2-478a-bdaf-5b219ea6f040@github.com>

On Wed, 29 Nov 2023 00:41:03 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

>> I've corrected some off-by-one issues with the existing computation of tenuring age that would cause premature promotion. Also fixed the support for "never tenure" and for an approximation of "always tenure", as well as fixing guardrails around the setting for the controlling flags for min and max tenuring age.
>> 
>> **Epilogue:** Testing with the Extremem configuration from Kelvin indicates that our current strategy for adapting the tenuring threshold based solely on historical mortality on a per-cohort basis falling below a preset is sub-optimal because it doesn't consider the twin costs of premature promotion of objects that might soon die, viz.
>> 1. the shrinkage of young generation and concomitant increase in minor gc cycle frequency
>> 2. the growth of old generation and concomitant increase in the major cycle frequency
>> 
>> The current algorithm tends to reduce the tenuring threshold too rapidly since it does not have much idea of future mortality of cohorts that are either promoted or identified for promotion in earlier cycles (but which may not have been promoted for other considerations such as garbage density). More commentary can be found in the ticket.
>> 
>> Specifically for the Extremem workload, we found that flipping the current setting of `ShenandoahGenerationalCensusIgnoreOldCohorts` to false softened this effect somewhat and improved the tenuring behavior a little, although it didn't match min=15,max=15, or min=7,max=7. The specjbb configuration wasn't affected much because objects didn't display long lifetimes and the current algorithm was able to find the appropriate low tenuring age (in reality varying the tenuring age made little difference here, although with smaller fixed size younger generations, it might start to show a difference).
>> 
>> As a result of all of this, I am planning to just check-in a minimal change for now, while I investigate further tweaks to this algorithm in a separate PR. In particular, to avoid sudden and surprising changes in behavior, I am still leaving `ShenandoahGenerationalCensusIgnoreOldCohorts` at its current `true` setting for now, although flipping it showed some benefits with the Extremem workload.
>> 
>> **Testing:**
>> - GHA & Codepipeline tests on x86 and aarch64
>> - also tested (including performance) with specjbb2015 and with extremem with default settings, min=2, min=max=7, min=max=15, never ternure (min=max=16), always tenure (min=max=1)
>
> Y. Srinivas Ramakrishna 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 21 additional commits since the last revision:
> 
>  - Merge branch 'master' into min_tenuring
>  - Don't promote objects in the cohort that has high mortality; instead
>    use the next older age to avoid premature promotion.
>  - Merge branch 'master' into min_tenuring
>  - Merge branch 'master' into min_tenuring
>  - We aren't currently set up to promote age 0 objects. Place a floor of 1
>    under the tenuring ages.
>  - Correct a documentation comment
>  - Comments in shenandoah_globals.hpp
>  - Fix more edge cases
>  - Merge branch 'master' into min_tenuring
>  - Fix another couple of off-by-1's
>  - ... and 11 more: https://git.openjdk.org/shenandoah/compare/35ecdbdb...fb54fdd1

Marked as reviewed by wkemper (Committer).

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

PR Review: https://git.openjdk.org/shenandoah/pull/359#pullrequestreview-1754194361

From kdnilsen at openjdk.org  Wed Nov 29 16:13:06 2023
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Wed, 29 Nov 2023 16:13:06 GMT
Subject: RFR: 8316226: GenShen: Consider forcing auto-tenure age to be
 greater than 1 [v2]
In-Reply-To: <TjfbqgvWTeitKGo5XJQNC8NB-OsX8G6kzj_cgTHnIrU=.1d375220-4ef5-41c0-9c3f-d0e7dfb35de2@github.com>
References: <FvXeeCS6jnc4iijeQR_zhDkqXpnL9dm3T-44Mggncz0=.4ced2a17-4a32-4d88-a051-b18051353bc6@github.com>
 <TjfbqgvWTeitKGo5XJQNC8NB-OsX8G6kzj_cgTHnIrU=.1d375220-4ef5-41c0-9c3f-d0e7dfb35de2@github.com>
Message-ID: <egnf3QOFPuSR8drA0hPzkEmD_8YaXP6ZxL6lrZlztCU=.b4bc12fc-8479-4a34-8579-1cb2d4280608@github.com>

On Wed, 29 Nov 2023 00:41:03 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

>> I've corrected some off-by-one issues with the existing computation of tenuring age that would cause premature promotion. Also fixed the support for "never tenure" and for an approximation of "always tenure", as well as fixing guardrails around the setting for the controlling flags for min and max tenuring age.
>> 
>> **Epilogue:** Testing with the Extremem configuration from Kelvin indicates that our current strategy for adapting the tenuring threshold based solely on historical mortality on a per-cohort basis falling below a preset is sub-optimal because it doesn't consider the twin costs of premature promotion of objects that might soon die, viz.
>> 1. the shrinkage of young generation and concomitant increase in minor gc cycle frequency
>> 2. the growth of old generation and concomitant increase in the major cycle frequency
>> 
>> The current algorithm tends to reduce the tenuring threshold too rapidly since it does not have much idea of future mortality of cohorts that are either promoted or identified for promotion in earlier cycles (but which may not have been promoted for other considerations such as garbage density). More commentary can be found in the ticket.
>> 
>> Specifically for the Extremem workload, we found that flipping the current setting of `ShenandoahGenerationalCensusIgnoreOldCohorts` to false softened this effect somewhat and improved the tenuring behavior a little, although it didn't match min=15,max=15, or min=7,max=7. The specjbb configuration wasn't affected much because objects didn't display long lifetimes and the current algorithm was able to find the appropriate low tenuring age (in reality varying the tenuring age made little difference here, although with smaller fixed size younger generations, it might start to show a difference).
>> 
>> As a result of all of this, I am planning to just check-in a minimal change for now, while I investigate further tweaks to this algorithm in a separate PR. In particular, to avoid sudden and surprising changes in behavior, I am still leaving `ShenandoahGenerationalCensusIgnoreOldCohorts` at its current `true` setting for now, although flipping it showed some benefits with the Extremem workload.
>> 
>> **Testing:**
>> - GHA & Codepipeline tests on x86 and aarch64
>> - also tested (including performance) with specjbb2015 and with extremem with default settings, min=2, min=max=7, min=max=15, never ternure (min=max=16), always tenure (min=max=1)
>
> Y. Srinivas Ramakrishna 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 21 additional commits since the last revision:
> 
>  - Merge branch 'master' into min_tenuring
>  - Don't promote objects in the cohort that has high mortality; instead
>    use the next older age to avoid premature promotion.
>  - Merge branch 'master' into min_tenuring
>  - Merge branch 'master' into min_tenuring
>  - We aren't currently set up to promote age 0 objects. Place a floor of 1
>    under the tenuring ages.
>  - Correct a documentation comment
>  - Comments in shenandoah_globals.hpp
>  - Fix more edge cases
>  - Merge branch 'master' into min_tenuring
>  - Fix another couple of off-by-1's
>  - ... and 11 more: https://git.openjdk.org/shenandoah/compare/2786570c...fb54fdd1

Marked as reviewed by kdnilsen (Committer).

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

PR Review: https://git.openjdk.org/shenandoah/pull/359#pullrequestreview-1755659982

From wkemper at openjdk.org  Wed Nov 29 16:38:49 2023
From: wkemper at openjdk.org (William Kemper)
Date: Wed, 29 Nov 2023 16:38:49 GMT
Subject: RFR: 8320913: GenShen: Bootstrap 21u backports repo
In-Reply-To: <wMKS5O5c-5rWrQ7l6C6rf64RNpgLbXswk-7EtDMZv4E=.ea46c327-1697-480c-a372-749cafbc84e3@github.com>
References: <wMKS5O5c-5rWrQ7l6C6rf64RNpgLbXswk-7EtDMZv4E=.ea46c327-1697-480c-a372-749cafbc84e3@github.com>
Message-ID: <iWi6ArYh1MmtVdiBNRCQ4dmxUtHK2Ey4qzye5KySMAc=.0ba4c9e7-00bd-4306-a040-33f4d099eb3d@github.com>

On Mon, 27 Nov 2023 20:18:52 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Merges the generational mode for Shenandoah to a jdk21u based repo.

Pipeline tests all passed.

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

PR Comment: https://git.openjdk.org/shenandoah-jdk21u/pull/1#issuecomment-1832296281

From shade at openjdk.org  Wed Nov 29 17:03:23 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 29 Nov 2023 17:03:23 GMT
Subject: RFR: 8320969: Shenandoah: Enforce stable number of GC workers
Message-ID: <54bP7p1EQWWE8YXN94AlKVabtJUOFpw-wZ7fXOmxG_0=.7ad5f3d4-fe36-4ea3-8e38-0561020cc043@github.com>

See bug for rationale.

Additional testing:
 - [x] MacOS AArch64 server fastdebug, `hotspot_gc_shenandoah`
 - [x] Linux x86_64 server fastdebug, `tier{1,2,3}` with `-XX:+UseShenandoahGC`
 - [x] Linux AArch64 server fastdebug, `tier{1,2,3}` with `-XX:+UseShenandoahGC`

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

Commit messages:
 - No dynamic GC workers

Changes: https://git.openjdk.org/jdk/pull/16878/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16878&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8320969
  Stats: 206 lines in 5 files changed: 10 ins; 175 del; 21 mod
  Patch: https://git.openjdk.org/jdk/pull/16878.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16878/head:pull/16878

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

From rkennke at openjdk.org  Wed Nov 29 17:16:10 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Wed, 29 Nov 2023 17:16:10 GMT
Subject: RFR: 8320888: Shenandoah: Enable ShenandoahVerifyOptoBarriers in
 debug builds
In-Reply-To: <4V4ijEJlqyoqZ7UjiX3613qsBPw5R4k9yv9lv1eqcaw=.aee775ba-a393-4f2c-9978-8aac011317f9@github.com>
References: <4V4ijEJlqyoqZ7UjiX3613qsBPw5R4k9yv9lv1eqcaw=.aee775ba-a393-4f2c-9978-8aac011317f9@github.com>
Message-ID: <UeERqE70sV4eLvpTCSFJZsCMMFNfJNaP5HkFfq2MJhs=.48e6b44e-ce30-4527-90e6-39b16cb7a729@github.com>

On Tue, 28 Nov 2023 12:40:41 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Flag cleanup. Current barrier verification code is opt-in, and it is selected for a few tests. For extra safety, we want to have it enabled by default in debug builds. This also simplifies test configurations.
> 
> Additional testing:
>  - [x] Linux x86_64 server fastdebug, `hotspot_gc_shenandoah`
>  - [x] Linux AArch64 server fastdebug, `hotspot_gc_shenandoah`
>  - [x] Linux x86_64 server fastdebug, `tier{1,2,3,4}` with `-XX:+UseShenandoahGC`
>  - [x] Linux AArch64 server fastdebug, `tier{1,2,3,4}` with `-XX:+UseShenandoahGC`

Makes sense and looks good, thank you!

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

Marked as reviewed by rkennke (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16849#pullrequestreview-1755819547

From rkennke at openjdk.org  Wed Nov 29 17:18:07 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Wed, 29 Nov 2023 17:18:07 GMT
Subject: RFR: 8320877: Shenandoah: Remove ShenandoahUnloadClassesFrequency
 support
In-Reply-To: <La397iKMbwNiZP4jtclteabx4qwQKXIrhrzzP_SDfcc=.a55c7a05-95e8-47f4-b46f-83127b769599@github.com>
References: <La397iKMbwNiZP4jtclteabx4qwQKXIrhrzzP_SDfcc=.a55c7a05-95e8-47f4-b46f-83127b769599@github.com>
Message-ID: <q-l2UV2jyZnIloCRb4rEdvv1WdVCBJB6FGX8nnkX-hE=.578d42ce-2283-4783-8c40-eb8a1335f64f@github.com>

On Tue, 28 Nov 2023 12:05:16 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Flag cleanup. `ShenandoahUnloadClassesFrequency` was added long time ago when Shenandoah did not support concurrent class unloading. We kept it in to simplify backports. At this point, most releases support concurrent class unloading, and there is no reason to keep the flag in. The default is "1" since [JDK-8228720](https://bugs.openjdk.org/browse/JDK-8228720).
> 
> Additional testing:
>  - [x] MacOS AArch64 server fastdebug, `hotspot_gc_shenandoah`

Makes sense and looks good, thank you!

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

Marked as reviewed by rkennke (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16847#pullrequestreview-1755822674

From rkennke at openjdk.org  Wed Nov 29 17:19:04 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Wed, 29 Nov 2023 17:19:04 GMT
Subject: RFR: 8320907: Shenandoah: Remove ShenandoahSelfFixing flag
In-Reply-To: <EcRbhDl7tQL8BYdk-OoHXEye4_C6G2C_N4tCX_V9AkQ=.4849fcd1-bcc6-4998-91d5-495a00411dad@github.com>
References: <EcRbhDl7tQL8BYdk-OoHXEye4_C6G2C_N4tCX_V9AkQ=.4849fcd1-bcc6-4998-91d5-495a00411dad@github.com>
Message-ID: <NeGHiGle4cqI9wMVg0K2ryrLWm3jS4JnZLaj5RhtwB4=.2b2190d3-0065-4dce-a3f2-3c8d5c0c6c2d@github.com>

On Tue, 28 Nov 2023 15:40:24 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> We added `ShenandoahSelfFixing` flag during LRB work to exercise LRB mid-paths better during stress tests. Today, we do not need the flag. Actually, if we ever call LRB for the side-effect of updating the location (e.g. somewhere in roots), then disabling this flag would introduce more bugs. Therefore, we need to remove the flag and make self-fixing unconditional. 
> 
> Additional testing:
>  - [x] MacOS AArch64 server fastdebug, `hotspot_gc_shenandoah`

Looks good, thank you!

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

Marked as reviewed by rkennke (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16855#pullrequestreview-1755824941

From shade at openjdk.org  Wed Nov 29 17:25:16 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 29 Nov 2023 17:25:16 GMT
Subject: Integrated: 8320907: Shenandoah: Remove ShenandoahSelfFixing flag
In-Reply-To: <EcRbhDl7tQL8BYdk-OoHXEye4_C6G2C_N4tCX_V9AkQ=.4849fcd1-bcc6-4998-91d5-495a00411dad@github.com>
References: <EcRbhDl7tQL8BYdk-OoHXEye4_C6G2C_N4tCX_V9AkQ=.4849fcd1-bcc6-4998-91d5-495a00411dad@github.com>
Message-ID: <SOGIDPbfwvh5eXmWDhV_im6-S2KXKgOStF004OhP05w=.035c6501-8b35-4f89-a16b-45e5069c5fe7@github.com>

On Tue, 28 Nov 2023 15:40:24 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> We added `ShenandoahSelfFixing` flag during LRB work to exercise LRB mid-paths better during stress tests. Today, we do not need the flag. Actually, if we ever call LRB for the side-effect of updating the location (e.g. somewhere in roots), then disabling this flag would introduce more bugs. Therefore, we need to remove the flag and make self-fixing unconditional. 
> 
> Additional testing:
>  - [x] MacOS AArch64 server fastdebug, `hotspot_gc_shenandoah`

This pull request has now been integrated.

Changeset: 43c7f6a6
Author:    Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/43c7f6a673c2fa0b4dbec232e92b621619a98246
Stats:     7 lines in 3 files changed: 0 ins; 5 del; 2 mod

8320907: Shenandoah: Remove ShenandoahSelfFixing flag

Reviewed-by: wkemper, zgu, kdnilsen, rkennke

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

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

From shade at openjdk.org  Wed Nov 29 17:25:15 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 29 Nov 2023 17:25:15 GMT
Subject: RFR: 8320907: Shenandoah: Remove ShenandoahSelfFixing flag
In-Reply-To: <EcRbhDl7tQL8BYdk-OoHXEye4_C6G2C_N4tCX_V9AkQ=.4849fcd1-bcc6-4998-91d5-495a00411dad@github.com>
References: <EcRbhDl7tQL8BYdk-OoHXEye4_C6G2C_N4tCX_V9AkQ=.4849fcd1-bcc6-4998-91d5-495a00411dad@github.com>
Message-ID: <l0vXTa0SclpTUzXwtVJWzXCEsbuBMURkwEhM2HF87RA=.94c1a8ba-30cc-4b22-b415-8b9b1fa44999@github.com>

On Tue, 28 Nov 2023 15:40:24 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> We added `ShenandoahSelfFixing` flag during LRB work to exercise LRB mid-paths better during stress tests. Today, we do not need the flag. Actually, if we ever call LRB for the side-effect of updating the location (e.g. somewhere in roots), then disabling this flag would introduce more bugs. Therefore, we need to remove the flag and make self-fixing unconditional. 
> 
> Additional testing:
>  - [x] MacOS AArch64 server fastdebug, `hotspot_gc_shenandoah`

Thank you all!

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

PR Comment: https://git.openjdk.org/jdk/pull/16855#issuecomment-1832378026

From shade at openjdk.org  Wed Nov 29 17:28:24 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 29 Nov 2023 17:28:24 GMT
Subject: RFR: 8320877: Shenandoah: Remove ShenandoahUnloadClassesFrequency
 support
In-Reply-To: <La397iKMbwNiZP4jtclteabx4qwQKXIrhrzzP_SDfcc=.a55c7a05-95e8-47f4-b46f-83127b769599@github.com>
References: <La397iKMbwNiZP4jtclteabx4qwQKXIrhrzzP_SDfcc=.a55c7a05-95e8-47f4-b46f-83127b769599@github.com>
Message-ID: <Cla1nQMydKeTPjnOv98t6opQsDIc3GmoCa8AaESbre0=.4c6537b6-a448-466f-a100-e6352c2db7d9@github.com>

On Tue, 28 Nov 2023 12:05:16 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Flag cleanup. `ShenandoahUnloadClassesFrequency` was added long time ago when Shenandoah did not support concurrent class unloading. We kept it in to simplify backports. At this point, most releases support concurrent class unloading, and there is no reason to keep the flag in. The default is "1" since [JDK-8228720](https://bugs.openjdk.org/browse/JDK-8228720).
> 
> Additional testing:
>  - [x] MacOS AArch64 server fastdebug, `hotspot_gc_shenandoah`

Thanks!

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

PR Comment: https://git.openjdk.org/jdk/pull/16847#issuecomment-1832380194

From shade at openjdk.org  Wed Nov 29 17:28:25 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 29 Nov 2023 17:28:25 GMT
Subject: Integrated: 8320877: Shenandoah: Remove
 ShenandoahUnloadClassesFrequency support
In-Reply-To: <La397iKMbwNiZP4jtclteabx4qwQKXIrhrzzP_SDfcc=.a55c7a05-95e8-47f4-b46f-83127b769599@github.com>
References: <La397iKMbwNiZP4jtclteabx4qwQKXIrhrzzP_SDfcc=.a55c7a05-95e8-47f4-b46f-83127b769599@github.com>
Message-ID: <ucMHkbEkM68d-dtvEOba-gNDFtyMKcK2shU3Bb7C0bc=.662398d6-5b2a-4113-b373-5be0784d75bf@github.com>

On Tue, 28 Nov 2023 12:05:16 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Flag cleanup. `ShenandoahUnloadClassesFrequency` was added long time ago when Shenandoah did not support concurrent class unloading. We kept it in to simplify backports. At this point, most releases support concurrent class unloading, and there is no reason to keep the flag in. The default is "1" since [JDK-8228720](https://bugs.openjdk.org/browse/JDK-8228720).
> 
> Additional testing:
>  - [x] MacOS AArch64 server fastdebug, `hotspot_gc_shenandoah`

This pull request has now been integrated.

Changeset: b65ccff3
Author:    Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b65ccff357e2e294b027f693ceb3d25410236a6b
Stats:     37 lines in 5 files changed: 0 ins; 34 del; 3 mod

8320877: Shenandoah: Remove ShenandoahUnloadClassesFrequency support

Reviewed-by: wkemper, kdnilsen, rkennke

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

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

From ysr at openjdk.org  Wed Nov 29 17:31:05 2023
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Wed, 29 Nov 2023 17:31:05 GMT
Subject: RFR: 8320969: Shenandoah: Enforce stable number of GC workers
In-Reply-To: <54bP7p1EQWWE8YXN94AlKVabtJUOFpw-wZ7fXOmxG_0=.7ad5f3d4-fe36-4ea3-8e38-0561020cc043@github.com>
References: <54bP7p1EQWWE8YXN94AlKVabtJUOFpw-wZ7fXOmxG_0=.7ad5f3d4-fe36-4ea3-8e38-0561020cc043@github.com>
Message-ID: <M-oqVJjajkXHcq5njW7ypIP2lDau6k1rSug3d0ZF-MU=.270039c4-afb9-4dd7-8bfb-cf4f4a4b4d20@github.com>

On Wed, 29 Nov 2023 11:01:32 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> See bug for rationale.
> 
> Additional testing:
>  - [x] MacOS AArch64 server fastdebug, `hotspot_gc_shenandoah`
>  - [x] Linux x86_64 server fastdebug, `tier{1,2,3}` with `-XX:+UseShenandoahGC`
>  - [x] Linux AArch64 server fastdebug, `tier{1,2,3}` with `-XX:+UseShenandoahGC`

@shipilev can you share any performance numbers with this change? The infra to modify the number of threads per phase would seem to be useful for adaptively changing the number of threads, specializing the per-GC/collector/phase policy for doing so, instead of removing it entirely. The problem you point out with the existing implementation was that it deferred completely to the shared policy; couldn't we just specialize that for Shenandoah or Generational Shenandoah (and for now just fix the number of workers at the values you chose here, but allow this to be more intelligently adapted in the future)?

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

PR Comment: https://git.openjdk.org/jdk/pull/16878#issuecomment-1832388065

From ysr at openjdk.org  Wed Nov 29 17:43:47 2023
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Wed, 29 Nov 2023 17:43:47 GMT
Subject: RFR: 8316226: GenShen: Consider forcing auto-tenure age to be
 greater than 1 [v2]
In-Reply-To: <TjfbqgvWTeitKGo5XJQNC8NB-OsX8G6kzj_cgTHnIrU=.1d375220-4ef5-41c0-9c3f-d0e7dfb35de2@github.com>
References: <FvXeeCS6jnc4iijeQR_zhDkqXpnL9dm3T-44Mggncz0=.4ced2a17-4a32-4d88-a051-b18051353bc6@github.com>
 <TjfbqgvWTeitKGo5XJQNC8NB-OsX8G6kzj_cgTHnIrU=.1d375220-4ef5-41c0-9c3f-d0e7dfb35de2@github.com>
Message-ID: <NtgBV9qKQZNGgGgOH5YKZCpVYy0wX-Qrcrbb9siFOTE=.a1acf177-42a0-4ca8-a363-9936999737b3@github.com>

On Wed, 29 Nov 2023 00:41:03 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

>> I've corrected some off-by-one issues with the existing computation of tenuring age that would cause premature promotion. Also fixed the support for "never tenure" and for an approximation of "always tenure", as well as fixing guardrails around the setting for the controlling flags for min and max tenuring age.
>> 
>> **Epilogue:** Testing with the Extremem configuration from Kelvin indicates that our current strategy for adapting the tenuring threshold based solely on historical mortality on a per-cohort basis falling below a preset is sub-optimal because it doesn't consider the twin costs of premature promotion of objects that might soon die, viz.
>> 1. the shrinkage of young generation and concomitant increase in minor gc cycle frequency
>> 2. the growth of old generation and concomitant increase in the major cycle frequency
>> 
>> The current algorithm tends to reduce the tenuring threshold too rapidly since it does not have much idea of future mortality of cohorts that are either promoted or identified for promotion in earlier cycles (but which may not have been promoted for other considerations such as garbage density). More commentary can be found in the ticket.
>> 
>> Specifically for the Extremem workload, we found that flipping the current setting of `ShenandoahGenerationalCensusIgnoreOldCohorts` to false softened this effect somewhat and improved the tenuring behavior a little, although it didn't match min=15,max=15, or min=7,max=7. The specjbb configuration wasn't affected much because objects didn't display long lifetimes and the current algorithm was able to find the appropriate low tenuring age (in reality varying the tenuring age made little difference here, although with smaller fixed size younger generations, it might start to show a difference).
>> 
>> As a result of all of this, I am planning to just check-in a minimal change for now, while I investigate further tweaks to this algorithm in a separate PR. In particular, to avoid sudden and surprising changes in behavior, I am still leaving `ShenandoahGenerationalCensusIgnoreOldCohorts` at its current `true` setting for now, although flipping it showed some benefits with the Extremem workload.
>> 
>> **Testing:**
>> - GHA & Codepipeline tests on x86 and aarch64
>> - also tested (including performance) with specjbb2015 and with extremem with default settings, min=2, min=max=7, min=max=15, never ternure (min=max=16), always tenure (min=max=1)
>
> Y. Srinivas Ramakrishna 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 21 additional commits since the last revision:
> 
>  - Merge branch 'master' into min_tenuring
>  - Don't promote objects in the cohort that has high mortality; instead
>    use the next older age to avoid premature promotion.
>  - Merge branch 'master' into min_tenuring
>  - Merge branch 'master' into min_tenuring
>  - We aren't currently set up to promote age 0 objects. Place a floor of 1
>    under the tenuring ages.
>  - Correct a documentation comment
>  - Comments in shenandoah_globals.hpp
>  - Fix more edge cases
>  - Merge branch 'master' into min_tenuring
>  - Fix another couple of off-by-1's
>  - ... and 11 more: https://git.openjdk.org/shenandoah/compare/ff5eb00f...fb54fdd1

Thanks for the reviews!

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

PR Comment: https://git.openjdk.org/shenandoah/pull/359#issuecomment-1832403847

From ysr at openjdk.org  Wed Nov 29 17:43:47 2023
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Wed, 29 Nov 2023 17:43:47 GMT
Subject: Integrated: 8316226: GenShen: Consider forcing auto-tenure age to be
 greater than 1
In-Reply-To: <FvXeeCS6jnc4iijeQR_zhDkqXpnL9dm3T-44Mggncz0=.4ced2a17-4a32-4d88-a051-b18051353bc6@github.com>
References: <FvXeeCS6jnc4iijeQR_zhDkqXpnL9dm3T-44Mggncz0=.4ced2a17-4a32-4d88-a051-b18051353bc6@github.com>
Message-ID: <REzOHXDBz7aL3FBqzmyV0Cspw4g7Tf2_n2gp59na-H4=.f8ee0535-7750-4696-b670-c6e6731c8cee@github.com>

On Wed, 15 Nov 2023 16:20:35 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

> I've corrected some off-by-one issues with the existing computation of tenuring age that would cause premature promotion. Also fixed the support for "never tenure" and for an approximation of "always tenure", as well as fixing guardrails around the setting for the controlling flags for min and max tenuring age.
> 
> **Epilogue:** Testing with the Extremem configuration from Kelvin indicates that our current strategy for adapting the tenuring threshold based solely on historical mortality on a per-cohort basis falling below a preset is sub-optimal because it doesn't consider the twin costs of premature promotion of objects that might soon die, viz.
> 1. the shrinkage of young generation and concomitant increase in minor gc cycle frequency
> 2. the growth of old generation and concomitant increase in the major cycle frequency
> 
> The current algorithm tends to reduce the tenuring threshold too rapidly since it does not have much idea of future mortality of cohorts that are either promoted or identified for promotion in earlier cycles (but which may not have been promoted for other considerations such as garbage density). More commentary can be found in the ticket.
> 
> Specifically for the Extremem workload, we found that flipping the current setting of `ShenandoahGenerationalCensusIgnoreOldCohorts` to false softened this effect somewhat and improved the tenuring behavior a little, although it didn't match min=15,max=15, or min=7,max=7. The specjbb configuration wasn't affected much because objects didn't display long lifetimes and the current algorithm was able to find the appropriate low tenuring age (in reality varying the tenuring age made little difference here, although with smaller fixed size younger generations, it might start to show a difference).
> 
> As a result of all of this, I am planning to just check-in a minimal change for now, while I investigate further tweaks to this algorithm in a separate PR. In particular, to avoid sudden and surprising changes in behavior, I am still leaving `ShenandoahGenerationalCensusIgnoreOldCohorts` at its current `true` setting for now, although flipping it showed some benefits with the Extremem workload.
> 
> **Testing:**
> - GHA & Codepipeline tests on x86 and aarch64
> - also tested (including performance) with specjbb2015 and with extremem with default settings, min=2, min=max=7, min=max=15, never ternure (min=max=16), always tenure (min=max=1)

This pull request has now been integrated.

Changeset: 2618aa69
Author:    Y. Srinivas Ramakrishna <ysr at openjdk.org>
URL:       https://git.openjdk.org/shenandoah/commit/2618aa699475a7ad62335daa5d3f48c98526f376
Stats:     48 lines in 2 files changed: 29 ins; 0 del; 19 mod

8316226: GenShen: Consider forcing auto-tenure age to be greater than 1

Reviewed-by: wkemper, kdnilsen

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

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

From wkemper at openjdk.org  Wed Nov 29 18:28:50 2023
From: wkemper at openjdk.org (William Kemper)
Date: Wed, 29 Nov 2023 18:28:50 GMT
Subject: Integrated: 8320913: GenShen: Bootstrap 21u backports repo
In-Reply-To: <wMKS5O5c-5rWrQ7l6C6rf64RNpgLbXswk-7EtDMZv4E=.ea46c327-1697-480c-a372-749cafbc84e3@github.com>
References: <wMKS5O5c-5rWrQ7l6C6rf64RNpgLbXswk-7EtDMZv4E=.ea46c327-1697-480c-a372-749cafbc84e3@github.com>
Message-ID: <0AR2IwLIcsj-yFitUyK9NH4hF7-87uf7F1pyMtTwx9E=.5d42162b-b72b-4be2-b3ed-321052b0e4fa@github.com>

On Mon, 27 Nov 2023 20:18:52 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Merges the generational mode for Shenandoah to a jdk21u based repo.

This pull request has now been integrated.

Changeset: 08570451
Author:    William Kemper <wkemper at openjdk.org>
Committer: Y. Srinivas Ramakrishna <ysr at openjdk.org>
URL:       https://git.openjdk.org/shenandoah-jdk21u/commit/08570451baf61fcc3ab7e13cafe72458a06005bd
Stats:     21645 lines in 219 files changed: 19682 ins; 930 del; 1033 mod

8320913: GenShen: Bootstrap 21u backports repo

Reviewed-by: ysr, kdnilsen

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

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

From shade at openjdk.org  Wed Nov 29 18:34:03 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 29 Nov 2023 18:34:03 GMT
Subject: RFR: 8320913: GenShen: Bootstrap 21u backports repo
In-Reply-To: <wMKS5O5c-5rWrQ7l6C6rf64RNpgLbXswk-7EtDMZv4E=.ea46c327-1697-480c-a372-749cafbc84e3@github.com>
References: <wMKS5O5c-5rWrQ7l6C6rf64RNpgLbXswk-7EtDMZv4E=.ea46c327-1697-480c-a372-749cafbc84e3@github.com>
Message-ID: <xolV6Rd9xoXl7ojPChsq8U70PyXyMk87JUIxc4rd_9M=.f06749ab-2644-4271-bcfe-2d99a0c0f3d5@github.com>

On Mon, 27 Nov 2023 20:18:52 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Merges the generational mode for Shenandoah to a jdk21u based repo.

> /sponsor needs to be done by @shipilev or @rkennke?

LOL, this is the first time I see bot misinterprets the command like this. ? 
Another thing we should try some time:

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

PR Comment: https://git.openjdk.org/shenandoah-jdk21u/pull/1#issuecomment-1832481806

From rkennke at openjdk.org  Wed Nov 29 18:40:20 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Wed, 29 Nov 2023 18:40:20 GMT
Subject: RFR: 8320913: GenShen: Bootstrap 21u backports repo
In-Reply-To: <iWi6ArYh1MmtVdiBNRCQ4dmxUtHK2Ey4qzye5KySMAc=.0ba4c9e7-00bd-4306-a040-33f4d099eb3d@github.com>
References: <wMKS5O5c-5rWrQ7l6C6rf64RNpgLbXswk-7EtDMZv4E=.ea46c327-1697-480c-a372-749cafbc84e3@github.com>
 <iWi6ArYh1MmtVdiBNRCQ4dmxUtHK2Ey4qzye5KySMAc=.0ba4c9e7-00bd-4306-a040-33f4d099eb3d@github.com>
Message-ID: <d_v8IWsqIdvh4_u2svzNgt088C3znxPwaucADX5cdP4=.acce5887-84c9-4a87-9ce4-7f90cd3c40cf@github.com>

On Wed, 29 Nov 2023 16:36:14 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> Merges the generational mode for Shenandoah to a jdk21u based repo.
>
> Pipeline tests all passed.

We should make @earthling-amzn a committer. @ysramakrishna and @kdnilsen already are (that's why @ysramakrishna could accidentally sponsor it).

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

PR Comment: https://git.openjdk.org/shenandoah-jdk21u/pull/1#issuecomment-1832490226

From cslucas at openjdk.org  Wed Nov 29 19:30:24 2023
From: cslucas at openjdk.org (Cesar Soares Lucas)
Date: Wed, 29 Nov 2023 19:30:24 GMT
Subject: RFR: JDK-8241503: C2: Share MacroAssembler between mach nodes
 during code emission [v3]
In-Reply-To: <ExCrwPns55nw2P62UI3vzSVTmFCh3dzJq7u3Kugp9EA=.c20cd86c-2c16-4869-ba7f-76f2a53821d0@github.com>
References: <ExCrwPns55nw2P62UI3vzSVTmFCh3dzJq7u3Kugp9EA=.c20cd86c-2c16-4869-ba7f-76f2a53821d0@github.com>
Message-ID: <hvtbVfw1oUP70vZ0432X-3F1hHylcFqOH1xkJJ7SrAY=.af5e7218-7e02-42db-a03f-a7804024ba3a@github.com>

> # Description
> 
> Please review this PR with a patch to re-use the same C2_MacroAssembler object to emit all instructions in the same compilation unit.
> 
> Overall, the change is pretty simple. However, due to the renaming of the variable to access C2_MacroAssembler, from `_masm.` to `masm->`, and also some method prototype changes, the patch became quite large.
> 
> # Help Needed for Testing
> 
> I don't have access to all platforms necessary to test this. I hope some other folks can help with testing on `S390`, `RISC-V` and `PPC`.
> 
> # Testing status
> 
> ## tier1
> 
> |          |   Win   |   Mac   |  Linux  |
> |----------|---------|---------|---------|
> | ARM64    |         |         |         |
> | ARM32    |         |         |         |
> | x86      |         |         |         |
> | x64      |         |         |         |
> | PPC64    |         |         |         |
> | S390x    |         |         |         |
> | RiscV    |         |         |         |

Cesar Soares Lucas has updated the pull request incrementally with one additional commit since the last revision:

  Some inst_mark fixes; Catch up with master.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16484/files
  - new: https://git.openjdk.org/jdk/pull/16484/files/b56c98de..89a6dff3

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

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

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

From shade at openjdk.org  Wed Nov 29 20:18:23 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 29 Nov 2023 20:18:23 GMT
Subject: RFR: 8320888: Shenandoah: Enable ShenandoahVerifyOptoBarriers in
 debug builds
In-Reply-To: <4V4ijEJlqyoqZ7UjiX3613qsBPw5R4k9yv9lv1eqcaw=.aee775ba-a393-4f2c-9978-8aac011317f9@github.com>
References: <4V4ijEJlqyoqZ7UjiX3613qsBPw5R4k9yv9lv1eqcaw=.aee775ba-a393-4f2c-9978-8aac011317f9@github.com>
Message-ID: <q6jDvUGQiKIxSIyw25K_JmV_Zimha-fGKEe3o7citCw=.e93cce89-8230-464e-a7cc-f2cdc48c9446@github.com>

On Tue, 28 Nov 2023 12:40:41 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Flag cleanup. Current barrier verification code is opt-in, and it is selected for a few tests. For extra safety, we want to have it enabled by default in debug builds. This also simplifies test configurations.
> 
> Additional testing:
>  - [x] Linux x86_64 server fastdebug, `hotspot_gc_shenandoah`
>  - [x] Linux AArch64 server fastdebug, `hotspot_gc_shenandoah`
>  - [x] Linux x86_64 server fastdebug, `tier{1,2,3,4}` with `-XX:+UseShenandoahGC`
>  - [x] Linux AArch64 server fastdebug, `tier{1,2,3,4}` with `-XX:+UseShenandoahGC`

Thanks all!

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

PR Comment: https://git.openjdk.org/jdk/pull/16849#issuecomment-1832634200

From shade at openjdk.org  Wed Nov 29 20:18:23 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 29 Nov 2023 20:18:23 GMT
Subject: Integrated: 8320888: Shenandoah: Enable ShenandoahVerifyOptoBarriers
 in debug builds
In-Reply-To: <4V4ijEJlqyoqZ7UjiX3613qsBPw5R4k9yv9lv1eqcaw=.aee775ba-a393-4f2c-9978-8aac011317f9@github.com>
References: <4V4ijEJlqyoqZ7UjiX3613qsBPw5R4k9yv9lv1eqcaw=.aee775ba-a393-4f2c-9978-8aac011317f9@github.com>
Message-ID: <CH2y4Edx_IrdhvwUGfBJUoyfDyuFWDmol-XvGpjgIrA=.5da38d9d-f7a8-413e-b44e-96cf04e8031f@github.com>

On Tue, 28 Nov 2023 12:40:41 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Flag cleanup. Current barrier verification code is opt-in, and it is selected for a few tests. For extra safety, we want to have it enabled by default in debug builds. This also simplifies test configurations.
> 
> Additional testing:
>  - [x] Linux x86_64 server fastdebug, `hotspot_gc_shenandoah`
>  - [x] Linux AArch64 server fastdebug, `hotspot_gc_shenandoah`
>  - [x] Linux x86_64 server fastdebug, `tier{1,2,3,4}` with `-XX:+UseShenandoahGC`
>  - [x] Linux AArch64 server fastdebug, `tier{1,2,3,4}` with `-XX:+UseShenandoahGC`

This pull request has now been integrated.

Changeset: c8643176
Author:    Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c86431767e6802317dc2be6221a5d0990b976ddc
Stats:     39 lines in 4 files changed: 0 ins; 37 del; 2 mod

8320888: Shenandoah: Enable ShenandoahVerifyOptoBarriers in debug builds

Reviewed-by: wkemper, kdnilsen, rkennke

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

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

From wkemper at openjdk.org  Wed Nov 29 22:05:31 2023
From: wkemper at openjdk.org (William Kemper)
Date: Wed, 29 Nov 2023 22:05:31 GMT
Subject: RFR: Merge openjdk/jdk21u:master
Message-ID: <CHbuoaKl9AHDRK_BAZqfNfM_Mme2vuXjHB9SHNIVrkU=.0bf025c6-6d44-4473-ad90-57307fa2fb48@github.com>

Merge tip of jdk21u

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

Commit messages:
 - Merge 'openjdk-21u/master' into 'shenandoah-jdk21u/master'
 - 8320001: javac crashes while adding type annotations to the return type of a constructor
 - 8320601: ProblemList java/lang/invoke/lambda/LambdaFileEncodingSerialization.java on linux-all
 - 8320363: ppc64 TypeEntries::type_unknown logic looks wrong, missed optimization opportunity
 - 8315684: Parallelize sun/security/util/math/TestIntegerModuloP.java
 - 8315936: Parallelize gc/stress/TestStressG1Humongous.java test
 - 8316401: sun/tools/jhsdb/JStackStressTest.java failed with "InternalError: We should have found a thread that owns the anonymous lock"
 - 8318895: Deoptimization results in incorrect lightweight locking stack
 - 8318078: ADLC: pass ASSERT and PRODUCT flags
 - 8319120: Unbound ScopedValue.get() throws the wrong exception
 - ... and 59 more: https://git.openjdk.org/shenandoah-jdk21u/compare/08570451...7c145a52

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

Changes: https://git.openjdk.org/shenandoah-jdk21u/pull/2/files
  Stats: 17927 lines in 348 files changed: 11041 ins; 1810 del; 5076 mod
  Patch: https://git.openjdk.org/shenandoah-jdk21u/pull/2.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah-jdk21u.git pull/2/head:pull/2

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

From cslucas at openjdk.org  Wed Nov 29 22:40:35 2023
From: cslucas at openjdk.org (Cesar Soares Lucas)
Date: Wed, 29 Nov 2023 22:40:35 GMT
Subject: RFR: JDK-8241503: C2: Share MacroAssembler between mach nodes
 during code emission [v4]
In-Reply-To: <ExCrwPns55nw2P62UI3vzSVTmFCh3dzJq7u3Kugp9EA=.c20cd86c-2c16-4869-ba7f-76f2a53821d0@github.com>
References: <ExCrwPns55nw2P62UI3vzSVTmFCh3dzJq7u3Kugp9EA=.c20cd86c-2c16-4869-ba7f-76f2a53821d0@github.com>
Message-ID: <h1AmMexga4JM1boU-1EEIk0dX_7EHkxk9RD8V9myD9s=.b736a16c-09fd-4854-94b5-a488cb86f4e1@github.com>

> # Description
> 
> Please review this PR with a patch to re-use the same C2_MacroAssembler object to emit all instructions in the same compilation unit.
> 
> Overall, the change is pretty simple. However, due to the renaming of the variable to access C2_MacroAssembler, from `_masm.` to `masm->`, and also some method prototype changes, the patch became quite large.
> 
> # Help Needed for Testing
> 
> I don't have access to all platforms necessary to test this. I hope some other folks can help with testing on `S390`, `RISC-V` and `PPC`.
> 
> # Testing status
> 
> ## tier1
> 
> |          |   Win   |   Mac   |  Linux  |
> |----------|---------|---------|---------|
> | ARM64    |         |         |         |
> | ARM32    |         |         |         |
> | x86      |         |         |         |
> | x64      |         |         |         |
> | PPC64    |         |         |         |
> | S390x    |         |         |         |
> | RiscV    |         |         |         |

Cesar Soares Lucas has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:

 - Fix merge
 - Catch up with master branch.
   
   Merge remote-tracking branch 'origin/master' into reuse-macroasm
 - Some inst_mark fixes; Catch up with master.
 - Catch up with changes on master
 - Reuse same C2_MacroAssembler object to emit instructions.

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

Changes: https://git.openjdk.org/jdk/pull/16484/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16484&range=03
  Stats: 2433 lines in 60 files changed: 106 ins; 433 del; 1894 mod
  Patch: https://git.openjdk.org/jdk/pull/16484.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16484/head:pull/16484

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

From haosun at openjdk.org  Thu Nov 30 09:31:26 2023
From: haosun at openjdk.org (Hao Sun)
Date: Thu, 30 Nov 2023 09:31:26 GMT
Subject: RFR: JDK-8241503: C2: Share MacroAssembler between mach nodes
 during code emission [v4]
In-Reply-To: <h1AmMexga4JM1boU-1EEIk0dX_7EHkxk9RD8V9myD9s=.b736a16c-09fd-4854-94b5-a488cb86f4e1@github.com>
References: <ExCrwPns55nw2P62UI3vzSVTmFCh3dzJq7u3Kugp9EA=.c20cd86c-2c16-4869-ba7f-76f2a53821d0@github.com>
 <h1AmMexga4JM1boU-1EEIk0dX_7EHkxk9RD8V9myD9s=.b736a16c-09fd-4854-94b5-a488cb86f4e1@github.com>
Message-ID: <QxR5-i1pw6AYAwooADtSxVdjVcuKwQV8ahPv7bDp_G8=.b139b0f8-7d03-4b27-a883-69730d3c4be8@github.com>

On Wed, 29 Nov 2023 22:40:35 GMT, Cesar Soares Lucas <cslucas at openjdk.org> wrote:

>> # Description
>> 
>> Please review this PR with a patch to re-use the same C2_MacroAssembler object to emit all instructions in the same compilation unit.
>> 
>> Overall, the change is pretty simple. However, due to the renaming of the variable to access C2_MacroAssembler, from `_masm.` to `masm->`, and also some method prototype changes, the patch became quite large.
>> 
>> # Help Needed for Testing
>> 
>> I don't have access to all platforms necessary to test this. I hope some other folks can help with testing on `S390`, `RISC-V` and `PPC`.
>> 
>> # Testing status
>> 
>> ## tier1
>> 
>> |          |   Win   |   Mac   |  Linux  |
>> |----------|---------|---------|---------|
>> | ARM64    |         |         |         |
>> | ARM32    |         |         |         |
>> | x86      |         |         |         |
>> | x64      |         |         |         |
>> | PPC64    |         |         |         |
>> | S390x    |         |         |         |
>> | RiscV    |         |         |         |
>
> Cesar Soares Lucas has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:
> 
>  - Fix merge
>  - Catch up with master branch.
>    
>    Merge remote-tracking branch 'origin/master' into reuse-macroasm
>  - Some inst_mark fixes; Catch up with master.
>  - Catch up with changes on master
>  - Reuse same C2_MacroAssembler object to emit instructions.

We should update the copyright year for the following files:


src/hotspot/cpu/aarch64/gc/x/x_aarch64.ad
src/hotspot/cpu/arm/arm_32.ad
src/hotspot/cpu/ppc/gc/x/x_ppc.ad
src/hotspot/cpu/riscv/gc/x/x_riscv.ad
src/hotspot/cpu/x86/c2_intelJccErratum_x86.hpp
src/hotspot/cpu/x86/gc/x/x_x86_64.ad
src/hotspot/cpu/x86/x86_32.ad
src/hotspot/share/opto/c2_CodeStubs.hpp
src/hotspot/share/opto/constantTable.hpp

src/hotspot/cpu/aarch64/aarch64.ad line 2829:

> 2827:   enc_class aarch64_enc_ldrsbw(iRegI dst, memory1 mem) %{
> 2828:     Register dst_reg = as_Register($dst$$reg);
> 2829:     loadStore(masm, &MacroAssembler::ldrsbw, dst_reg, $mem->opcode(),

The block of code should be auto-generated by `ad_encode.m4` file. 
We'd better not edit these lines directly. Instead, we should update the m4 file accordingly.

src/hotspot/cpu/aarch64/aarch64_vector.ad line 122:

> 120:       }
> 121:       int imm4 = disp / mesize / Matcher::scalable_vector_reg_size(vector_elem_bt);
> 122:       (masm->*insn)(reg, Assembler::elemType_to_regVariant(vector_elem_bt), pg, Address(base, imm4));

this update is missing in the corresponding `aarch64_vector_ad.m4` file.
(that is, there is a mismatch between the ad file and the generated one.)

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

PR Review: https://git.openjdk.org/jdk/pull/16484#pullrequestreview-1756986982
PR Review Comment: https://git.openjdk.org/jdk/pull/16484#discussion_r1410387066
PR Review Comment: https://git.openjdk.org/jdk/pull/16484#discussion_r1410381293

From tschatzl at openjdk.org  Thu Nov 30 10:37:11 2023
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Thu, 30 Nov 2023 10:37:11 GMT
Subject: RFR: 8317809: Insertion of free code blobs into code cache can be
 very slow during class unloading [v3]
In-Reply-To: <ym4bAn9bR2uEMqltEKTgRltmBToMF0GVFIruX5CRTOM=.8209d394-bf68-4d4d-8e97-cea4a0d67c14@github.com>
References: <_dcFF70_w7IXSjb6w-HuHCBkPyS3a6NlzejtqdfdYnM=.74e0f9df-eca3-49b0-be68-2d5824c16003@github.com>
 <wPKk7I8G7gknAGGQhrOurDNO1ekzXk3HMxHhlW_S5oc=.ee4e09e7-b4eb-40a6-a149-7b5a30ff42f9@github.com>
 <ym4bAn9bR2uEMqltEKTgRltmBToMF0GVFIruX5CRTOM=.8209d394-bf68-4d4d-8e97-cea4a0d67c14@github.com>
Message-ID: <E1dsz9pz9qPSP-npcKNgdsmJyoNG1KnduRNXGfvfLuk=.3f8cef90-6b8a-4d6b-bf57-78fdd87842f3@github.com>

On Mon, 27 Nov 2023 14:53:34 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Thomas Schatzl has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:
>> 
>>  - Merge branch 'master' into mergeme
>>  - iwalulya review, naming
>>  - 8317809 Insert code blobs in a sorted fashion to exploit the finger-optimization when adding, making this procedure O(n) instead of O(n^2)
>>    
>>    Introduce a globally available ClassUnloadingContext that contains common methods pertaining to class and code unloading.
>>    GCs may use it to efficiently manage unlinked class loader datas and nmethods to allow use of common methods (unlink/merge).
>>    
>>    The steps typically are registering a new to be unlinked CLD/nmethod, and then purge its memory later. STW collectors perform
>>    this work in one big chunk taking the CodeCache_lock, for the entire duration, while concurrent collectors lock/unlock for every
>>    insertion to allow for concurrent users for the lock to progress.
>>    
>>    Some care has been taken to stay consistent with an "unloading = unlinking + purge" scheme; however particularly the existing
>>    CLD handling API (still) mixes unlinking and purging in its CLD::unload() call. To simplify this change that is mostly geared
>>    towards separating nmethod unlinking from purging, to make code blob freeing O(n) instead of O(n^2).
>>    
>>    Upcoming changes will
>>    * separate nmethod unregistering from nmethod purging to allow doing that in bulk (for the STW collectors); that can significantly
>>      reduce code purging time for the STW collectors.
>>    * better name the second stage of unlinking (called "cleaning" throughout, e.g. the work done in `G1CollectedHeap::complete_cleaning`)
>>    * untangle CLD unlinking and what's called "cleaning" now to allow moving more stuff into the second unlinking stage for better
>>      parallelism
>>    * G1: move some signifcant tasks from the remark pause to concurrent (unregistering nmethods, freeing code blobs and cld/metaspace purging)
>>    * Maybe move Serial/Parallel GC metaspace purging closer to other unlinking/purging code to keep things local and allow easier logging.
>>  - Only run test case on debug VMs, sufficient
>>  - 8320331 g1 full gc "during" verification accesses half-unloaded metadata
>
> src/hotspot/share/gc/shared/classUnloadingContext.hpp line 63:
> 
>> 61: };
>> 62: 
>> 63: class DefaultClassUnloadingContext : public ClassUnloadingContext {
> 
> I don't understand why they need to be two classes, even after reading "These are the reason for the class hierarchy for...". The reference to future/other PR(s) in the description doesn't really help -- it's unclear what is *necessary* for the current PR and what is preparation for future PR(s).

The base class is unnecessary for this change, but very nice to have for future changes. I'll just merge them for now, and separate them again later.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16759#discussion_r1410476983

From tschatzl at openjdk.org  Thu Nov 30 11:38:28 2023
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Thu, 30 Nov 2023 11:38:28 GMT
Subject: RFR: 8317809: Insertion of free code blobs into code cache can be
 very slow during class unloading [v4]
In-Reply-To: <_dcFF70_w7IXSjb6w-HuHCBkPyS3a6NlzejtqdfdYnM=.74e0f9df-eca3-49b0-be68-2d5824c16003@github.com>
References: <_dcFF70_w7IXSjb6w-HuHCBkPyS3a6NlzejtqdfdYnM=.74e0f9df-eca3-49b0-be68-2d5824c16003@github.com>
Message-ID: <2_ONmN3qxsdTIEJMbQhE82nBn10l_RnZm5-DZAmQn2I=.9ad49c74-3721-4299-8a9e-b8c1973eb494@github.com>

> Insert code blobs in a sorted fashion to exploit the finger-optimization when adding, making this procedure O(n) instead of O(n^2)
> 
> Introduces a globally available ClassUnloadingContext that contains common methods pertaining to class and code unloading. GCs may use it to efficiently manage unlinked class loader datas and nmethods to allow use of common methods (unlink/merge).
> 
> The steps typically are registering a new to be unlinked CLD/nmethod, and then purge its memory later. STW collectors perform this work in one big chunk taking the CodeCache_lock, for the entire duration, while concurrent collectors lock/unlock for every insertion to allow for concurrent users for the lock to progress.
> 
> Some care has been taken to stay consistent with an "unloading = unlinking + purge" scheme; however particularly the existing CLD handling API (still) mixes unlinking and purging in its CLD::unload() call. To simplify this change that is mostly geared towards separating nmethod unlinking from purging, to make code blob freeing O(n) instead of O(n^2).
> 
> Upcoming changes will
> * separate nmethod unregistering from nmethod purging to allow doing that in bulk (for the STW collectors); that can significantly reduce code purging time for the STW collectors.
> * better name the second stage of unlinking (called "cleaning" throughout, e.g. the work done in `G1CollectedHeap::complete_cleaning`)
> * untangle CLD unlinking and what's called "cleaning" now to allow moving more stuff into the second unlinking stage for better parallelism
> * G1: move some significant tasks from the remark pause to concurrent (unregistering nmethods, freeing code blobs and cld/metaspace purging)
> * Maybe move Serial/Parallel GC metaspace purging closer to other unlinking/purging code to keep things local and allow easier logging.
> 
> These are the reason for the class hierarchy for `ClassUnloadingContext`: the goal is to ultimately have about this phasing (for G1):
> 1. collect all dead CLDs, using the `register_unloading_class_loader_data` method *only*
> 2. parallelize the stuff in `ClassLoaderData::unload()` in one way or another, adding them to the `complete_cleaning` (parallel) phase.
> 3. `purge_nmethods`, `free_code_blobs` and the `remove_unlinked_nmethods_from_code_root_set` (from JDK-8317007) will be concurrent.
> 
> Particularly the split of `SystemDictionary::do_unloading` into "only" traversing the CLDs to find the dead ones and then in parallel process them in 2. above warrants a separate `ClassUnloadingCo...

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

 - remove trailing whitespace
 - fix indentation after recent commit
 - Address ayang/iwalulya review comments, remove inheritance in ClassUnloadingContext for now as unnecessary for this change, use iterators, other review comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16759/files
  - new: https://git.openjdk.org/jdk/pull/16759/files/e8c8477a..801426a2

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

  Stats: 103 lines in 9 files changed: 19 ins; 40 del; 44 mod
  Patch: https://git.openjdk.org/jdk/pull/16759.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16759/head:pull/16759

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

From wkemper at openjdk.org  Thu Nov 30 14:16:33 2023
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 30 Nov 2023 14:16:33 GMT
Subject: RFR: Merge openjdk/jdk:master
Message-ID: <QZyAbveBx3_fVR4LqFtj1XTKJ17fQglpGcmB08AtxjU=.fc1dc224-5e49-4741-a9c6-9ab326d40d85@github.com>

Merges tag jdk-22+26

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

Commit messages:
 - 8320945: problemlist tests failing on latest Windows 11 update
 - 8210410: Refactor java.util.Currency:i18n shell tests to plain java tests
 - 8320942: Only set openjdk-target when cross compiling linux-aarch64
 - 8320937: support latest VS2022 MSC_VER in abstract_vm_version.cpp
 - 8319444: Unhelpful failure output in TestLegalNotices
 - 8313816: Accessing jmethodID might lead to spurious crashes
 - 8320877: Shenandoah: Remove ShenandoahUnloadClassesFrequency support
 - 8320806: Augment test/langtools/tools/javac/versions/Versions.java for JDK 22 language changes
 - 8320940: Fix typo in java.lang.Double
 - 8320907: Shenandoah: Remove ShenandoahSelfFixing flag
 - ... and 102 more: https://git.openjdk.org/shenandoah/compare/e47cf611...ea6e92ed

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

Changes: https://git.openjdk.org/shenandoah/pull/363/files
  Stats: 16460 lines in 646 files changed: 11110 ins; 3130 del; 2220 mod
  Patch: https://git.openjdk.org/shenandoah/pull/363.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah.git pull/363/head:pull/363

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

From rkennke at openjdk.org  Thu Nov 30 15:59:16 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Thu, 30 Nov 2023 15:59:16 GMT
Subject: RFR: 8321123: [Shenandoah/JDK21] Fix repo permissions
Message-ID: <LZ4c1zcJRFtp0oOcZw2g_eh5Tl8_Gx922JPDz4LHScQ=.585df00e-fcfa-419e-9618-65d7d133cc27@github.com>

The Shenandoah/JDK21u repo has the wrong permissons: it inherits permissions from jdk-updates, but should use permission from she Shenandoah project instead.

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

Commit messages:
 - 8321123: [Shenandoah/JDK21] Fix repo permissions

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

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

From shade at openjdk.org  Thu Nov 30 16:16:41 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 30 Nov 2023 16:16:41 GMT
Subject: RFR: 8321120: Shenandoah: Remove ShenandoahElasticTLAB flag
Message-ID: <P8f66OTqbmkHO6YapjCxgX-LWR8cJOnpsK_KsckBZCo=.70d0af35-f36d-4e8b-aa86-b3f110ca7925@github.com>

We have added `ShenandoahElasticTLAB` a long time ago, to provide the escape hatch if elastic TLABs would misbehave. We have been running with elastic TLABs for years without problems. Taking care of elastic/non-elastic TLAB allocs adds to technical debt. 

Additional testing:
  - [x] hotspot_gc_shenandoah

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

Commit messages:
 - Remove stale comment as well
 - Fix

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

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

From shade at openjdk.org  Thu Nov 30 16:19:49 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 30 Nov 2023 16:19:49 GMT
Subject: RFR: 8321123: [Shenandoah/JDK21] Fix repo permissions
In-Reply-To: <LZ4c1zcJRFtp0oOcZw2g_eh5Tl8_Gx922JPDz4LHScQ=.585df00e-fcfa-419e-9618-65d7d133cc27@github.com>
References: <LZ4c1zcJRFtp0oOcZw2g_eh5Tl8_Gx922JPDz4LHScQ=.585df00e-fcfa-419e-9618-65d7d133cc27@github.com>
Message-ID: <ezvFxGgt4dDpyWyo2X81ns15Q5TnvOt27YXUDkpRhIY=.2bff2fcb-eff7-4c20-a1de-c459fa9bd5c4@github.com>

On Thu, 30 Nov 2023 15:53:07 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> The Shenandoah/JDK21u repo has the wrong permissons: it inherits permissions from jdk-updates, but should use permission from she Shenandoah project instead.

Marked as reviewed by shade (Reviewer).

Wait, no, the version is also incorrect. I would say it should be just `21`?

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

PR Review: https://git.openjdk.org/shenandoah-jdk21u/pull/3#pullrequestreview-1757850998
Changes requested by shade (Reviewer).

PR Review: https://git.openjdk.org/shenandoah-jdk21u/pull/3#pullrequestreview-1757851663

From rkennke at openjdk.org  Thu Nov 30 16:24:34 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Thu, 30 Nov 2023 16:24:34 GMT
Subject: RFR: 8321123: [Shenandoah/JDK21] Fix repo permissions [v2]
In-Reply-To: <LZ4c1zcJRFtp0oOcZw2g_eh5Tl8_Gx922JPDz4LHScQ=.585df00e-fcfa-419e-9618-65d7d133cc27@github.com>
References: <LZ4c1zcJRFtp0oOcZw2g_eh5Tl8_Gx922JPDz4LHScQ=.585df00e-fcfa-419e-9618-65d7d133cc27@github.com>
Message-ID: <paAF7onaNl4z36qyDemJnRX6-HwC7gzaqb0MjnzkCJM=.427cc0e1-a82d-476b-9ce9-097f151ef220@github.com>

> The Shenandoah/JDK21u repo has the wrong permissons: it inherits permissions from jdk-updates, but should use permission from she Shenandoah project instead.

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

  Fix version

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

Changes:
  - all: https://git.openjdk.org/shenandoah-jdk21u/pull/3/files
  - new: https://git.openjdk.org/shenandoah-jdk21u/pull/3/files/4edc6d73..32f68445

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

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

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

From shade at openjdk.org  Thu Nov 30 16:34:06 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 30 Nov 2023 16:34:06 GMT
Subject: RFR: 8321122: Shenandoah: Remove ShenandoahLoopOptsAfterExpansion flag
Message-ID: <Qx1RiCM0aLTjBwDMNJvHiBBBceXMFmsJ-QtA0CdkdzE=.06c7276c-d9d1-44fc-bdac-24fd2727d16d@github.com>

More flags cleanup. `ShenandoahLoopOptsAfterExpansion` was added long time ago to gate more aggressive barrier optimizations in C2. It was default since then. There seem to be no reason to keep it as the flag. Just checking, @rwestrel -- you don't need it anymore, right?

Additional testing:
 - [x] `hotspot_gc_shenandoah`

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

Commit messages:
 - Fix

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

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

From kdnilsen at openjdk.org  Thu Nov 30 16:38:16 2023
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Thu, 30 Nov 2023 16:38:16 GMT
Subject: RFR: 8321120: Shenandoah: Remove ShenandoahElasticTLAB flag
In-Reply-To: <P8f66OTqbmkHO6YapjCxgX-LWR8cJOnpsK_KsckBZCo=.70d0af35-f36d-4e8b-aa86-b3f110ca7925@github.com>
References: <P8f66OTqbmkHO6YapjCxgX-LWR8cJOnpsK_KsckBZCo=.70d0af35-f36d-4e8b-aa86-b3f110ca7925@github.com>
Message-ID: <n08o8epQ66mNwMv5H_ZQdaecI2JMNEbZky9ZkdpAhj0=.e8b33d23-f6fd-4c45-bb4d-64694fcf8a35@github.com>

On Thu, 30 Nov 2023 15:50:52 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> We have added `ShenandoahElasticTLAB` a long time ago, to provide the escape hatch if elastic TLABs would misbehave. We have been running with elastic TLABs for years without problems. Taking care of elastic/non-elastic TLAB allocs adds to technical debt. 
> 
> Additional testing:
>   - [x] hotspot_gc_shenandoah

I agree to make elastic tlab behavior the only supported configuration.  FWIW, GenShen code has not thoroughly tested with this flag disabled.

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

Marked as reviewed by kdnilsen (no project role).

PR Review: https://git.openjdk.org/jdk/pull/16907#pullrequestreview-1757903383

From kdnilsen at openjdk.org  Thu Nov 30 16:44:05 2023
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Thu, 30 Nov 2023 16:44:05 GMT
Subject: RFR: 8321122: Shenandoah: Remove ShenandoahLoopOptsAfterExpansion
 flag
In-Reply-To: <Qx1RiCM0aLTjBwDMNJvHiBBBceXMFmsJ-QtA0CdkdzE=.06c7276c-d9d1-44fc-bdac-24fd2727d16d@github.com>
References: <Qx1RiCM0aLTjBwDMNJvHiBBBceXMFmsJ-QtA0CdkdzE=.06c7276c-d9d1-44fc-bdac-24fd2727d16d@github.com>
Message-ID: <B2YLmBqNbMlT93IX2_ufFaqwffImTJ6FjzRvHLyiUGw=.d92989a9-59a2-4171-8ef3-739f4cba8484@github.com>

On Thu, 30 Nov 2023 16:00:17 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> More flags cleanup. `ShenandoahLoopOptsAfterExpansion` was added long time ago to gate more aggressive barrier optimizations in C2. It was default since then. There seem to be no reason to keep it as the flag. Just checking, @rwestrel -- you don't need it anymore, right?
> 
> Additional testing:
>  - [x] `hotspot_gc_shenandoah`

This looks good to me, though I don't have full understanding of all the relevant issues.

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

Marked as reviewed by kdnilsen (no project role).

PR Review: https://git.openjdk.org/jdk/pull/16908#pullrequestreview-1757916271

From wkemper at openjdk.org  Thu Nov 30 17:20:07 2023
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 30 Nov 2023 17:20:07 GMT
Subject: RFR: Merge openjdk/jdk:master [v2]
In-Reply-To: <QZyAbveBx3_fVR4LqFtj1XTKJ17fQglpGcmB08AtxjU=.fc1dc224-5e49-4741-a9c6-9ab326d40d85@github.com>
References: <QZyAbveBx3_fVR4LqFtj1XTKJ17fQglpGcmB08AtxjU=.fc1dc224-5e49-4741-a9c6-9ab326d40d85@github.com>
Message-ID: <Eme2VGHoLjIkR1TCQzuyJh5bAZeQ_EDxPtT6tM6Rwqs=.5ea0a60f-3961-43de-aeab-43480ba436ab@github.com>

> Merges tag jdk-22+26

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

 - Merge branch 'master' into merge-jdk-22+26
 - 8320945: problemlist tests failing on latest Windows 11 update
   
   Reviewed-by: lmesnik
 - 8210410: Refactor java.util.Currency:i18n shell tests to plain java tests
   
   Reviewed-by: naoto, lancea
 - 8320942: Only set openjdk-target when cross compiling linux-aarch64
   
   Reviewed-by: ihse, erikj
 - 8320937: support latest VS2022 MSC_VER in abstract_vm_version.cpp
   
   Reviewed-by: dholmes, shade
 - 8319444: Unhelpful failure output in TestLegalNotices
   
   Reviewed-by: hannesw, jjg
 - 8313816: Accessing jmethodID might lead to spurious crashes
   
   Reviewed-by: coleenp
 - 8320877: Shenandoah: Remove ShenandoahUnloadClassesFrequency support
   
   Reviewed-by: wkemper, kdnilsen, rkennke
 - 8320806: Augment test/langtools/tools/javac/versions/Versions.java for JDK 22 language changes
   
   Reviewed-by: jlahoda, vromero
 - 8320940: Fix typo in java.lang.Double
   
   Reviewed-by: rriggs, iris, shade, lancea, bpb
 - ... and 103 more: https://git.openjdk.org/shenandoah/compare/2618aa69...50d05f60

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

Changes: https://git.openjdk.org/shenandoah/pull/363/files
 Webrev: https://webrevs.openjdk.org/?repo=shenandoah&pr=363&range=01
  Stats: 16457 lines in 646 files changed: 11110 ins; 3127 del; 2220 mod
  Patch: https://git.openjdk.org/shenandoah/pull/363.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah.git pull/363/head:pull/363

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

From cslucas at openjdk.org  Thu Nov 30 17:38:16 2023
From: cslucas at openjdk.org (Cesar Soares Lucas)
Date: Thu, 30 Nov 2023 17:38:16 GMT
Subject: RFR: JDK-8241503: C2: Share MacroAssembler between mach nodes
 during code emission [v4]
In-Reply-To: <QxR5-i1pw6AYAwooADtSxVdjVcuKwQV8ahPv7bDp_G8=.b139b0f8-7d03-4b27-a883-69730d3c4be8@github.com>
References: <ExCrwPns55nw2P62UI3vzSVTmFCh3dzJq7u3Kugp9EA=.c20cd86c-2c16-4869-ba7f-76f2a53821d0@github.com>
 <h1AmMexga4JM1boU-1EEIk0dX_7EHkxk9RD8V9myD9s=.b736a16c-09fd-4854-94b5-a488cb86f4e1@github.com>
 <QxR5-i1pw6AYAwooADtSxVdjVcuKwQV8ahPv7bDp_G8=.b139b0f8-7d03-4b27-a883-69730d3c4be8@github.com>
Message-ID: <j71QjUvXG0HSy8PKg0MYzpHBZYJ3T31SdrRWutU0pN0=.e6e1988c-3b11-410f-aaee-523849360310@github.com>

On Thu, 30 Nov 2023 09:24:12 GMT, Hao Sun <haosun at openjdk.org> wrote:

>> Cesar Soares Lucas has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:
>> 
>>  - Fix merge
>>  - Catch up with master branch.
>>    
>>    Merge remote-tracking branch 'origin/master' into reuse-macroasm
>>  - Some inst_mark fixes; Catch up with master.
>>  - Catch up with changes on master
>>  - Reuse same C2_MacroAssembler object to emit instructions.
>
> src/hotspot/cpu/aarch64/aarch64.ad line 2829:
> 
>> 2827:   enc_class aarch64_enc_ldrsbw(iRegI dst, memory1 mem) %{
>> 2828:     Register dst_reg = as_Register($dst$$reg);
>> 2829:     loadStore(masm, &MacroAssembler::ldrsbw, dst_reg, $mem->opcode(),
> 
> The block of code should be auto-generated by `ad_encode.m4` file. 
> We'd better not edit these lines directly. Instead, we should update the m4 file accordingly.

Oops. I didn't see the comment there! Thank you for letting me know.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16484#discussion_r1411050332

From rkennke at openjdk.org  Thu Nov 30 17:48:21 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Thu, 30 Nov 2023 17:48:21 GMT
Subject: RFR: 8321123: [Shenandoah/JDK21] Fix repo permissions [v3]
In-Reply-To: <LZ4c1zcJRFtp0oOcZw2g_eh5Tl8_Gx922JPDz4LHScQ=.585df00e-fcfa-419e-9618-65d7d133cc27@github.com>
References: <LZ4c1zcJRFtp0oOcZw2g_eh5Tl8_Gx922JPDz4LHScQ=.585df00e-fcfa-419e-9618-65d7d133cc27@github.com>
Message-ID: <U_rvxocSwE-mjyw8QKhIA6SJhNDdjcLgnhx9rYFaO8g=.6475880c-ab34-4d1e-8121-7753a5072747@github.com>

> The Shenandoah/JDK21u repo has the wrong permissons: it inherits permissions from jdk-updates, but should use permission from she Shenandoah project instead.

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

  Allow committers to review

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

Changes:
  - all: https://git.openjdk.org/shenandoah-jdk21u/pull/3/files
  - new: https://git.openjdk.org/shenandoah-jdk21u/pull/3/files/32f68445..0a3b6306

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

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

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

From shade at openjdk.org  Thu Nov 30 17:50:54 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 30 Nov 2023 17:50:54 GMT
Subject: RFR: 8321123: [Shenandoah/JDK21] Fix repo permissions [v3]
In-Reply-To: <U_rvxocSwE-mjyw8QKhIA6SJhNDdjcLgnhx9rYFaO8g=.6475880c-ab34-4d1e-8121-7753a5072747@github.com>
References: <LZ4c1zcJRFtp0oOcZw2g_eh5Tl8_Gx922JPDz4LHScQ=.585df00e-fcfa-419e-9618-65d7d133cc27@github.com>
 <U_rvxocSwE-mjyw8QKhIA6SJhNDdjcLgnhx9rYFaO8g=.6475880c-ab34-4d1e-8121-7753a5072747@github.com>
Message-ID: <4Ga4SRMe-X7VM8f3xpIZ69YCsqWVVVXx8aQtJDwoXUo=.380cebec-e25a-4baf-96b8-cbb7b79cd6f8@github.com>

On Thu, 30 Nov 2023 17:48:21 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> The Shenandoah/JDK21u repo has the wrong permissons: it inherits permissions from jdk-updates, but should use permission from she Shenandoah project instead.
>
> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Allow committers to review

Marked as reviewed by shade (Reviewer).

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

PR Review: https://git.openjdk.org/shenandoah-jdk21u/pull/3#pullrequestreview-1758123140

From rkennke at openjdk.org  Thu Nov 30 17:59:30 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Thu, 30 Nov 2023 17:59:30 GMT
Subject: RFR: 8321123: [Shenandoah/JDK21] Fix repo permissions [v3]
In-Reply-To: <U_rvxocSwE-mjyw8QKhIA6SJhNDdjcLgnhx9rYFaO8g=.6475880c-ab34-4d1e-8121-7753a5072747@github.com>
References: <LZ4c1zcJRFtp0oOcZw2g_eh5Tl8_Gx922JPDz4LHScQ=.585df00e-fcfa-419e-9618-65d7d133cc27@github.com>
 <U_rvxocSwE-mjyw8QKhIA6SJhNDdjcLgnhx9rYFaO8g=.6475880c-ab34-4d1e-8121-7753a5072747@github.com>
Message-ID: <wjvG8Ll-kW7ORb4OkDVpTmchIkPqwphJYbX6lcjAhCI=.26d1632c-8c79-4c83-8c74-2a5f9f7b5f0f@github.com>

On Thu, 30 Nov 2023 17:48:21 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> The Shenandoah/JDK21u repo has the wrong permissons: it inherits permissions from jdk-updates, but should use permission from she Shenandoah project instead.
>
> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Allow committers to review

Thanks!

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

PR Comment: https://git.openjdk.org/shenandoah-jdk21u/pull/3#issuecomment-1834280070

From rkennke at openjdk.org  Thu Nov 30 17:59:31 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Thu, 30 Nov 2023 17:59:31 GMT
Subject: Integrated: 8321123: [Shenandoah/JDK21] Fix repo permissions
In-Reply-To: <LZ4c1zcJRFtp0oOcZw2g_eh5Tl8_Gx922JPDz4LHScQ=.585df00e-fcfa-419e-9618-65d7d133cc27@github.com>
References: <LZ4c1zcJRFtp0oOcZw2g_eh5Tl8_Gx922JPDz4LHScQ=.585df00e-fcfa-419e-9618-65d7d133cc27@github.com>
Message-ID: <ge05VTO1X1KnjSlQ0a2F3wzwS4B1X0rEIdLWQfv2BcA=.130d2194-5aba-44b7-b5a4-283b947b222f@github.com>

On Thu, 30 Nov 2023 15:53:07 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> The Shenandoah/JDK21u repo has the wrong permissons: it inherits permissions from jdk-updates, but should use permission from she Shenandoah project instead.

This pull request has now been integrated.

Changeset: 57fb4b2b
Author:    Roman Kennke <rkennke at openjdk.org>
URL:       https://git.openjdk.org/shenandoah-jdk21u/commit/57fb4b2bd49bc930e18b9713ba11f2c4a8457f05
Stats:     3 lines in 1 file changed: 0 ins; 0 del; 3 mod

8321123: [Shenandoah/JDK21] Fix repo permissions

Reviewed-by: shade

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

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

From ysr at openjdk.org  Thu Nov 30 20:14:10 2023
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Thu, 30 Nov 2023 20:14:10 GMT
Subject: RFR: 8321120: Shenandoah: Remove ShenandoahElasticTLAB flag
In-Reply-To: <P8f66OTqbmkHO6YapjCxgX-LWR8cJOnpsK_KsckBZCo=.70d0af35-f36d-4e8b-aa86-b3f110ca7925@github.com>
References: <P8f66OTqbmkHO6YapjCxgX-LWR8cJOnpsK_KsckBZCo=.70d0af35-f36d-4e8b-aa86-b3f110ca7925@github.com>
Message-ID: <KUYCp6yukOdT-onh9Ujv8rHNqCnWybea49w2obbHjfM=.66266c3b-4f2d-44f4-8ff9-fe9c47d00c43@github.com>

On Thu, 30 Nov 2023 15:50:52 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> We have added `ShenandoahElasticTLAB` a long time ago, to provide the escape hatch if elastic TLABs would misbehave. We have been running with elastic TLABs for years without problems. Taking care of elastic/non-elastic TLAB allocs adds to technical debt. 
> 
> Additional testing:
>   - [x] hotspot_gc_shenandoah

Marked as reviewed by ysr (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/16907#pullrequestreview-1758364128

From wkemper at openjdk.org  Thu Nov 30 23:17:23 2023
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 30 Nov 2023 23:17:23 GMT
Subject: RFR: Merge openjdk/jdk:master [v3]
In-Reply-To: <QZyAbveBx3_fVR4LqFtj1XTKJ17fQglpGcmB08AtxjU=.fc1dc224-5e49-4741-a9c6-9ab326d40d85@github.com>
References: <QZyAbveBx3_fVR4LqFtj1XTKJ17fQglpGcmB08AtxjU=.fc1dc224-5e49-4741-a9c6-9ab326d40d85@github.com>
Message-ID: <kMQv14SCPf4AQGovGQhESl_mnKKtGIxA5x-RenGdvig=.2ac4bc9a-de73-4618-a8cd-42d1cfd41bbc@github.com>

> Merges tag jdk-22+26

William Kemper 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:

  Merge remote-tracking branch 'shenandoah/master' into merge-jdk-22+26

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

Changes:
  - all: https://git.openjdk.org/shenandoah/pull/363/files
  - new: https://git.openjdk.org/shenandoah/pull/363/files/50d05f60..aae52834

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

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

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