From shade at openjdk.org  Fri Mar  1 18:11:59 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 1 Mar 2024 18:11:59 GMT
Subject: RFR: 8324649: Shenandoah: refactor implementation of free set
 [v14]
In-Reply-To: <DtAJtZcZPNv2FMbF9-FeJIT6T8Oio1TW9yYnw3cceF0=.ed94d2d3-39c2-4f8d-9e00-5dbd81683c93@github.com>
References: <VAkn0SrKYZWmnflpM8ZwVAXjUF1LjA0_FCBmRJJ4VSc=.c2f979bd-2957-434e-95ca-7b11b1573900@github.com>
 <DtAJtZcZPNv2FMbF9-FeJIT6T8Oio1TW9yYnw3cceF0=.ed94d2d3-39c2-4f8d-9e00-5dbd81683c93@github.com>
Message-ID: <PVrVW-I2bKkYzrdBafHAaWF8mw6WtANB3PoOZW5ekRw=.2ab54392-0f5b-4f6f-b5d7-7b7a9b6a0a97@github.com>

On Thu, 29 Feb 2024 19:10:21 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> Several objectives:
>> 1. Reduce humongous allocation failures by segregating regular regions from humongous regions
>> 2. Do not retire regions just because an allocation failed within the region if the memory remaining within the region is large enough to represent a LAB
>> 3. Track range of empty regions in addition to range of available regions in order to expedite humongous allocations
>> 4. Treat collector reserves as available for Mutator allocations after evacuation completes
>> 5. Improve encapsulation so as to enable an OldCollector reserve for future integration of generational Shenandoah
>> 
>> We have compared performance of existing FreeSet implementation with the proposed PR over a broad set of performance workloads and see that the impact is mostly neutral.
>> 
>> Comparing 105235.0 metrics from control, 220638.0 from experiment.
>> Compare: 0.589s
>>                           Most impacted benchmarks |                              Most impacted metrics
>> -------------------------------------------------------------------------------------------------------
>>                                  Shenandoah/jython |                                          cwr_total
>> 
>> 
>>                                 Only in experiment |                                    Only in control
>> -------------------------------------------------------------------------------------------------------
>>                  crypto.signverify/trigger_failure |                        crypto.rsa/cmr_thread_roots
>>                 extremem-large-31g/adjust_pointers |       scimark.sparse.small/concurrent_thread_roots
>>             extremem-large-31g/calculate_addresses |              xml.transform/concurrent_thread_roots
>>       crypto.signverify/class_unloading_rendezvous |                    mpegaudio/concurrent_weak_roots
>>                                   serial/cmr_total |                        crypto.rsa/ctr_thread_roots
>> 
>> Shenandoah
>> -------------------------------------------------------------------------------------------------------
>> +5.64% jython/cwr_total p=0.00037
>>   Control:      1.928ms (+/-272.40us)        170
>>   Test:         2.037ms (+/-322.73us)        344
>
> Kelvin Nilsen has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 60 commits:
> 
>  - Remove instrumentation and cleanup magic numbers
>    
>    Two places, I had used 63 when I should have used
>    _bits_per_array_element -1.
>  - Address 32-bit compile issues
>  - Fix 32-bit size formatting in log messages
>  - Fix white space
>  - Merge remote-tracking branch 'origin/master' into restructure-free-set
>  - Merge branch 'openjdk:master' into master
>  - Two bug fixes for better performance
>    
>    1. Collector reserve size is based on memory available within regions
>       rather than the region size (oops).
>    
>    2. If an attempt to allocate within a region fails and the region has
>       already provided the percentage presumed by ShenandoahEvacWaste,
>       retire this region.  This is motivated by observations that
>       otherwise, we end up with large numbers of regions that have only
>       a small amount of memory within them (e.g. 4k) and every allocation
>       request has to wade through all of these regions before it eventually
>       finds a region that has a sufficiently large amount of available
>       memory.  In the original Shenandoah free-set implementation, the
>       behavior was to retire the first time an allocation within that
>       regions fails, regardless of whether the region has already reached
>       the ShenandoahEvacWaste threshold.
>  - Fix off-by-one error in is_forward_consecutive_ones()
>  - Fix whitespace
>  - Bug fixes and performance improvements
>    
>    1. Correct off-b-one-error in count of trailingones
>    2. Speed up search for contiguous regions (for humongous allocations) by
>       sliding window instead of initiating new search each time
>    3. Bias regular region allocations to favor regions that are already
>       partially consumed
>    4. Fix bug in move_regions_from_collector_to_mutator which caused some
>       non-empty regions to be ignored.
>  - ... and 50 more: https://git.openjdk.org/jdk/compare/be2b92bd...1aa5a3e6

It is a very interesting piece of work, but it requires much more polishing before integrating.

I think at least `ShenandoahSimpleBitMap` needs unit tests, as its implementation is not obvious. See bitmap gtests as the example. Or maybe we can polish it enough to be obvious.

More cursory review comments:

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

> 418:                  req.type_string(),
> 419:                  byte_size_in_proper_unit(req.size() * HeapWordSize), proper_unit_for_byte_size(req.size() * HeapWordSize));
> 420: 

No need for this change?

src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp line 50:

> 48:   size_t element_bits = _bitmap[array_idx];
> 49:   size_t bit_number = start_idx % _bits_per_array_element;
> 50:   size_t the_bit = ((size_t) 0x01) << bit_number;

Here and later, we have a special macro for this, `nth_bit`.

src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp line 52:

> 50:   size_t the_bit = ((size_t) 0x01) << bit_number;
> 51:   size_t omit_mask = the_bit - 1;
> 52:   size_t mask = ((size_t) ((ssize_t) -1)) & omit_mask;

Same, we have `right_n_bits` to generate the masks like this.

src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp line 59:

> 57:   } else {
> 58:     size_t counted_ones;
> 59:     for (counted_ones = 0; element_bits & the_bit; counted_ones++) {

Here and later: this would likely trigger an implicit conversion warning. Do `(element_bits & the_bit) != 0`?

src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp line 67:

> 65: 
> 66: // Count consecutive ones in reverse order, starting from last_idx.  Requires that there is at least one zero
> 67: // between last_idx and index value zero, inclusive.

Here and later: This duplicates the documentation in header. No need to put it here, saves us from desyncs between duplicate comments.

src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp line 76:

> 74: 
> 75:   // All ones from bit 0 to the_bit
> 76:   size_t mask = (the_bit * 2) - 1;

It would be much cleaner with `right_n_bits`, I think.

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

> 101:     size_t exclude_mask = ((size_t) 0x1 << bit_number) - 1;
> 102:     size_t exact_mask = overreach_mask & ~exclude_mask;
> 103:     return (element_bits & exact_mask) == exact_mask? true: false;

Here and later: this is just `return (element_bits & exact_mask) == exact_mask;`

src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp line 162:

> 160:           ssize_t candidate_result = (array_idx * _bits_per_array_element) + bit_number;
> 161:           if (candidate_result < boundary_idx) return candidate_result;
> 162:           else return boundary_idx;

Here and later: Odd style for branch. It looks like this is just `MIN2(candidate_result, boundary_idx)`.

src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp line 168:

> 166:         }
> 167:       }
> 168:       assert(false, "should not reach here");

Just `ShouldNotReachHere()` then?

src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp line 319:

> 317: #else
> 318:   log_info(gc)("%6s: %10s %10s %10s", "index", "Mutator Bits", "Collector Bits", "NotFree Bits");
> 319: #endif

There is no need for `_LP64` here, just print with `%18s` unconditionally.

src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp line 388:

> 386: }
> 387: 
> 388: inline ssize_t ShenandoahRegionPartitions:: leftmost(ShenandoahFreeSetPartitionId which_partition) const {

Excess space after `::`.

src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp line 394:

> 392:     return _max;
> 393:   } else {
> 394:     // _membership[which_partition].is_set(idx) may not be true if we are shrinking the interval

...and? This comment is really confusing. What does it have to do with `leftmost`?

src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp line 892:

> 890:         //  1. Eventual collection set has fewer regions because we have packed newly allocated objects into fewer regions
> 891:         //  2. We preserve the "empty" regions longer into the GC cycle, reducing likelihood of allocation failures
> 892:         //     late in the GC cycle.

Be more terse about this. Maybe even add it to the description above the code. The large comments should not interrupt the flow of the code.

src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp line 1152:

> 1150:   _partitions.retire_range_from_partition(Mutator, beg, end);
> 1151: 
> 1152:   size_t total_humongous_size = ShenandoahHeapRegion::region_size_bytes() * num;

Lost the original comment. Also, where did the call to `notify_mutator_alloc_words` went?

src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp line 1372:

> 1370:     if (move_to_collector) {
> 1371:       // Note: In a previous implementation, regions were only placed into the survivor space (collector_is_free) if
> 1372:       // they were entirely empty.  I'm not sure I understand the rationale for that.  That alternative behavior would

We should not leave "I'm not sure..." comments in the code. I believe the reason is exactly what you stated below: we do not want to put evacuated objects (implicitly live) to the region that might be mostly garbage, thus prolonging the garbage lifetime.

src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp line 1541:

> 1539:   shenandoah_assert_heaplocked();
> 1540: 
> 1541:   // Allocation request is known to satisfy all memory budgeting constraints.

What does it mean?

src/hotspot/share/gc/shenandoah/shenandoahFreeSet.hpp line 68:

> 66:   // Count consecutive ones in forward order, starting from start_idx.  Requires that there is at least one zero
> 67:   // between start_idx and index value (_num_bits - 1), inclusive.
> 68:   size_t count_leading_ones(ssize_t start_idx) const;

Does the argument have to me `ssize_t`, not `size_t`? Is this because you want it to be signed?

src/hotspot/share/gc/shenandoah/shenandoahFullGC.cpp line 1089:

> 1087:     heap->heap_region_iterate(&post_compact);
> 1088:     heap->set_used(post_compact.get_live());
> 1089: 

Is this change necessary?

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

PR Review: https://git.openjdk.org/jdk/pull/17561#pullrequestreview-1911398216
PR Review Comment: https://git.openjdk.org/jdk/pull/17561#discussion_r1509144390
PR Review Comment: https://git.openjdk.org/jdk/pull/17561#discussion_r1509151821
PR Review Comment: https://git.openjdk.org/jdk/pull/17561#discussion_r1509153942
PR Review Comment: https://git.openjdk.org/jdk/pull/17561#discussion_r1509305137
PR Review Comment: https://git.openjdk.org/jdk/pull/17561#discussion_r1509301710
PR Review Comment: https://git.openjdk.org/jdk/pull/17561#discussion_r1509306601
PR Review Comment: https://git.openjdk.org/jdk/pull/17561#discussion_r1509318105
PR Review Comment: https://git.openjdk.org/jdk/pull/17561#discussion_r1509321462
PR Review Comment: https://git.openjdk.org/jdk/pull/17561#discussion_r1509322005
PR Review Comment: https://git.openjdk.org/jdk/pull/17561#discussion_r1509324302
PR Review Comment: https://git.openjdk.org/jdk/pull/17561#discussion_r1509326323
PR Review Comment: https://git.openjdk.org/jdk/pull/17561#discussion_r1509328606
PR Review Comment: https://git.openjdk.org/jdk/pull/17561#discussion_r1509336524
PR Review Comment: https://git.openjdk.org/jdk/pull/17561#discussion_r1509341993
PR Review Comment: https://git.openjdk.org/jdk/pull/17561#discussion_r1509350825
PR Review Comment: https://git.openjdk.org/jdk/pull/17561#discussion_r1509353034
PR Review Comment: https://git.openjdk.org/jdk/pull/17561#discussion_r1509148199
PR Review Comment: https://git.openjdk.org/jdk/pull/17561#discussion_r1509356010

From shade at openjdk.org  Fri Mar  1 18:11:59 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 1 Mar 2024 18:11:59 GMT
Subject: RFR: 8324649: Shenandoah: refactor implementation of free set
 [v14]
In-Reply-To: <pjoRaaHiLifEQUCMk_ZmClQxnnTAt_Un53krTS_nzYs=.0217fd7e-b405-4d40-9c0f-07b3d1c0fd20@github.com>
References: <VAkn0SrKYZWmnflpM8ZwVAXjUF1LjA0_FCBmRJJ4VSc=.c2f979bd-2957-434e-95ca-7b11b1573900@github.com>
 <VqvdjBK8YXO4luQRnXq9RUQIT1mvT8jSJEEQSZhbxb8=.5c13a995-2f5e-40c7-b23e-d223feab2869@github.com>
 <sk6lR8VrpBhTCZh--yPDAfTdTD0DfudPpVeE26nbtTw=.7c9d4a5c-62a6-4a20-8bc5-8af0a7bb14d9@github.com>
 <GiYMp3WaMzUbf9qb1UQZhV04uqBFjJNHk6vT_aVn6cU=.eebe6466-7dab-4a39-aed5-5fae11c492ff@github.com>
 <pjoRaaHiLifEQUCMk_ZmClQxnnTAt_Un53krTS_nzYs=.0217fd7e-b405-4d40-9c0f-07b3d1c0fd20@github.com>
Message-ID: <N73C7xW1zrh8CcUeUOtxf0JJlPeHeTwFs95AioaXxzk=.41da9721-962a-497b-84d1-4d55d43688f7@github.com>

On Fri, 26 Jan 2024 18:36:40 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> We want to put these Collector regions into the service of the Mutator threads as quickly as possible in order to avoid Mutator allocation failures.  We also want to complete update-refs as quickly as possible, because that will put a lot more memory into the hands of the Mutators.
>> 
>> The implementation of move_collector_sets_to_mutator() takes the heap lock when it reassigns a region's purpose from Collector to Mutator.
>
> Okay.

Cobbling together update-refs and freeset management adds to already high complexity. We need to do this as separate task somewhere in `op_updaterefs()`. Also, what does this move for _non-concurrent_ update refs, like degen GC?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17561#discussion_r1509365091

From kdnilsen at openjdk.org  Fri Mar  1 18:17:00 2024
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Fri, 1 Mar 2024 18:17:00 GMT
Subject: RFR: 8324649: Shenandoah: refactor implementation of free set
 [v15]
In-Reply-To: <VAkn0SrKYZWmnflpM8ZwVAXjUF1LjA0_FCBmRJJ4VSc=.c2f979bd-2957-434e-95ca-7b11b1573900@github.com>
References: <VAkn0SrKYZWmnflpM8ZwVAXjUF1LjA0_FCBmRJJ4VSc=.c2f979bd-2957-434e-95ca-7b11b1573900@github.com>
Message-ID: <JzYmcLSs6Mhpv_f8fEpsOB6n5yTWVbwm7YJs3Y8Z4As=.cd6e56cc-108d-4b72-8f46-e4a355332f75@github.com>

> Several objectives:
> 1. Reduce humongous allocation failures by segregating regular regions from humongous regions
> 2. Do not retire regions just because an allocation failed within the region if the memory remaining within the region is large enough to represent a LAB
> 3. Track range of empty regions in addition to range of available regions in order to expedite humongous allocations
> 4. Treat collector reserves as available for Mutator allocations after evacuation completes
> 5. Improve encapsulation so as to enable an OldCollector reserve for future integration of generational Shenandoah
> 
> We have compared performance of existing FreeSet implementation with the proposed PR over a broad set of performance workloads and see that the impact is mostly neutral.
> 
> Comparing 105235.0 metrics from control, 220638.0 from experiment.
> Compare: 0.589s
>                           Most impacted benchmarks |                              Most impacted metrics
> -------------------------------------------------------------------------------------------------------
>                                  Shenandoah/jython |                                          cwr_total
> 
> 
>                                 Only in experiment |                                    Only in control
> -------------------------------------------------------------------------------------------------------
>                  crypto.signverify/trigger_failure |                        crypto.rsa/cmr_thread_roots
>                 extremem-large-31g/adjust_pointers |       scimark.sparse.small/concurrent_thread_roots
>             extremem-large-31g/calculate_addresses |              xml.transform/concurrent_thread_roots
>       crypto.signverify/class_unloading_rendezvous |                    mpegaudio/concurrent_weak_roots
>                                   serial/cmr_total |                        crypto.rsa/ctr_thread_roots
> 
> Shenandoah
> -------------------------------------------------------------------------------------------------------
> +5.64% jython/cwr_total p=0.00037
>   Control:      1.928ms (+/-272.40us)        170
>   Test:         2.037ms (+/-322.73us)        344

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

  Simplify log_info and log_debug parameters
  
  This change endeavors to mitigate a problem with googletest and overflow
  of LogSelectionList::MaxSelections

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17561/files
  - new: https://git.openjdk.org/jdk/pull/17561/files/1aa5a3e6..c2f95567

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17561&range=14
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17561&range=13-14

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

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

From kdnilsen at openjdk.org  Fri Mar  1 20:43:56 2024
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Fri, 1 Mar 2024 20:43:56 GMT
Subject: RFR: 8324649: Shenandoah: refactor implementation of free set
 [v15]
In-Reply-To: <PVrVW-I2bKkYzrdBafHAaWF8mw6WtANB3PoOZW5ekRw=.2ab54392-0f5b-4f6f-b5d7-7b7a9b6a0a97@github.com>
References: <VAkn0SrKYZWmnflpM8ZwVAXjUF1LjA0_FCBmRJJ4VSc=.c2f979bd-2957-434e-95ca-7b11b1573900@github.com>
 <DtAJtZcZPNv2FMbF9-FeJIT6T8Oio1TW9yYnw3cceF0=.ed94d2d3-39c2-4f8d-9e00-5dbd81683c93@github.com>
 <PVrVW-I2bKkYzrdBafHAaWF8mw6WtANB3PoOZW5ekRw=.2ab54392-0f5b-4f6f-b5d7-7b7a9b6a0a97@github.com>
Message-ID: <EgqYAe9YnBO9-_aMjwxmmW70BZi-Pcddh_LkbfIGND8=.71e88fdf-284e-414f-90cd-9401540bc4b5@github.com>

On Fri, 1 Mar 2024 15:15:26 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Simplify log_info and log_debug parameters
>>   
>>   This change endeavors to mitigate a problem with googletest and overflow
>>   of LogSelectionList::MaxSelections
>
> src/hotspot/share/gc/shenandoah/shenandoahControlThread.cpp line 420:
> 
>> 418:                  req.type_string(),
>> 419:                  byte_size_in_proper_unit(req.size() * HeapWordSize), proper_unit_for_byte_size(req.size() * HeapWordSize));
>> 420: 
> 
> No need for this change?

Thanks.  Reverting.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17561#discussion_r1509511143

From kdnilsen at openjdk.org  Fri Mar  1 21:25:58 2024
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Fri, 1 Mar 2024 21:25:58 GMT
Subject: RFR: 8324649: Shenandoah: refactor implementation of free set
 [v14]
In-Reply-To: <PVrVW-I2bKkYzrdBafHAaWF8mw6WtANB3PoOZW5ekRw=.2ab54392-0f5b-4f6f-b5d7-7b7a9b6a0a97@github.com>
References: <VAkn0SrKYZWmnflpM8ZwVAXjUF1LjA0_FCBmRJJ4VSc=.c2f979bd-2957-434e-95ca-7b11b1573900@github.com>
 <DtAJtZcZPNv2FMbF9-FeJIT6T8Oio1TW9yYnw3cceF0=.ed94d2d3-39c2-4f8d-9e00-5dbd81683c93@github.com>
 <PVrVW-I2bKkYzrdBafHAaWF8mw6WtANB3PoOZW5ekRw=.2ab54392-0f5b-4f6f-b5d7-7b7a9b6a0a97@github.com>
Message-ID: <XzlTwJFYWhjXumZ-mexXz39jhm5-hjqfBnmWayHTVZg=.e5d25e3d-54f0-4478-a1ed-afacaecf9af9@github.com>

On Fri, 1 Mar 2024 15:18:40 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Kelvin Nilsen has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 60 commits:
>> 
>>  - Remove instrumentation and cleanup magic numbers
>>    
>>    Two places, I had used 63 when I should have used
>>    _bits_per_array_element -1.
>>  - Address 32-bit compile issues
>>  - Fix 32-bit size formatting in log messages
>>  - Fix white space
>>  - Merge remote-tracking branch 'origin/master' into restructure-free-set
>>  - Merge branch 'openjdk:master' into master
>>  - Two bug fixes for better performance
>>    
>>    1. Collector reserve size is based on memory available within regions
>>       rather than the region size (oops).
>>    
>>    2. If an attempt to allocate within a region fails and the region has
>>       already provided the percentage presumed by ShenandoahEvacWaste,
>>       retire this region.  This is motivated by observations that
>>       otherwise, we end up with large numbers of regions that have only
>>       a small amount of memory within them (e.g. 4k) and every allocation
>>       request has to wade through all of these regions before it eventually
>>       finds a region that has a sufficiently large amount of available
>>       memory.  In the original Shenandoah free-set implementation, the
>>       behavior was to retire the first time an allocation within that
>>       regions fails, regardless of whether the region has already reached
>>       the ShenandoahEvacWaste threshold.
>>  - Fix off-by-one error in is_forward_consecutive_ones()
>>  - Fix whitespace
>>  - Bug fixes and performance improvements
>>    
>>    1. Correct off-b-one-error in count of trailingones
>>    2. Speed up search for contiguous regions (for humongous allocations) by
>>       sliding window instead of initiating new search each time
>>    3. Bias regular region allocations to favor regions that are already
>>       partially consumed
>>    4. Fix bug in move_regions_from_collector_to_mutator which caused some
>>       non-empty regions to be ignored.
>>  - ... and 50 more: https://git.openjdk.org/jdk/compare/be2b92bd...1aa5a3e6
>
> src/hotspot/share/gc/shenandoah/shenandoahFreeSet.hpp line 68:
> 
>> 66:   // Count consecutive ones in forward order, starting from start_idx.  Requires that there is at least one zero
>> 67:   // between start_idx and index value (_num_bits - 1), inclusive.
>> 68:   size_t count_leading_ones(ssize_t start_idx) const;
> 
> Does the argument have to me `ssize_t`, not `size_t`? Is this because you want it to be signed?

I'm going to add the following comment at the top of shenandoahFreeSet.hpp:

// The API and internal implementation of ShenandoahSimpleBitMap and ShenandoahRegionPartitions use ssize_t to                      
// represent index, even though index is "inherently" unsigned.  There are two reasons for this choice:                             
//  1. We use -1 as a sentinel value to represent empty partitions.  This same value may be used to represent                       
//     failure to find a previous set bit or previous range of set bits.                                                            
//  2. Certain loops are written most naturally if the iterator, which may hold the sentinel -1 value, can be                       
//     declared as signed and the terminating condition can be < 0.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17561#discussion_r1509554566

From wkemper at openjdk.org  Fri Mar  1 22:18:46 2024
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 1 Mar 2024 22:18:46 GMT
Subject: RFR: Merge openjdk/jdk:master [v4]
In-Reply-To: <AS_pM2SZw7OhfafGXUXGMWgKw8MwuYj4XDt9Yfet2MQ=.2ef4c4fc-a51e-44e2-80e7-10c22a13ff07@github.com>
References: <AS_pM2SZw7OhfafGXUXGMWgKw8MwuYj4XDt9Yfet2MQ=.2ef4c4fc-a51e-44e2-80e7-10c22a13ff07@github.com>
Message-ID: <RZZe4VbaACWsfqB8dD1xlG2wJuhMugi3sT71hGkx9ks=.5e2d2671-f91b-4e69-b59c-6e8253c991e3@github.com>

> Merges tag jdk-23+11

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

 - Merge branch 'shenandoah-master' into merge-jdk-23+11
 - Fix zero build
 - Merge remote-tracking branch 'shenandoah/master' into merge-jdk-23+11
 - 8326461: tools/jlink/CheckExecutable.java fails as .debuginfo files are not executable
   
   Reviewed-by: shade, alanb
 - 8325870: Zap end padding bits for ArrayOops in non-release builds
   
   Reviewed-by: stefank, ayang
 - 8326414: Serial: Inline SerialHeap::create_rem_set
   
   Reviewed-by: kbarrett
 - 8323695: RenderPerf (2D) enhancements (23.12)
   
   Reviewed-by: avu, prr
 - 8324243: Compilation failures in java.desktop module with gcc 14
   
   Reviewed-by: jwaters, ihse, kbarrett, prr
 - 8325342: Remove unneeded exceptions in compare.sh
   
   Reviewed-by: erikj
 - 8326158: Javadoc for java.time.DayOfWeek#minus(long)
   
   Reviewed-by: iris, lancea
 - ... and 85 more: https://git.openjdk.org/shenandoah/compare/b7c68eb3...bb8c2163

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

Changes: https://git.openjdk.org/shenandoah/pull/399/files
 Webrev: https://webrevs.openjdk.org/?repo=shenandoah&pr=399&range=03
  Stats: 12284 lines in 327 files changed: 6368 ins; 3630 del; 2286 mod
  Patch: https://git.openjdk.org/shenandoah/pull/399.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah.git pull/399/head:pull/399

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

From ysr at openjdk.org  Fri Mar  1 22:42:03 2024
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Fri, 1 Mar 2024 22:42:03 GMT
Subject: RFR: 8325671: Shenandoah: Introduce a ShenandoahGenerationType and
 templatize certain marking closures with it [v9]
In-Reply-To: <jao3hVd-10GqHqJXM53BnuyBVmIPYc2tR8dg6M0MtX4=.c6c4fee3-a3a6-4a35-b379-4352b19e2bfc@github.com>
References: <jao3hVd-10GqHqJXM53BnuyBVmIPYc2tR8dg6M0MtX4=.c6c4fee3-a3a6-4a35-b379-4352b19e2bfc@github.com>
Message-ID: <JgAZ7cRADxkdstztKAoUmK8xa_GEBNG_bS7u7BNdneU=.76cf1e5b-852f-4012-a469-febe41de064f@github.com>

> 8325671: Shenandoah: Introduce a ShenandoahGenerationType and templatize certain marking closures with it

Y. Srinivas Ramakrishna has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits:

 - Merge branch 'master' into generation_type
 - Merge branch 'master' into generation_type
 - Merge branch 'master' into generation_type
 - Merge branch 'master' into generation_type
 - Changes from review: Adjust order of parms in functions so they are consistent with their
   template parameter order and contiguity, per convention.
 - Merge branch 'master' into generation_type
 - Merge branch 'master' into generation_type
 - Missing #include of ShenandoahGenerationType (albeit satisfied transitively via other include).
 - Merge branch 'master' into generation_type
 - Introduce ShenandoahGenerationType and templatize most closures with it.
   The template expands for only the NON_GEN type for the non-generational
   version of Shenandoah currently, and will in the future accomodate
   Generational Shenandoah.

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

Changes: https://git.openjdk.org/jdk/pull/17815/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17815&range=08
  Stats: 124 lines in 9 files changed: 71 ins; 3 del; 50 mod
  Patch: https://git.openjdk.org/jdk/pull/17815.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17815/head:pull/17815

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

From wkemper at openjdk.org  Fri Mar  1 23:45:30 2024
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 1 Mar 2024 23:45:30 GMT
Subject: RFR: 8325670: GenShen: Allow old to expand at end of each GC
Message-ID: <xHixokdJcFIT4mqIpzBMDym-X_V2EOUgyZomghrjGCw=.abd0658a-ee96-40be-8d05-f3c8eaaf7fae@github.com>

Clean backport

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

Commit messages:
 - Backport 2f1fa6dbe2b6dcea15603ac42087af83961622f9

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

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

From kdnilsen at openjdk.org  Fri Mar  1 23:57:26 2024
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Fri, 1 Mar 2024 23:57:26 GMT
Subject: Integrated: 8326626: GenShen: Remove dead code associated with
 non-elastic TLABS
Message-ID: <NwPMgn0c08yyTZnOVN-2rWnGcb_mD--wlQoW1Wqso_Y=.0a3d19c9-683a-428a-9b0b-ef60f5b87383@github.com>

Clean backport.

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

Commit messages:
 - Backport 9fde64ecf7f4954dbd4028a57cdeb400de8b0268

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

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

From kdnilsen at openjdk.org  Fri Mar  1 23:57:26 2024
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Fri, 1 Mar 2024 23:57:26 GMT
Subject: Integrated: 8326626: GenShen: Remove dead code associated with
 non-elastic TLABS
In-Reply-To: <NwPMgn0c08yyTZnOVN-2rWnGcb_mD--wlQoW1Wqso_Y=.0a3d19c9-683a-428a-9b0b-ef60f5b87383@github.com>
References: <NwPMgn0c08yyTZnOVN-2rWnGcb_mD--wlQoW1Wqso_Y=.0a3d19c9-683a-428a-9b0b-ef60f5b87383@github.com>
Message-ID: <FOTIIW7OwDzxz6YHVUPaQ65llOKrYxMmJoADxjteqXk=.8a7f2daf-34e2-499f-b741-1464bfaaeee1@github.com>

On Fri, 1 Mar 2024 23:49:13 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

> Clean backport.

This pull request has now been integrated.

Changeset: 0b12057a
Author:    Kelvin Nilsen <kdnilsen at openjdk.org>
URL:       https://git.openjdk.org/shenandoah-jdk21u/commit/0b12057a5d5afc52f9a023c876279286acc6c1de
Stats:     8 lines in 1 file changed: 0 ins; 8 del; 0 mod

8326626: GenShen: Remove dead code associated with non-elastic TLABS

Backport-of: 9fde64ecf7f4954dbd4028a57cdeb400de8b0268

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

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

From wkemper at openjdk.org  Sat Mar  2 00:00:18 2024
From: wkemper at openjdk.org (William Kemper)
Date: Sat, 2 Mar 2024 00:00:18 GMT
Subject: Integrated: 8325670: GenShen: Allow old to expand at end of each GC
In-Reply-To: <xHixokdJcFIT4mqIpzBMDym-X_V2EOUgyZomghrjGCw=.abd0658a-ee96-40be-8d05-f3c8eaaf7fae@github.com>
References: <xHixokdJcFIT4mqIpzBMDym-X_V2EOUgyZomghrjGCw=.abd0658a-ee96-40be-8d05-f3c8eaaf7fae@github.com>
Message-ID: <XMH_yCjYYi92sH_fAl8KME1K29TC65UQVOgflHKqaes=.2c9feba7-d520-4bdd-afe5-17f7ce7135ae@github.com>

On Fri, 1 Mar 2024 23:39:46 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Clean backport

This pull request has now been integrated.

Changeset: 1e32ddc6
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.org/shenandoah-jdk21u/commit/1e32ddc66f3eaeba9cfce2e1b071debd5eeaf676
Stats:     8 lines in 1 file changed: 5 ins; 0 del; 3 mod

8325670: GenShen: Allow old to expand at end of each GC

Backport-of: 2f1fa6dbe2b6dcea15603ac42087af83961622f9

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

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

From kdnilsen at openjdk.org  Sat Mar  2 00:13:05 2024
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Sat, 2 Mar 2024 00:13:05 GMT
Subject: RFR: 8324649: Shenandoah: refactor implementation of free set
 [v16]
In-Reply-To: <VAkn0SrKYZWmnflpM8ZwVAXjUF1LjA0_FCBmRJJ4VSc=.c2f979bd-2957-434e-95ca-7b11b1573900@github.com>
References: <VAkn0SrKYZWmnflpM8ZwVAXjUF1LjA0_FCBmRJJ4VSc=.c2f979bd-2957-434e-95ca-7b11b1573900@github.com>
Message-ID: <J3wFIBb1V6ZKnxPUZ_1MpyiqFiHPZq_v4H79bhH6UI0=.b08ac3d8-0c71-44a7-9833-59137c2b01b3@github.com>

> Several objectives:
> 1. Reduce humongous allocation failures by segregating regular regions from humongous regions
> 2. Do not retire regions just because an allocation failed within the region if the memory remaining within the region is large enough to represent a LAB
> 3. Track range of empty regions in addition to range of available regions in order to expedite humongous allocations
> 4. Treat collector reserves as available for Mutator allocations after evacuation completes
> 5. Improve encapsulation so as to enable an OldCollector reserve for future integration of generational Shenandoah
> 
> We have compared performance of existing FreeSet implementation with the proposed PR over a broad set of performance workloads and see that the impact is mostly neutral.
> 
> Comparing 105235.0 metrics from control, 220638.0 from experiment.
> Compare: 0.589s
>                           Most impacted benchmarks |                              Most impacted metrics
> -------------------------------------------------------------------------------------------------------
>                                  Shenandoah/jython |                                          cwr_total
> 
> 
>                                 Only in experiment |                                    Only in control
> -------------------------------------------------------------------------------------------------------
>                  crypto.signverify/trigger_failure |                        crypto.rsa/cmr_thread_roots
>                 extremem-large-31g/adjust_pointers |       scimark.sparse.small/concurrent_thread_roots
>             extremem-large-31g/calculate_addresses |              xml.transform/concurrent_thread_roots
>       crypto.signverify/class_unloading_rendezvous |                    mpegaudio/concurrent_weak_roots
>                                   serial/cmr_total |                        crypto.rsa/ctr_thread_roots
> 
> Shenandoah
> -------------------------------------------------------------------------------------------------------
> +5.64% jython/cwr_total p=0.00037
>   Control:      1.928ms (+/-272.40us)        170
>   Test:         2.037ms (+/-322.73us)        344

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

  Respond to reviewer feedback and improve comments
  
  Also, increase LogSelectionList::MaxSelections, an experimental change that will be integrated
  independently from a separate PR.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17561/files
  - new: https://git.openjdk.org/jdk/pull/17561/files/c2f95567..42af76b4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17561&range=15
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17561&range=14-15

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

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

From ysr at openjdk.org  Sat Mar  2 02:05:00 2024
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Sat, 2 Mar 2024 02:05:00 GMT
Subject: Integrated: 8325671: Shenandoah: Introduce a ShenandoahGenerationType
 and templatize certain marking closures with it
In-Reply-To: <jao3hVd-10GqHqJXM53BnuyBVmIPYc2tR8dg6M0MtX4=.c6c4fee3-a3a6-4a35-b379-4352b19e2bfc@github.com>
References: <jao3hVd-10GqHqJXM53BnuyBVmIPYc2tR8dg6M0MtX4=.c6c4fee3-a3a6-4a35-b379-4352b19e2bfc@github.com>
Message-ID: <QA2jlRKGWQMcZEKvikaCDRdt1xts23mHH3eq0gNlVOM=.8a190417-2202-40e8-98fb-5841cd5fd7fa@github.com>

On Mon, 12 Feb 2024 18:31:30 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

> 8325671: Shenandoah: Introduce a ShenandoahGenerationType and templatize certain marking closures with it

This pull request has now been integrated.

Changeset: f62f2adb
Author:    Y. Srinivas Ramakrishna <ysr at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f62f2adbc3ec3cf8a9a59d3d766c60d11ebd77e2
Stats:     124 lines in 9 files changed: 71 ins; 3 del; 50 mod

8325671: Shenandoah: Introduce a ShenandoahGenerationType and templatize certain marking closures with it

In support of eventually supporting a generational version of Shenandoah, we introduce a ShenandoahGenerationType enum which currently has a single NON_GEN value for Shenandoah. The generational extension of Shenandoah will introduce additional enum values when GenShen is integrated. These will be used to specialize certain marking closures via templatization, such that suitable variations of the marking (and in the future other) closures can be used for the generational and non-generational variants of the collector while minimizing interference between the two variants while maximizing code-sharing without affecting correctness or performance.

This ticket introduces the new enum type and templatizes certain existing marking closures.

In effect, this should be semantically a no-op for current (non-generational) Shenandoah and ideally completely performance-neutral (to be established via measurements).

**Testing:**
- [x] jtreg hotspot_gc
- [x] github actions
- [ ] codepipeline perf & stress: in progress

**Performance:**
- [ ] specjbb w/shenandoah
- [ ] codepipeline perf: in progress

Reviewed-by: kdnilsen, shade

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

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

From ysr at openjdk.org  Sat Mar  2 02:22:04 2024
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Sat, 2 Mar 2024 02:22:04 GMT
Subject: RFR: 8325885: GenShen: harmonize with JDK-8325671
Message-ID: <p2NMmKOTpWvmj-60q4JQoojCjeT7XcsHawdzru4dXqA=.d24ee989-c04b-4a8e-9bb2-e3e6a4132e72@github.com>

/issueJDK-8325885

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

Commit messages:
 - Merge branch 'master' into generation_type
 - GLOBAL_GEN -> GLOBAL
 - Merge branch 'master' into generation_type
 - Changes stemming from hanges to upstream for preparing for
 - Build failure.

Changes: https://git.openjdk.org/shenandoah/pull/402/files
 Webrev: https://webrevs.openjdk.org/?repo=shenandoah&pr=402&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8325885
  Stats: 87 lines in 16 files changed: 10 ins; 3 del; 74 mod
  Patch: https://git.openjdk.org/shenandoah/pull/402.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah.git pull/402/head:pull/402

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

From kdnilsen at openjdk.org  Sat Mar  2 03:37:13 2024
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Sat, 2 Mar 2024 03:37:13 GMT
Subject: RFR: 8324649: Shenandoah: refactor implementation of free set
 [v17]
In-Reply-To: <VAkn0SrKYZWmnflpM8ZwVAXjUF1LjA0_FCBmRJJ4VSc=.c2f979bd-2957-434e-95ca-7b11b1573900@github.com>
References: <VAkn0SrKYZWmnflpM8ZwVAXjUF1LjA0_FCBmRJJ4VSc=.c2f979bd-2957-434e-95ca-7b11b1573900@github.com>
Message-ID: <UpMOM4bpBwioGdPGfvJfhdvFM-tgYhYcM4FPyzsfS3c=.98bcbcec-c8b0-4fd0-927e-ab5052869eb4@github.com>

> Several objectives:
> 1. Reduce humongous allocation failures by segregating regular regions from humongous regions
> 2. Do not retire regions just because an allocation failed within the region if the memory remaining within the region is large enough to represent a LAB
> 3. Track range of empty regions in addition to range of available regions in order to expedite humongous allocations
> 4. Treat collector reserves as available for Mutator allocations after evacuation completes
> 5. Improve encapsulation so as to enable an OldCollector reserve for future integration of generational Shenandoah
> 
> We have compared performance of existing FreeSet implementation with the proposed PR over a broad set of performance workloads and see that the impact is mostly neutral.
> 
> Comparing 105235.0 metrics from control, 220638.0 from experiment.
> Compare: 0.589s
>                           Most impacted benchmarks |                              Most impacted metrics
> -------------------------------------------------------------------------------------------------------
>                                  Shenandoah/jython |                                          cwr_total
> 
> 
>                                 Only in experiment |                                    Only in control
> -------------------------------------------------------------------------------------------------------
>                  crypto.signverify/trigger_failure |                        crypto.rsa/cmr_thread_roots
>                 extremem-large-31g/adjust_pointers |       scimark.sparse.small/concurrent_thread_roots
>             extremem-large-31g/calculate_addresses |              xml.transform/concurrent_thread_roots
>       crypto.signverify/class_unloading_rendezvous |                    mpegaudio/concurrent_weak_roots
>                                   serial/cmr_total |                        crypto.rsa/ctr_thread_roots
> 
> Shenandoah
> -------------------------------------------------------------------------------------------------------
> +5.64% jython/cwr_total p=0.00037
>   Control:      1.928ms (+/-272.40us)        170
>   Test:         2.037ms (+/-322.73us)        344

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

  Fix initialization order for ShenandoahFreeSet

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17561/files
  - new: https://git.openjdk.org/jdk/pull/17561/files/42af76b4..a45f976d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17561&range=16
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17561&range=15-16

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

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

From kdnilsen at openjdk.org  Sun Mar  3 15:17:08 2024
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Sun, 3 Mar 2024 15:17:08 GMT
Subject: RFR: 8324649: Shenandoah: refactor implementation of free set
 [v18]
In-Reply-To: <VAkn0SrKYZWmnflpM8ZwVAXjUF1LjA0_FCBmRJJ4VSc=.c2f979bd-2957-434e-95ca-7b11b1573900@github.com>
References: <VAkn0SrKYZWmnflpM8ZwVAXjUF1LjA0_FCBmRJJ4VSc=.c2f979bd-2957-434e-95ca-7b11b1573900@github.com>
Message-ID: <5pMGQeLdHTAYwhqg2FKmZAGs7ZFhHem0zBs9Y4T2l64=.45f6298e-9250-46ee-b01b-6c54880abdc4@github.com>

> Several objectives:
> 1. Reduce humongous allocation failures by segregating regular regions from humongous regions
> 2. Do not retire regions just because an allocation failed within the region if the memory remaining within the region is large enough to represent a LAB
> 3. Track range of empty regions in addition to range of available regions in order to expedite humongous allocations
> 4. Treat collector reserves as available for Mutator allocations after evacuation completes
> 5. Improve encapsulation so as to enable an OldCollector reserve for future integration of generational Shenandoah
> 
> We have compared performance of existing FreeSet implementation with the proposed PR over a broad set of performance workloads and see that the impact is mostly neutral.
> 
> Comparing 105235.0 metrics from control, 220638.0 from experiment.
> Compare: 0.589s
>                           Most impacted benchmarks |                              Most impacted metrics
> -------------------------------------------------------------------------------------------------------
>                                  Shenandoah/jython |                                          cwr_total
> 
> 
>                                 Only in experiment |                                    Only in control
> -------------------------------------------------------------------------------------------------------
>                  crypto.signverify/trigger_failure |                        crypto.rsa/cmr_thread_roots
>                 extremem-large-31g/adjust_pointers |       scimark.sparse.small/concurrent_thread_roots
>             extremem-large-31g/calculate_addresses |              xml.transform/concurrent_thread_roots
>       crypto.signverify/class_unloading_rendezvous |                    mpegaudio/concurrent_weak_roots
>                                   serial/cmr_total |                        crypto.rsa/ctr_thread_roots
> 
> Shenandoah
> -------------------------------------------------------------------------------------------------------
> +5.64% jython/cwr_total p=0.00037
>   Control:      1.928ms (+/-272.40us)        170
>   Test:         2.037ms (+/-322.73us)        344

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

  Revert redundant change from https://github.com/openjdk/jdk/pull/18083
  
  This change was made experimentally in this PR to evaluate whether this
  would resolve regressions in GHA tests.  When present, this PR passed
  all GHA tests.  When absent, it does not.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17561/files
  - new: https://git.openjdk.org/jdk/pull/17561/files/a45f976d..25263849

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17561&range=17
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17561&range=16-17

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

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

From kdnilsen at openjdk.org  Mon Mar  4 21:48:18 2024
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Mon, 4 Mar 2024 21:48:18 GMT
Subject: RFR: 8325885: GenShen: harmonize with JDK-8325671
In-Reply-To: <p2NMmKOTpWvmj-60q4JQoojCjeT7XcsHawdzru4dXqA=.d24ee989-c04b-4a8e-9bb2-e3e6a4132e72@github.com>
References: <p2NMmKOTpWvmj-60q4JQoojCjeT7XcsHawdzru4dXqA=.d24ee989-c04b-4a8e-9bb2-e3e6a4132e72@github.com>
Message-ID: <71hGIAwcRZWW_H_BKfEu04xaJldebABlHZZzZw4oQYg=.a99f7b03-ad4a-4c80-a382-05e2a4c7eaea@github.com>

On Sat, 2 Mar 2024 02:15:53 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

> /issueJDK-8325885

Looks good to me.  Thanks.

src/hotspot/share/gc/shenandoah/shenandoahConcurrentMark.cpp line 244:

> 242:   ShenandoahFlushSATBHandshakeClosure flush_satb(qset);
> 243:   for (uint flushes = 0; flushes < ShenandoahMaxSATBBufferFlushes; flushes++) {
> 244:     // TODO: ysr : hoist this switch out of the loop & refactor ?? How may

The default value of ShenandoahMaxSATBBufferFlushes is 5.  I think the number of iterations is typically low.  Given low number of typical iterations, may not be worth it to restructure the loop control.

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

Marked as reviewed by kdnilsen (Committer).

PR Review: https://git.openjdk.org/shenandoah/pull/402#pullrequestreview-1915411815
PR Review Comment: https://git.openjdk.org/shenandoah/pull/402#discussion_r1511836937

From kdnilsen at openjdk.org  Mon Mar  4 21:51:02 2024
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Mon, 4 Mar 2024 21:51:02 GMT
Subject: RFR: 8325885: GenShen: harmonize with JDK-8325671
In-Reply-To: <p2NMmKOTpWvmj-60q4JQoojCjeT7XcsHawdzru4dXqA=.d24ee989-c04b-4a8e-9bb2-e3e6a4132e72@github.com>
References: <p2NMmKOTpWvmj-60q4JQoojCjeT7XcsHawdzru4dXqA=.d24ee989-c04b-4a8e-9bb2-e3e6a4132e72@github.com>
Message-ID: <yPrTafvW0yP6csGBjoiASjYJI2GkghCEN_nYHs3muOE=.d90ef723-6be8-4f48-8dbd-e1db89c5a09e@github.com>

On Sat, 2 Mar 2024 02:15:53 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

> /issueJDK-8325885

The timeouts observed on TestHumongousThreshold are a known issue being addressed by (https://bugs.openjdk.org/browse/JDK-8327000)

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

PR Comment: https://git.openjdk.org/shenandoah/pull/402#issuecomment-1977520263

From kdnilsen at openjdk.org  Mon Mar  4 22:21:13 2024
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Mon, 4 Mar 2024 22:21:13 GMT
Subject: RFR: 8324649: Shenandoah: refactor implementation of free set
 [v19]
In-Reply-To: <VAkn0SrKYZWmnflpM8ZwVAXjUF1LjA0_FCBmRJJ4VSc=.c2f979bd-2957-434e-95ca-7b11b1573900@github.com>
References: <VAkn0SrKYZWmnflpM8ZwVAXjUF1LjA0_FCBmRJJ4VSc=.c2f979bd-2957-434e-95ca-7b11b1573900@github.com>
Message-ID: <usMQo07WAaiHvrm0pX3-vC9K3Qb9PMmRLJ6OMo5YxB8=.9a7a776d-9cc4-4920-bb46-8ce499c77e08@github.com>

> Several objectives:
> 1. Reduce humongous allocation failures by segregating regular regions from humongous regions
> 2. Do not retire regions just because an allocation failed within the region if the memory remaining within the region is large enough to represent a LAB
> 3. Track range of empty regions in addition to range of available regions in order to expedite humongous allocations
> 4. Treat collector reserves as available for Mutator allocations after evacuation completes
> 5. Improve encapsulation so as to enable an OldCollector reserve for future integration of generational Shenandoah
> 
> We have compared performance of existing FreeSet implementation with the proposed PR over a broad set of performance workloads and see that the impact is mostly neutral.
> 
> Comparing 105235.0 metrics from control, 220638.0 from experiment.
> Compare: 0.589s
>                           Most impacted benchmarks |                              Most impacted metrics
> -------------------------------------------------------------------------------------------------------
>                                  Shenandoah/jython |                                          cwr_total
> 
> 
>                                 Only in experiment |                                    Only in control
> -------------------------------------------------------------------------------------------------------
>                  crypto.signverify/trigger_failure |                        crypto.rsa/cmr_thread_roots
>                 extremem-large-31g/adjust_pointers |       scimark.sparse.small/concurrent_thread_roots
>             extremem-large-31g/calculate_addresses |              xml.transform/concurrent_thread_roots
>       crypto.signverify/class_unloading_rendezvous |                    mpegaudio/concurrent_weak_roots
>                                   serial/cmr_total |                        crypto.rsa/ctr_thread_roots
> 
> Shenandoah
> -------------------------------------------------------------------------------------------------------
> +5.64% jython/cwr_total p=0.00037
>   Control:      1.928ms (+/-272.40us)        170
>   Test:         2.037ms (+/-322.73us)        344

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

  Add unit tests for ShenandoahSimpleBitMap

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17561/files
  - new: https://git.openjdk.org/jdk/pull/17561/files/25263849..2b9a4707

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17561&range=18
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17561&range=17-18

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

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

From kdnilsen at openjdk.org  Mon Mar  4 23:14:11 2024
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Mon, 4 Mar 2024 23:14:11 GMT
Subject: RFR: 8324649: Shenandoah: refactor implementation of free set
 [v20]
In-Reply-To: <VAkn0SrKYZWmnflpM8ZwVAXjUF1LjA0_FCBmRJJ4VSc=.c2f979bd-2957-434e-95ca-7b11b1573900@github.com>
References: <VAkn0SrKYZWmnflpM8ZwVAXjUF1LjA0_FCBmRJJ4VSc=.c2f979bd-2957-434e-95ca-7b11b1573900@github.com>
Message-ID: <eNGHSqdjfAEu1B9nKmzWbpJeGxC-bRdtIMVJV8aua5M=.973b8790-290b-4e14-902b-f3a2112eb1d3@github.com>

> Several objectives:
> 1. Reduce humongous allocation failures by segregating regular regions from humongous regions
> 2. Do not retire regions just because an allocation failed within the region if the memory remaining within the region is large enough to represent a LAB
> 3. Track range of empty regions in addition to range of available regions in order to expedite humongous allocations
> 4. Treat collector reserves as available for Mutator allocations after evacuation completes
> 5. Improve encapsulation so as to enable an OldCollector reserve for future integration of generational Shenandoah
> 
> We have compared performance of existing FreeSet implementation with the proposed PR over a broad set of performance workloads and see that the impact is mostly neutral.
> 
> Comparing 105235.0 metrics from control, 220638.0 from experiment.
> Compare: 0.589s
>                           Most impacted benchmarks |                              Most impacted metrics
> -------------------------------------------------------------------------------------------------------
>                                  Shenandoah/jython |                                          cwr_total
> 
> 
>                                 Only in experiment |                                    Only in control
> -------------------------------------------------------------------------------------------------------
>                  crypto.signverify/trigger_failure |                        crypto.rsa/cmr_thread_roots
>                 extremem-large-31g/adjust_pointers |       scimark.sparse.small/concurrent_thread_roots
>             extremem-large-31g/calculate_addresses |              xml.transform/concurrent_thread_roots
>       crypto.signverify/class_unloading_rendezvous |                    mpegaudio/concurrent_weak_roots
>                                   serial/cmr_total |                        crypto.rsa/ctr_thread_roots
> 
> Shenandoah
> -------------------------------------------------------------------------------------------------------
> +5.64% jython/cwr_total p=0.00037
>   Control:      1.928ms (+/-272.40us)        170
>   Test:         2.037ms (+/-322.73us)        344

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

  Correct errors in ShenandoahSimpleBitMap unit tests

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17561/files
  - new: https://git.openjdk.org/jdk/pull/17561/files/2b9a4707..9be1a16a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17561&range=19
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17561&range=18-19

  Stats: 343 lines in 2 files changed: 267 ins; 19 del; 57 mod
  Patch: https://git.openjdk.org/jdk/pull/17561.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17561/head:pull/17561

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

From kdnilsen at openjdk.org  Mon Mar  4 23:23:11 2024
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Mon, 4 Mar 2024 23:23:11 GMT
Subject: RFR: 8324649: Shenandoah: refactor implementation of free set
 [v21]
In-Reply-To: <VAkn0SrKYZWmnflpM8ZwVAXjUF1LjA0_FCBmRJJ4VSc=.c2f979bd-2957-434e-95ca-7b11b1573900@github.com>
References: <VAkn0SrKYZWmnflpM8ZwVAXjUF1LjA0_FCBmRJJ4VSc=.c2f979bd-2957-434e-95ca-7b11b1573900@github.com>
Message-ID: <KfdIWkF4wKntBomq96BMXCfGOAaj1n2gjZdYbsDkzJQ=.dfa1eaae-75ba-4caa-a303-5b4372305e52@github.com>

> Several objectives:
> 1. Reduce humongous allocation failures by segregating regular regions from humongous regions
> 2. Do not retire regions just because an allocation failed within the region if the memory remaining within the region is large enough to represent a LAB
> 3. Track range of empty regions in addition to range of available regions in order to expedite humongous allocations
> 4. Treat collector reserves as available for Mutator allocations after evacuation completes
> 5. Improve encapsulation so as to enable an OldCollector reserve for future integration of generational Shenandoah
> 
> We have compared performance of existing FreeSet implementation with the proposed PR over a broad set of performance workloads and see that the impact is mostly neutral.
> 
> Comparing 105235.0 metrics from control, 220638.0 from experiment.
> Compare: 0.589s
>                           Most impacted benchmarks |                              Most impacted metrics
> -------------------------------------------------------------------------------------------------------
>                                  Shenandoah/jython |                                          cwr_total
> 
> 
>                                 Only in experiment |                                    Only in control
> -------------------------------------------------------------------------------------------------------
>                  crypto.signverify/trigger_failure |                        crypto.rsa/cmr_thread_roots
>                 extremem-large-31g/adjust_pointers |       scimark.sparse.small/concurrent_thread_roots
>             extremem-large-31g/calculate_addresses |              xml.transform/concurrent_thread_roots
>       crypto.signverify/class_unloading_rendezvous |                    mpegaudio/concurrent_weak_roots
>                                   serial/cmr_total |                        crypto.rsa/ctr_thread_roots
> 
> Shenandoah
> -------------------------------------------------------------------------------------------------------
> +5.64% jython/cwr_total p=0.00037
>   Control:      1.928ms (+/-272.40us)        170
>   Test:         2.037ms (+/-322.73us)        344

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

  Fix whitespace

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17561/files
  - new: https://git.openjdk.org/jdk/pull/17561/files/9be1a16a..d9359a38

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17561&range=20
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17561&range=19-20

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

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

From kdnilsen at openjdk.org  Mon Mar  4 23:38:14 2024
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Mon, 4 Mar 2024 23:38:14 GMT
Subject: RFR: 8324649: Shenandoah: refactor implementation of free set
 [v22]
In-Reply-To: <VAkn0SrKYZWmnflpM8ZwVAXjUF1LjA0_FCBmRJJ4VSc=.c2f979bd-2957-434e-95ca-7b11b1573900@github.com>
References: <VAkn0SrKYZWmnflpM8ZwVAXjUF1LjA0_FCBmRJJ4VSc=.c2f979bd-2957-434e-95ca-7b11b1573900@github.com>
Message-ID: <fJLjaqYxs_JfDt_gMdZDBeBiSZATbDBke0sPhMylgdA=.4d49cf39-daa9-46db-aed5-7b14005d41db@github.com>

> Several objectives:
> 1. Reduce humongous allocation failures by segregating regular regions from humongous regions
> 2. Do not retire regions just because an allocation failed within the region if the memory remaining within the region is large enough to represent a LAB
> 3. Track range of empty regions in addition to range of available regions in order to expedite humongous allocations
> 4. Treat collector reserves as available for Mutator allocations after evacuation completes
> 5. Improve encapsulation so as to enable an OldCollector reserve for future integration of generational Shenandoah
> 
> We have compared performance of existing FreeSet implementation with the proposed PR over a broad set of performance workloads and see that the impact is mostly neutral.
> 
> Comparing 105235.0 metrics from control, 220638.0 from experiment.
> Compare: 0.589s
>                           Most impacted benchmarks |                              Most impacted metrics
> -------------------------------------------------------------------------------------------------------
>                                  Shenandoah/jython |                                          cwr_total
> 
> 
>                                 Only in experiment |                                    Only in control
> -------------------------------------------------------------------------------------------------------
>                  crypto.signverify/trigger_failure |                        crypto.rsa/cmr_thread_roots
>                 extremem-large-31g/adjust_pointers |       scimark.sparse.small/concurrent_thread_roots
>             extremem-large-31g/calculate_addresses |              xml.transform/concurrent_thread_roots
>       crypto.signverify/class_unloading_rendezvous |                    mpegaudio/concurrent_weak_roots
>                                   serial/cmr_total |                        crypto.rsa/ctr_thread_roots
> 
> Shenandoah
> -------------------------------------------------------------------------------------------------------
> +5.64% jython/cwr_total p=0.00037
>   Control:      1.928ms (+/-272.40us)        170
>   Test:         2.037ms (+/-322.73us)        344

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

 - Fix another typo
 - Fix typo

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17561/files
  - new: https://git.openjdk.org/jdk/pull/17561/files/d9359a38..12327c0f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17561&range=21
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17561&range=20-21

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

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

From kdnilsen at openjdk.org  Tue Mar  5 01:14:14 2024
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Tue, 5 Mar 2024 01:14:14 GMT
Subject: RFR: 8324649: Shenandoah: refactor implementation of free set
 [v23]
In-Reply-To: <VAkn0SrKYZWmnflpM8ZwVAXjUF1LjA0_FCBmRJJ4VSc=.c2f979bd-2957-434e-95ca-7b11b1573900@github.com>
References: <VAkn0SrKYZWmnflpM8ZwVAXjUF1LjA0_FCBmRJJ4VSc=.c2f979bd-2957-434e-95ca-7b11b1573900@github.com>
Message-ID: <d1qkq04m_PgQkecRnqF3QgPNZHmt7rg2JZWioKHKj-U=.e3ebc376-f667-4642-8d6f-6386b5f7f3e9@github.com>

> Several objectives:
> 1. Reduce humongous allocation failures by segregating regular regions from humongous regions
> 2. Do not retire regions just because an allocation failed within the region if the memory remaining within the region is large enough to represent a LAB
> 3. Track range of empty regions in addition to range of available regions in order to expedite humongous allocations
> 4. Treat collector reserves as available for Mutator allocations after evacuation completes
> 5. Improve encapsulation so as to enable an OldCollector reserve for future integration of generational Shenandoah
> 
> We have compared performance of existing FreeSet implementation with the proposed PR over a broad set of performance workloads and see that the impact is mostly neutral.
> 
> Comparing 105235.0 metrics from control, 220638.0 from experiment.
> Compare: 0.589s
>                           Most impacted benchmarks |                              Most impacted metrics
> -------------------------------------------------------------------------------------------------------
>                                  Shenandoah/jython |                                          cwr_total
> 
> 
>                                 Only in experiment |                                    Only in control
> -------------------------------------------------------------------------------------------------------
>                  crypto.signverify/trigger_failure |                        crypto.rsa/cmr_thread_roots
>                 extremem-large-31g/adjust_pointers |       scimark.sparse.small/concurrent_thread_roots
>             extremem-large-31g/calculate_addresses |              xml.transform/concurrent_thread_roots
>       crypto.signverify/class_unloading_rendezvous |                    mpegaudio/concurrent_weak_roots
>                                   serial/cmr_total |                        crypto.rsa/ctr_thread_roots
> 
> Shenandoah
> -------------------------------------------------------------------------------------------------------
> +5.64% jython/cwr_total p=0.00037
>   Control:      1.928ms (+/-272.40us)        170
>   Test:         2.037ms (+/-322.73us)        344

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

  Fix compilation errors for ShenandoahSimpleBitMap test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17561/files
  - new: https://git.openjdk.org/jdk/pull/17561/files/12327c0f..4c1cf6a7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17561&range=22
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17561&range=21-22

  Stats: 132 lines in 3 files changed: 4 ins; 87 del; 41 mod
  Patch: https://git.openjdk.org/jdk/pull/17561.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17561/head:pull/17561

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

From kdnilsen at openjdk.org  Tue Mar  5 01:31:51 2024
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Tue, 5 Mar 2024 01:31:51 GMT
Subject: RFR: 8324649: Shenandoah: refactor implementation of free set
 [v24]
In-Reply-To: <VAkn0SrKYZWmnflpM8ZwVAXjUF1LjA0_FCBmRJJ4VSc=.c2f979bd-2957-434e-95ca-7b11b1573900@github.com>
References: <VAkn0SrKYZWmnflpM8ZwVAXjUF1LjA0_FCBmRJJ4VSc=.c2f979bd-2957-434e-95ca-7b11b1573900@github.com>
Message-ID: <2XziAri_q8693Sl4NDung2Oqp7VPVs1cbJcd01o60O8=.401d2bc2-27df-4270-ab8b-eadb37058ab0@github.com>

> Several objectives:
> 1. Reduce humongous allocation failures by segregating regular regions from humongous regions
> 2. Do not retire regions just because an allocation failed within the region if the memory remaining within the region is large enough to represent a LAB
> 3. Track range of empty regions in addition to range of available regions in order to expedite humongous allocations
> 4. Treat collector reserves as available for Mutator allocations after evacuation completes
> 5. Improve encapsulation so as to enable an OldCollector reserve for future integration of generational Shenandoah
> 
> We have compared performance of existing FreeSet implementation with the proposed PR over a broad set of performance workloads and see that the impact is mostly neutral.
> 
> Comparing 105235.0 metrics from control, 220638.0 from experiment.
> Compare: 0.589s
>                           Most impacted benchmarks |                              Most impacted metrics
> -------------------------------------------------------------------------------------------------------
>                                  Shenandoah/jython |                                          cwr_total
> 
> 
>                                 Only in experiment |                                    Only in control
> -------------------------------------------------------------------------------------------------------
>                  crypto.signverify/trigger_failure |                        crypto.rsa/cmr_thread_roots
>                 extremem-large-31g/adjust_pointers |       scimark.sparse.small/concurrent_thread_roots
>             extremem-large-31g/calculate_addresses |              xml.transform/concurrent_thread_roots
>       crypto.signverify/class_unloading_rendezvous |                    mpegaudio/concurrent_weak_roots
>                                   serial/cmr_total |                        crypto.rsa/ctr_thread_roots
> 
> Shenandoah
> -------------------------------------------------------------------------------------------------------
> +5.64% jython/cwr_total p=0.00037
>   Control:      1.928ms (+/-272.40us)        170
>   Test:         2.037ms (+/-322.73us)        344

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

  Add new source file

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17561/files
  - new: https://git.openjdk.org/jdk/pull/17561/files/4c1cf6a7..db7506e2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17561&range=23
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17561&range=22-23

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

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

From kdnilsen at openjdk.org  Tue Mar  5 02:27:03 2024
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Tue, 5 Mar 2024 02:27:03 GMT
Subject: RFR: 8324649: Shenandoah: refactor implementation of free set
 [v25]
In-Reply-To: <VAkn0SrKYZWmnflpM8ZwVAXjUF1LjA0_FCBmRJJ4VSc=.c2f979bd-2957-434e-95ca-7b11b1573900@github.com>
References: <VAkn0SrKYZWmnflpM8ZwVAXjUF1LjA0_FCBmRJJ4VSc=.c2f979bd-2957-434e-95ca-7b11b1573900@github.com>
Message-ID: <3sT2NasYG4ajMCv1GD41AA3m7pQQ0zMBEPCGPZ8qSAU=.fb1f445e-5fbe-4333-8980-c17b57f514c3@github.com>

> Several objectives:
> 1. Reduce humongous allocation failures by segregating regular regions from humongous regions
> 2. Do not retire regions just because an allocation failed within the region if the memory remaining within the region is large enough to represent a LAB
> 3. Track range of empty regions in addition to range of available regions in order to expedite humongous allocations
> 4. Treat collector reserves as available for Mutator allocations after evacuation completes
> 5. Improve encapsulation so as to enable an OldCollector reserve for future integration of generational Shenandoah
> 
> We have compared performance of existing FreeSet implementation with the proposed PR over a broad set of performance workloads and see that the impact is mostly neutral.
> 
> Comparing 105235.0 metrics from control, 220638.0 from experiment.
> Compare: 0.589s
>                           Most impacted benchmarks |                              Most impacted metrics
> -------------------------------------------------------------------------------------------------------
>                                  Shenandoah/jython |                                          cwr_total
> 
> 
>                                 Only in experiment |                                    Only in control
> -------------------------------------------------------------------------------------------------------
>                  crypto.signverify/trigger_failure |                        crypto.rsa/cmr_thread_roots
>                 extremem-large-31g/adjust_pointers |       scimark.sparse.small/concurrent_thread_roots
>             extremem-large-31g/calculate_addresses |              xml.transform/concurrent_thread_roots
>       crypto.signverify/class_unloading_rendezvous |                    mpegaudio/concurrent_weak_roots
>                                   serial/cmr_total |                        crypto.rsa/ctr_thread_roots
> 
> Shenandoah
> -------------------------------------------------------------------------------------------------------
> +5.64% jython/cwr_total p=0.00037
>   Control:      1.928ms (+/-272.40us)        170
>   Test:         2.037ms (+/-322.73us)        344

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

  Fix windows compiler errors

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17561/files
  - new: https://git.openjdk.org/jdk/pull/17561/files/db7506e2..f9d61f23

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17561&range=24
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17561&range=23-24

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

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

From kdnilsen at openjdk.org  Tue Mar  5 04:37:02 2024
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Tue, 5 Mar 2024 04:37:02 GMT
Subject: RFR: 8324649: Shenandoah: refactor implementation of free set
 [v26]
In-Reply-To: <VAkn0SrKYZWmnflpM8ZwVAXjUF1LjA0_FCBmRJJ4VSc=.c2f979bd-2957-434e-95ca-7b11b1573900@github.com>
References: <VAkn0SrKYZWmnflpM8ZwVAXjUF1LjA0_FCBmRJJ4VSc=.c2f979bd-2957-434e-95ca-7b11b1573900@github.com>
Message-ID: <Zj6Jxi58unwv81qt9KoTF8l06RrbVa0rzltH3-cH_4g=.ba757fb8-26e8-490c-b9c6-9832ba30a131@github.com>

> Several objectives:
> 1. Reduce humongous allocation failures by segregating regular regions from humongous regions
> 2. Do not retire regions just because an allocation failed within the region if the memory remaining within the region is large enough to represent a LAB
> 3. Track range of empty regions in addition to range of available regions in order to expedite humongous allocations
> 4. Treat collector reserves as available for Mutator allocations after evacuation completes
> 5. Improve encapsulation so as to enable an OldCollector reserve for future integration of generational Shenandoah
> 
> We have compared performance of existing FreeSet implementation with the proposed PR over a broad set of performance workloads and see that the impact is mostly neutral.
> 
> Comparing 105235.0 metrics from control, 220638.0 from experiment.
> Compare: 0.589s
>                           Most impacted benchmarks |                              Most impacted metrics
> -------------------------------------------------------------------------------------------------------
>                                  Shenandoah/jython |                                          cwr_total
> 
> 
>                                 Only in experiment |                                    Only in control
> -------------------------------------------------------------------------------------------------------
>                  crypto.signverify/trigger_failure |                        crypto.rsa/cmr_thread_roots
>                 extremem-large-31g/adjust_pointers |       scimark.sparse.small/concurrent_thread_roots
>             extremem-large-31g/calculate_addresses |              xml.transform/concurrent_thread_roots
>       crypto.signverify/class_unloading_rendezvous |                    mpegaudio/concurrent_weak_roots
>                                   serial/cmr_total |                        crypto.rsa/ctr_thread_roots
> 
> Shenandoah
> -------------------------------------------------------------------------------------------------------
> +5.64% jython/cwr_total p=0.00037
>   Control:      1.928ms (+/-272.40us)        170
>   Test:         2.037ms (+/-322.73us)        344

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

  Fix another compiler error

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17561/files
  - new: https://git.openjdk.org/jdk/pull/17561/files/f9d61f23..a0b66359

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17561&range=25
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17561&range=24-25

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

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

From kdnilsen at openjdk.org  Tue Mar  5 14:53:10 2024
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Tue, 5 Mar 2024 14:53:10 GMT
Subject: RFR: 8324649: Shenandoah: refactor implementation of free set
 [v27]
In-Reply-To: <VAkn0SrKYZWmnflpM8ZwVAXjUF1LjA0_FCBmRJJ4VSc=.c2f979bd-2957-434e-95ca-7b11b1573900@github.com>
References: <VAkn0SrKYZWmnflpM8ZwVAXjUF1LjA0_FCBmRJJ4VSc=.c2f979bd-2957-434e-95ca-7b11b1573900@github.com>
Message-ID: <Jwp4rOcRVHCUpZLMOb3u-k0YyVaIQkCtcXMHa4H8yuc=.d718d2e2-4d6b-451b-9d84-b3d33c6fe2d0@github.com>

> Several objectives:
> 1. Reduce humongous allocation failures by segregating regular regions from humongous regions
> 2. Do not retire regions just because an allocation failed within the region if the memory remaining within the region is large enough to represent a LAB
> 3. Track range of empty regions in addition to range of available regions in order to expedite humongous allocations
> 4. Treat collector reserves as available for Mutator allocations after evacuation completes
> 5. Improve encapsulation so as to enable an OldCollector reserve for future integration of generational Shenandoah
> 
> We have compared performance of existing FreeSet implementation with the proposed PR over a broad set of performance workloads and see that the impact is mostly neutral.
> 
> Comparing 105235.0 metrics from control, 220638.0 from experiment.
> Compare: 0.589s
>                           Most impacted benchmarks |                              Most impacted metrics
> -------------------------------------------------------------------------------------------------------
>                                  Shenandoah/jython |                                          cwr_total
> 
> 
>                                 Only in experiment |                                    Only in control
> -------------------------------------------------------------------------------------------------------
>                  crypto.signverify/trigger_failure |                        crypto.rsa/cmr_thread_roots
>                 extremem-large-31g/adjust_pointers |       scimark.sparse.small/concurrent_thread_roots
>             extremem-large-31g/calculate_addresses |              xml.transform/concurrent_thread_roots
>       crypto.signverify/class_unloading_rendezvous |                    mpegaudio/concurrent_weak_roots
>                                   serial/cmr_total |                        crypto.rsa/ctr_thread_roots
> 
> Shenandoah
> -------------------------------------------------------------------------------------------------------
> +5.64% jython/cwr_total p=0.00037
>   Control:      1.928ms (+/-272.40us)        170
>   Test:         2.037ms (+/-322.73us)        344

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

  Experiment: force gtest failure to confirm gtest is exercised

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17561/files
  - new: https://git.openjdk.org/jdk/pull/17561/files/a0b66359..9b503079

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17561&range=26
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17561&range=25-26

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

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

From ysr at openjdk.org  Tue Mar  5 17:50:11 2024
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Tue, 5 Mar 2024 17:50:11 GMT
Subject: RFR: 8325885: GenShen: harmonize with JDK-8325671
In-Reply-To: <71hGIAwcRZWW_H_BKfEu04xaJldebABlHZZzZw4oQYg=.a99f7b03-ad4a-4c80-a382-05e2a4c7eaea@github.com>
References: <p2NMmKOTpWvmj-60q4JQoojCjeT7XcsHawdzru4dXqA=.d24ee989-c04b-4a8e-9bb2-e3e6a4132e72@github.com>
 <71hGIAwcRZWW_H_BKfEu04xaJldebABlHZZzZw4oQYg=.a99f7b03-ad4a-4c80-a382-05e2a4c7eaea@github.com>
Message-ID: <Pq19lgGul4G23gwtff9n_diKebgWJrlI301cXKzgxB4=.40fdd897-f9da-4db5-b262-9aae1c03171f@github.com>

On Mon, 4 Mar 2024 21:43:50 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> /issueJDK-8325885
>
> src/hotspot/share/gc/shenandoah/shenandoahConcurrentMark.cpp line 244:
> 
>> 242:   ShenandoahFlushSATBHandshakeClosure flush_satb(qset);
>> 243:   for (uint flushes = 0; flushes < ShenandoahMaxSATBBufferFlushes; flushes++) {
>> 244:     // TODO: ysr : hoist this switch out of the loop & refactor ?? How may
> 
> The default value of ShenandoahMaxSATBBufferFlushes is 5.  I think the number of iterations is typically low.  Given low number of typical iterations, may not be worth it to restructure the loop control.

Good point, I'll clear this comment which was inadvertently left behind here.

To your point, the cost of the switch is far far lower than the work done inside each case statement, so any fears of cost when I initially wrote that comment are overblown.

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

PR Review Comment: https://git.openjdk.org/shenandoah/pull/402#discussion_r1513247442

From ysr at openjdk.org  Tue Mar  5 17:55:15 2024
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Tue, 5 Mar 2024 17:55:15 GMT
Subject: RFR: 8325885: GenShen: harmonize with JDK-8325671 [v2]
In-Reply-To: <Pq19lgGul4G23gwtff9n_diKebgWJrlI301cXKzgxB4=.40fdd897-f9da-4db5-b262-9aae1c03171f@github.com>
References: <p2NMmKOTpWvmj-60q4JQoojCjeT7XcsHawdzru4dXqA=.d24ee989-c04b-4a8e-9bb2-e3e6a4132e72@github.com>
 <71hGIAwcRZWW_H_BKfEu04xaJldebABlHZZzZw4oQYg=.a99f7b03-ad4a-4c80-a382-05e2a4c7eaea@github.com>
 <Pq19lgGul4G23gwtff9n_diKebgWJrlI301cXKzgxB4=.40fdd897-f9da-4db5-b262-9aae1c03171f@github.com>
Message-ID: <oYNT1LMfi7amyPOZQFORFOaOwldfo6UuMoLqkBptM_k=.36139798-7db6-4f88-95ad-df7e4c9eb93a@github.com>

On Tue, 5 Mar 2024 17:46:25 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

>> src/hotspot/share/gc/shenandoah/shenandoahConcurrentMark.cpp line 244:
>> 
>>> 242:   ShenandoahFlushSATBHandshakeClosure flush_satb(qset);
>>> 243:   for (uint flushes = 0; flushes < ShenandoahMaxSATBBufferFlushes; flushes++) {
>>> 244:     // TODO: ysr : hoist this switch out of the loop & refactor ?? How may
>> 
>> The default value of ShenandoahMaxSATBBufferFlushes is 5.  I think the number of iterations is typically low.  Given low number of typical iterations, may not be worth it to restructure the loop control.
>
> Good point, I'll clear this comment which was inadvertently left behind here.
> 
> To your point, the cost of the switch is far far lower than the work done inside each case statement, so any fears of cost when I initially wrote that comment are overblown.

Done.

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

PR Review Comment: https://git.openjdk.org/shenandoah/pull/402#discussion_r1513257958

From ysr at openjdk.org  Tue Mar  5 17:55:15 2024
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Tue, 5 Mar 2024 17:55:15 GMT
Subject: RFR: 8325885: GenShen: harmonize with JDK-8325671 [v2]
In-Reply-To: <p2NMmKOTpWvmj-60q4JQoojCjeT7XcsHawdzru4dXqA=.d24ee989-c04b-4a8e-9bb2-e3e6a4132e72@github.com>
References: <p2NMmKOTpWvmj-60q4JQoojCjeT7XcsHawdzru4dXqA=.d24ee989-c04b-4a8e-9bb2-e3e6a4132e72@github.com>
Message-ID: <-plbAc5B4C_Ilg27gfZ7sZJdub43jrbpsIZmROXK5AE=.583e177a-fe81-42d8-9451-a36cb7805423@github.com>

> /issueJDK-8325885

Y. Srinivas Ramakrishna has updated the pull request incrementally with one additional commit since the last revision:

  Remove TODO comment

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

Changes:
  - all: https://git.openjdk.org/shenandoah/pull/402/files
  - new: https://git.openjdk.org/shenandoah/pull/402/files/c1d38870..d5c0e90a

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

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

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

From ysr at openjdk.org  Tue Mar  5 18:22:16 2024
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Tue, 5 Mar 2024 18:22:16 GMT
Subject: RFR: 8325885: GenShen: harmonize with JDK-8325671 [v2]
In-Reply-To: <-plbAc5B4C_Ilg27gfZ7sZJdub43jrbpsIZmROXK5AE=.583e177a-fe81-42d8-9451-a36cb7805423@github.com>
References: <p2NMmKOTpWvmj-60q4JQoojCjeT7XcsHawdzru4dXqA=.d24ee989-c04b-4a8e-9bb2-e3e6a4132e72@github.com>
 <-plbAc5B4C_Ilg27gfZ7sZJdub43jrbpsIZmROXK5AE=.583e177a-fe81-42d8-9451-a36cb7805423@github.com>
Message-ID: <E26Tguv_h0qvoQNuUhtQEIGy1SlD7X-r0GJLaewZAgw=.08a7a451-51f6-4626-88d1-e200666afe46@github.com>

On Tue, 5 Mar 2024 17:55:15 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

>> Harmonize with the changes in JDK-8325671.
>> 
>> Renames:
>> - GLOBAL_NON_GEN -> NON_GEN
>> - GLOBAL_GEN -> GLOBAL
>> - ? -> UNKNOWN
>> 
>> Some reordering of arguments to follow existing convention.
>> 
>> **Testing:**
>> - [x] GHA (TestHumongous... failures are independent, and addressed in JDK-8327000)
>> - [x] code pipeline testing
>
> Y. Srinivas Ramakrishna has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove TODO comment

Thanks for the review!

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

PR Comment: https://git.openjdk.org/shenandoah/pull/402#issuecomment-1979372144

From ysr at openjdk.org  Tue Mar  5 18:22:16 2024
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Tue, 5 Mar 2024 18:22:16 GMT
Subject: Integrated: 8325885: GenShen: harmonize with JDK-8325671
In-Reply-To: <p2NMmKOTpWvmj-60q4JQoojCjeT7XcsHawdzru4dXqA=.d24ee989-c04b-4a8e-9bb2-e3e6a4132e72@github.com>
References: <p2NMmKOTpWvmj-60q4JQoojCjeT7XcsHawdzru4dXqA=.d24ee989-c04b-4a8e-9bb2-e3e6a4132e72@github.com>
Message-ID: <HwOAI0WVwKa4pVVh-wyTBLiMohFdSOi7d-MrCyVWxnI=.d52eb6aa-21fc-4f22-8e1b-3f0c5e343d57@github.com>

On Sat, 2 Mar 2024 02:15:53 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

> Harmonize with the changes in JDK-8325671.
> 
> Renames:
> - GLOBAL_NON_GEN -> NON_GEN
> - GLOBAL_GEN -> GLOBAL
> - ? -> UNKNOWN
> 
> Some reordering of arguments to follow existing convention.
> 
> **Testing:**
> - [x] GHA (TestHumongous... failures are independent, and addressed in JDK-8327000)
> - [x] code pipeline testing

This pull request has now been integrated.

Changeset: e9a1c699
Author:    Y. Srinivas Ramakrishna <ysr at openjdk.org>
URL:       https://git.openjdk.org/shenandoah/commit/e9a1c69952753979e5d1b0f440cfa1ee71f18033
Stats:     85 lines in 16 files changed: 8 ins; 3 del; 74 mod

8325885: GenShen: harmonize with JDK-8325671

Reviewed-by: kdnilsen

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

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

From kdnilsen at openjdk.org  Tue Mar  5 18:26:07 2024
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Tue, 5 Mar 2024 18:26:07 GMT
Subject: RFR: 8324649: Shenandoah: refactor implementation of free set
 [v28]
In-Reply-To: <VAkn0SrKYZWmnflpM8ZwVAXjUF1LjA0_FCBmRJJ4VSc=.c2f979bd-2957-434e-95ca-7b11b1573900@github.com>
References: <VAkn0SrKYZWmnflpM8ZwVAXjUF1LjA0_FCBmRJJ4VSc=.c2f979bd-2957-434e-95ca-7b11b1573900@github.com>
Message-ID: <5uv7dOIP4efhw5Bsih_wda-xxH5rBTgEkx8TvsaCBdE=.bcd4ba42-2e88-49ed-96d7-5940f6b96b63@github.com>

> Several objectives:
> 1. Reduce humongous allocation failures by segregating regular regions from humongous regions
> 2. Do not retire regions just because an allocation failed within the region if the memory remaining within the region is large enough to represent a LAB
> 3. Track range of empty regions in addition to range of available regions in order to expedite humongous allocations
> 4. Treat collector reserves as available for Mutator allocations after evacuation completes
> 5. Improve encapsulation so as to enable an OldCollector reserve for future integration of generational Shenandoah
> 
> We have compared performance of existing FreeSet implementation with the proposed PR over a broad set of performance workloads and see that the impact is mostly neutral.
> 
> Comparing 105235.0 metrics from control, 220638.0 from experiment.
> Compare: 0.589s
>                           Most impacted benchmarks |                              Most impacted metrics
> -------------------------------------------------------------------------------------------------------
>                                  Shenandoah/jython |                                          cwr_total
> 
> 
>                                 Only in experiment |                                    Only in control
> -------------------------------------------------------------------------------------------------------
>                  crypto.signverify/trigger_failure |                        crypto.rsa/cmr_thread_roots
>                 extremem-large-31g/adjust_pointers |       scimark.sparse.small/concurrent_thread_roots
>             extremem-large-31g/calculate_addresses |              xml.transform/concurrent_thread_roots
>       crypto.signverify/class_unloading_rendezvous |                    mpegaudio/concurrent_weak_roots
>                                   serial/cmr_total |                        crypto.rsa/ctr_thread_roots
> 
> Shenandoah
> -------------------------------------------------------------------------------------------------------
> +5.64% jython/cwr_total p=0.00037
>   Control:      1.928ms (+/-272.40us)        170
>   Test:         2.037ms (+/-322.73us)        344

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

  Changes to Simple BitMap test
  
  Tinkering with code to force tests to run (and fail).

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17561/files
  - new: https://git.openjdk.org/jdk/pull/17561/files/9b503079..4c829475

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17561&range=27
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17561&range=26-27

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

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

From kdnilsen at openjdk.org  Wed Mar  6 00:13:09 2024
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Wed, 6 Mar 2024 00:13:09 GMT
Subject: RFR: 8327097: GenShen: Align PLAB sizes down rather than up
Message-ID: <ubIf-lmCiowlGhyHfBvq-zudoKSzp6MWHaB9UZh5FuM=.27238aa1-a55b-4a19-9cac-e9c4de961613@github.com>

When adjusting LAB sizes, round down rather than rounding up.  Otherwise, we may violate the ShenandoahHumongousThreshold bound.

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

Commit messages:
 - Fix disabling of TestHumongousThreshold on macosx-aarch64
 - Fix up exclude declaration for TestHumongousThreshold.java
 - Forcefully disable TestHumongousThreshold.java tier2 test
 - Try a broader exclusion for TestHumongousThreshold problem list
 - Fix two typos in Problem List
 - Disable TestHumongousThreshold.java test on macos-aarch64
 - Merge remote-tracking branch 'origin/master' into enforce-humongous-threshold-on-tlab
 - Merge branch 'openjdk:master' into master
 - Revert "Round LAB sizes down rather than up to force alignment"
 - Remove over-zealous assertion
 - ... and 8 more: https://git.openjdk.org/shenandoah/compare/fcf8a8c7...3aba4303

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

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

From kdnilsen at openjdk.org  Wed Mar  6 00:13:09 2024
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Wed, 6 Mar 2024 00:13:09 GMT
Subject: RFR: 8327097: GenShen: Align PLAB sizes down rather than up
In-Reply-To: <ubIf-lmCiowlGhyHfBvq-zudoKSzp6MWHaB9UZh5FuM=.27238aa1-a55b-4a19-9cac-e9c4de961613@github.com>
References: <ubIf-lmCiowlGhyHfBvq-zudoKSzp6MWHaB9UZh5FuM=.27238aa1-a55b-4a19-9cac-e9c4de961613@github.com>
Message-ID: <U9_bIkvshGV7GFwhZFUvMldk7nNLvR2KnWjmeoDDzF8=.622a63c2-07e2-482d-a522-b2dbbf964539@github.com>

On Mon, 26 Feb 2024 21:27:37 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

> When adjusting LAB sizes, round down rather than rounding up.  Otherwise, we may violate the ShenandoahHumongousThreshold bound.

Will leave this in draft form until I complete further testing.

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

PR Comment: https://git.openjdk.org/shenandoah/pull/401#issuecomment-1965323194

From wkemper at openjdk.org  Wed Mar  6 00:13:09 2024
From: wkemper at openjdk.org (William Kemper)
Date: Wed, 6 Mar 2024 00:13:09 GMT
Subject: RFR: 8327097: GenShen: Align PLAB sizes down rather than up
In-Reply-To: <ubIf-lmCiowlGhyHfBvq-zudoKSzp6MWHaB9UZh5FuM=.27238aa1-a55b-4a19-9cac-e9c4de961613@github.com>
References: <ubIf-lmCiowlGhyHfBvq-zudoKSzp6MWHaB9UZh5FuM=.27238aa1-a55b-4a19-9cac-e9c4de961613@github.com>
Message-ID: <C_obOOzbVQ4krbDvrJyfkxLOnXYrHQz5HwAXN5hMKlk=.acf28457-c393-4d1c-ae2d-857caeeb3466@github.com>

On Mon, 26 Feb 2024 21:27:37 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

> When adjusting LAB sizes, round down rather than rounding up.  Otherwise, we may violate the ShenandoahHumongousThreshold bound.

test/hotspot/jtreg/ProblemList.txt line 94:

> 92: gc/TestAllocHumongousFragment.java#static 8298781 generic-all
> 93: gc/stress/gclocker/TestExcessGCLockerCollections.java 8229120 generic-all
> 94: gc/shenandoah/TestHumongousThreshold.java 832700 macos-aarch64

Not sure if it matters, but the ticket number looks too short. I also think the os name is `macosx`, based on other disabled tests. If that doesn't work, I think `generic-all` would also be fine temporarily.

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

PR Review Comment: https://git.openjdk.org/shenandoah/pull/401#discussion_r1507936459

From kdnilsen at openjdk.org  Wed Mar  6 00:13:09 2024
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Wed, 6 Mar 2024 00:13:09 GMT
Subject: RFR: 8327097: GenShen: Align PLAB sizes down rather than up
In-Reply-To: <C_obOOzbVQ4krbDvrJyfkxLOnXYrHQz5HwAXN5hMKlk=.acf28457-c393-4d1c-ae2d-857caeeb3466@github.com>
References: <ubIf-lmCiowlGhyHfBvq-zudoKSzp6MWHaB9UZh5FuM=.27238aa1-a55b-4a19-9cac-e9c4de961613@github.com>
 <C_obOOzbVQ4krbDvrJyfkxLOnXYrHQz5HwAXN5hMKlk=.acf28457-c393-4d1c-ae2d-857caeeb3466@github.com>
Message-ID: <994aK7dTm8ywk90nuOaT2r5_7mTSU9k1Zm9IAtyX-dQ=.f6bcdf10-4609-4481-b8bb-3d3d4a6966e9@github.com>

On Thu, 29 Feb 2024 17:25:13 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> When adjusting LAB sizes, round down rather than rounding up.  Otherwise, we may violate the ShenandoahHumongousThreshold bound.
>
> test/hotspot/jtreg/ProblemList.txt line 94:
> 
>> 92: gc/TestAllocHumongousFragment.java#static 8298781 generic-all
>> 93: gc/stress/gclocker/TestExcessGCLockerCollections.java 8229120 generic-all
>> 94: gc/shenandoah/TestHumongousThreshold.java 832700 macos-aarch64
> 
> Not sure if it matters, but the ticket number looks too short. I also think the os name is `macosx`, based on other disabled tests. If that doesn't work, I think `generic-all` would also be fine temporarily.

Good eyes.  Thank you.

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

PR Review Comment: https://git.openjdk.org/shenandoah/pull/401#discussion_r1508042898

From ihse at openjdk.org  Wed Mar  6 12:04:17 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 6 Mar 2024 12:04:17 GMT
Subject: RFR: 8327460: Compile tests with the same visibility rules as product
 code
Message-ID: <W2Xv4ln5Hn3tPW8C10dkuyynyqbLFvB8uxds0huGMms=.16a88981-b23c-4ceb-88fb-bff303de2076@github.com>

Currently, our symbol visibility handling for tests are sloppy; we only handle it properly on Windows. We need to bring it up to the same levels as product code. This is a prerequisite for [JDK-8327045](https://bugs.openjdk.org/browse/JDK-8327045), which in turn is a building block for Hermetic Java.

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

Commit messages:
 - 8327460: Compile tests with the same visibility rules as product code

Changes: https://git.openjdk.org/jdk/pull/18135/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18135&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8327460
  Stats: 303 lines in 38 files changed: 69 ins; 159 del; 75 mod
  Patch: https://git.openjdk.org/jdk/pull/18135.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18135/head:pull/18135

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

From ihse at openjdk.org  Wed Mar  6 12:16:45 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 6 Mar 2024 12:16:45 GMT
Subject: RFR: 8327460: Compile tests with the same visibility rules as
 product code
In-Reply-To: <W2Xv4ln5Hn3tPW8C10dkuyynyqbLFvB8uxds0huGMms=.16a88981-b23c-4ceb-88fb-bff303de2076@github.com>
References: <W2Xv4ln5Hn3tPW8C10dkuyynyqbLFvB8uxds0huGMms=.16a88981-b23c-4ceb-88fb-bff303de2076@github.com>
Message-ID: <D4VnoA_AetZT4vT_WasTrnfsavTpUH4oy8bCTL7HAWY=.5f2b4617-5854-4913-922e-aa84cd9c04a9@github.com>

On Wed, 6 Mar 2024 11:33:30 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Currently, our symbol visibility handling for tests are sloppy; we only handle it properly on Windows. We need to bring it up to the same levels as product code. This is a prerequisite for [JDK-8327045](https://bugs.openjdk.org/browse/JDK-8327045), which in turn is a building block for Hermetic Java.

Most of these changes is just putting the `EXPORT` define in `export.h` instead (where support for `__attribute__((visibility("default")))` is also added). However, there are a few other changes worth mentioning:

* `test/jdk/java/lang/Thread/jni/AttachCurrentThread/libImplicitAttach.c` was missing an export. This had not been discovered before since that file was not compiled on Windows.
* On macOS, the `main` function of a Java launcher needs to be exported, since we re-launch the main function when starting a new thread. (This is utterly weird behavior driven by how on macOS the main thread is reserved for Cocoa events, and I'm not sure this is properly documented by the JNI specification). 
* The `dereference_null` function from `libTestDwarfHelper.h` is looked for in the Hotspot hs_err stack trace in `test/hotspot/jtreg/runtime/ErrorHandling/TestDwarf.java`. When compiling with `-fvisibility=hidden`, it became inline and the test failed. I solved this by exporting the function, thus restoring the same situation as was before. I'm not sure this is the correct or best solution though, since it depends on what you expect `TestDwarf.java` to really achieve. (You can't expect of it to perform miracles and show functions that has been inlined in stack traces, though...)

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

PR Comment: https://git.openjdk.org/jdk/pull/18135#issuecomment-1980739771

From ihse at openjdk.org  Wed Mar  6 13:43:00 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 6 Mar 2024 13:43:00 GMT
Subject: RFR: 8327460: Compile tests with the same visibility rules as
 product code [v2]
In-Reply-To: <W2Xv4ln5Hn3tPW8C10dkuyynyqbLFvB8uxds0huGMms=.16a88981-b23c-4ceb-88fb-bff303de2076@github.com>
References: <W2Xv4ln5Hn3tPW8C10dkuyynyqbLFvB8uxds0huGMms=.16a88981-b23c-4ceb-88fb-bff303de2076@github.com>
Message-ID: <pnjREovJalRYYzpMToibwGdUxZbOZ2FfO6hJowlG2J0=.e0947aa0-2af9-4785-93bb-18f1cf6bfef3@github.com>

> Currently, our symbol visibility handling for tests are sloppy; we only handle it properly on Windows. We need to bring it up to the same levels as product code. This is a prerequisite for [JDK-8327045](https://bugs.openjdk.org/browse/JDK-8327045), which in turn is a building block for Hermetic Java.

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

  Update line number for dereference_null  in TestDwarf

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18135/files
  - new: https://git.openjdk.org/jdk/pull/18135/files/1dc79758..b1bf01ad

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

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

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

From erikj at openjdk.org  Wed Mar  6 13:51:46 2024
From: erikj at openjdk.org (Erik Joelsson)
Date: Wed, 6 Mar 2024 13:51:46 GMT
Subject: RFR: 8327460: Compile tests with the same visibility rules as
 product code [v2]
In-Reply-To: <pnjREovJalRYYzpMToibwGdUxZbOZ2FfO6hJowlG2J0=.e0947aa0-2af9-4785-93bb-18f1cf6bfef3@github.com>
References: <W2Xv4ln5Hn3tPW8C10dkuyynyqbLFvB8uxds0huGMms=.16a88981-b23c-4ceb-88fb-bff303de2076@github.com>
 <pnjREovJalRYYzpMToibwGdUxZbOZ2FfO6hJowlG2J0=.e0947aa0-2af9-4785-93bb-18f1cf6bfef3@github.com>
Message-ID: <T9joul4A3qCerggx27eSyiUW5npWCAJo46tukWvEyy4=.66d8eb4d-3747-4741-b2aa-c313b9523829@github.com>

On Wed, 6 Mar 2024 13:43:00 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Currently, our symbol visibility handling for tests are sloppy; we only handle it properly on Windows. We need to bring it up to the same levels as product code. This is a prerequisite for [JDK-8327045](https://bugs.openjdk.org/browse/JDK-8327045), which in turn is a building block for Hermetic Java.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update line number for dereference_null  in TestDwarf

Build system changes look good to me. The specific test changes probably needs other reviewers.

I assume you have run all the affected tests on a wide variety of platforms?

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

Marked as reviewed by erikj (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18135#pullrequestreview-1919814110

From ihse at openjdk.org  Wed Mar  6 13:55:46 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 6 Mar 2024 13:55:46 GMT
Subject: RFR: 8327460: Compile tests with the same visibility rules as
 product code [v2]
In-Reply-To: <pnjREovJalRYYzpMToibwGdUxZbOZ2FfO6hJowlG2J0=.e0947aa0-2af9-4785-93bb-18f1cf6bfef3@github.com>
References: <W2Xv4ln5Hn3tPW8C10dkuyynyqbLFvB8uxds0huGMms=.16a88981-b23c-4ceb-88fb-bff303de2076@github.com>
 <pnjREovJalRYYzpMToibwGdUxZbOZ2FfO6hJowlG2J0=.e0947aa0-2af9-4785-93bb-18f1cf6bfef3@github.com>
Message-ID: <qrvOs87-Kt6FXps9AhHaYb4uBfwN-zdNkvgy4ym6H8Q=.eeca8b49-0baf-4c8e-9217-f4133b41830f@github.com>

On Wed, 6 Mar 2024 13:43:00 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Currently, our symbol visibility handling for tests are sloppy; we only handle it properly on Windows. We need to bring it up to the same levels as product code. This is a prerequisite for [JDK-8327045](https://bugs.openjdk.org/browse/JDK-8327045), which in turn is a building block for Hermetic Java.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update line number for dereference_null  in TestDwarf

I have run the tests in tier1, tier2 and tier3 on the Oracle internal CI, which includes linux/x64, linux/aarch64, windows/x64, macosx/x64 and macosx/aarch64. 

I am currently running tier 4-10; this will take a while (and I won't integrate until this has finished running). When running multiple high-tier tests like this, the likelihood that I encounter intermittent problems increase. I will ignore test failures that seem likely to be intermittent and not caused by this patch. I might be overdoing the testing, but since this change affects **all** native tests, I want to be absolutely sure I don't break any tests that only execute as part of a high tier.

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

PR Comment: https://git.openjdk.org/jdk/pull/18135#issuecomment-1980924971

From ysr at openjdk.org  Wed Mar  6 20:46:04 2024
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Wed, 6 Mar 2024 20:46:04 GMT
Subject: RFR: 8327097: GenShen: Align PLAB sizes down rather than up
In-Reply-To: <ubIf-lmCiowlGhyHfBvq-zudoKSzp6MWHaB9UZh5FuM=.27238aa1-a55b-4a19-9cac-e9c4de961613@github.com>
References: <ubIf-lmCiowlGhyHfBvq-zudoKSzp6MWHaB9UZh5FuM=.27238aa1-a55b-4a19-9cac-e9c4de961613@github.com>
Message-ID: <eXK3thsHz9Yiil_Sd00EMQ3mgel01QLbxZo4e6NAezQ=.7865b9a4-649b-41dd-ad69-9f5921aec328@github.com>

On Mon, 26 Feb 2024 21:27:37 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

> When adjusting LAB sizes, round down rather than rounding up.  Otherwise, we may violate the ShenandoahHumongousThreshold bound.

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

> 1112:   future_size = MIN2(future_size, PLAB::max_size());
> 1113:   future_size = MAX2(future_size, PLAB::min_size());
> 1114:   future_size = align_down(future_size, CardTable::card_size_in_words());

Can one use cardsize-aligned min and max sizes (taking whetever PLAB gives us, may be by using a ShenandoahPLAB subclass). We then first align future_size up wrt card size, then floor/clamp it with the already cardsize-aligned min and max?

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

PR Review Comment: https://git.openjdk.org/shenandoah/pull/401#discussion_r1515130844

From ysr at openjdk.org  Thu Mar  7 02:36:24 2024
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Thu, 7 Mar 2024 02:36:24 GMT
Subject: RFR: 8327388: GenShen: census during marking is partial
Message-ID: <g_Iob3H5hUHpr6iN1nzSSSM_u7_8z9hO6Al52hRtyUc=.ee22a343-8e84-454f-8da0-541cd3146026@github.com>

There was a bug in the placement of the call to clear stale census data before starting a fresh one for a new marking cycle that marks through the younger generation. This bug resulted in the use of a co-terminal suffix of the census collection, losing all data from the earlier iterations of an iterative collection process that may run up to 5 times.

We stumbled upon the defect when working on a refactoring task involving separation of generational extensions of Shenandoah from its non-generational version. The (performance) defect has existed since day zero of the adaptive tenuring code in GenShen.

Along with fixing the defect, an assertion has been added to check the "reasonable completeness" of the census, which came in useful to detect a reset call inadvertently left behind in one place.

Some ShenandoahAgeCensus APIs have been narrowed and cleaned up a bit, and documentation clarified a bit more.

**Testing**: TBD
- [ ] GHA
- [ ] Code pipeline testing
- [ ] SpecJBB

**Performance**: TBD
In an early round of measurements, we saw no statistically significant change in performance (including with SPECjbb) -- we eyeballed the tenuring threshold values over a random pair of runs and didn't notice any differences either. A fresh round of tests will be done and updated here.

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

Commit messages:
 - Remove local_reset of age_census object inadvertently left behind in the
 - Avoid divide-by-zero.
 - Merge branch 'master' into clear_census
 - Fix word and byte size unit confusion in comparison/assert.
 - Loose verification of "reasonable completeness" of census.
 - Fix release build.
 - Support for verification of census' reasonableness, but no verification
 - ShenandoahGlobalGeneration also resets local age census data in
 - Fix/elaborate some more documentation. Move age census reset to young
 - Narrower public inerface; documentation.
 - ... and 3 more: https://git.openjdk.org/shenandoah/compare/e9a1c699...be38e9e6

Changes: https://git.openjdk.org/shenandoah/pull/403/files
 Webrev: https://webrevs.openjdk.org/?repo=shenandoah&pr=403&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8327388
  Stats: 167 lines in 11 files changed: 122 ins; 27 del; 18 mod
  Patch: https://git.openjdk.org/shenandoah/pull/403.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah.git pull/403/head:pull/403

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

From duke at openjdk.org  Thu Mar  7 08:06:28 2024
From: duke at openjdk.org (Yude Lin)
Date: Thu, 7 Mar 2024 08:06:28 GMT
Subject: RFR: 8327522: Shenandoah: Remove unused references to
 satb_mark_queue_active_offset
Message-ID: <FHAGyiw9p9dB_4zEe4Wnd9LlJMK3xwqPhvEnWPiJyhU=.ebf25823-d198-4d87-8230-b52ab6919748@github.com>

Removed an unused variable (trivial)

Also, there is another place that uses satb_mark_queue_active_offset which is ShenandoahBarrierSetC2::verify_gc_barriers
The current barrier pattern is different from what this code is expecting:
If->Bool->CmpI->AndI->LoadUB->AddP->ConL(gc_state_offset)
rather than
If->Bool->CmpI->LoadB->AddP->ConL(marking_offset)
However, this code isn't doing as much checking as its counterpart in G1 anyway (so I'm thinking removing the incorrect matching code altogether?) Looking forward to your suggestions.

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

Commit messages:
 - 8327522: Shenandoah: Remove unused references to satb_mark_queue_active_offset

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

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

From wkemper at openjdk.org  Thu Mar  7 14:22:30 2024
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 7 Mar 2024 14:22:30 GMT
Subject: RFR: Merge openjdk/jdk21u-dev:master
Message-ID: <8R15RlV-MVnyBG779EhSs6ZOYLCJmEBKdJ-z0IARgc0=.6b4d4d1c-16ce-4d2e-a651-8c6adda5bd6e@github.com>

Merges tag jdk-21.0.3+6

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

Commit messages:
 - 8322750: Test "api/java_awt/interactive/SystemTrayTests.html" failed because A blue ball icon is added outside of the system tray
 - 8323664: java/awt/font/JNICheck/FreeTypeScalerJNICheck.java still fails with JNI warning on some Windows configurations
 - 8325496: Make TrimNativeHeapInterval a product switch
 - 8321151: JDK-8294427 breaks Windows L&F on all older Windows versions
 - 8325876: crashes in docker container tests on Linuxppc64le Power8 machines
 - 8325470: [AIX] use fclose after fopen in read_psinfo
 - 8320303: Allow PassFailJFrame to accept single window creator
 - 8326000: Remove obsolete comments for class sun.security.ssl.SunJSSE
 - 8314835: gtest wrappers should be marked as flagless
 - 8325254: CKA_TOKEN private and secret keys are not necessarily sensitive
 - ... and 35 more: https://git.openjdk.org/shenandoah-jdk21u/compare/57956950...29bf21fd

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

Changes: https://git.openjdk.org/shenandoah-jdk21u/pull/26/files
  Stats: 3260 lines in 177 files changed: 2507 ins; 194 del; 559 mod
  Patch: https://git.openjdk.org/shenandoah-jdk21u/pull/26.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah-jdk21u.git pull/26/head:pull/26

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

From kdnilsen at openjdk.org  Thu Mar  7 18:48:25 2024
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Thu, 7 Mar 2024 18:48:25 GMT
Subject: RFR: 8324649: Shenandoah: refactor implementation of free set
 [v29]
In-Reply-To: <VAkn0SrKYZWmnflpM8ZwVAXjUF1LjA0_FCBmRJJ4VSc=.c2f979bd-2957-434e-95ca-7b11b1573900@github.com>
References: <VAkn0SrKYZWmnflpM8ZwVAXjUF1LjA0_FCBmRJJ4VSc=.c2f979bd-2957-434e-95ca-7b11b1573900@github.com>
Message-ID: <R6qwDmmgcrRDk8j-Vc_FIbWJPhxPh5yFAO-cR2XLGlQ=.33bb870c-7025-4de4-bdc5-e0b33aee1369@github.com>

> Several objectives:
> 1. Reduce humongous allocation failures by segregating regular regions from humongous regions
> 2. Do not retire regions just because an allocation failed within the region if the memory remaining within the region is large enough to represent a LAB
> 3. Track range of empty regions in addition to range of available regions in order to expedite humongous allocations
> 4. Treat collector reserves as available for Mutator allocations after evacuation completes
> 5. Improve encapsulation so as to enable an OldCollector reserve for future integration of generational Shenandoah
> 
> We have compared performance of existing FreeSet implementation with the proposed PR over a broad set of performance workloads and see that the impact is mostly neutral.
> 
> Comparing 105235.0 metrics from control, 220638.0 from experiment.
> Compare: 0.589s
>                           Most impacted benchmarks |                              Most impacted metrics
> -------------------------------------------------------------------------------------------------------
>                                  Shenandoah/jython |                                          cwr_total
> 
> 
>                                 Only in experiment |                                    Only in control
> -------------------------------------------------------------------------------------------------------
>                  crypto.signverify/trigger_failure |                        crypto.rsa/cmr_thread_roots
>                 extremem-large-31g/adjust_pointers |       scimark.sparse.small/concurrent_thread_roots
>             extremem-large-31g/calculate_addresses |              xml.transform/concurrent_thread_roots
>       crypto.signverify/class_unloading_rendezvous |                    mpegaudio/concurrent_weak_roots
>                                   serial/cmr_total |                        crypto.rsa/ctr_thread_roots
> 
> Shenandoah
> -------------------------------------------------------------------------------------------------------
> +5.64% jython/cwr_total p=0.00037
>   Control:      1.928ms (+/-272.40us)        170
>   Test:         2.037ms (+/-322.73us)        344

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

  Fix gtest for ShenandoahSimpleBitMap and fix ShennadoahSimpleBitMap bugs

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17561/files
  - new: https://git.openjdk.org/jdk/pull/17561/files/4c829475..6d71c324

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17561&range=28
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17561&range=27-28

  Stats: 141 lines in 2 files changed: 40 ins; 32 del; 69 mod
  Patch: https://git.openjdk.org/jdk/pull/17561.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17561/head:pull/17561

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

From ysr at openjdk.org  Fri Mar  8 00:53:13 2024
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Fri, 8 Mar 2024 00:53:13 GMT
Subject: RFR: 8327097: GenShen: Align PLAB sizes down rather than up
In-Reply-To: <ubIf-lmCiowlGhyHfBvq-zudoKSzp6MWHaB9UZh5FuM=.27238aa1-a55b-4a19-9cac-e9c4de961613@github.com>
References: <ubIf-lmCiowlGhyHfBvq-zudoKSzp6MWHaB9UZh5FuM=.27238aa1-a55b-4a19-9cac-e9c4de961613@github.com>
Message-ID: <GyE7WRRKyoXu1usuLw7vygkNsJMY8jHH9LhMbTjFyyU=.a1f2fbba-f36c-49a7-9101-7716cb081129@github.com>

On Mon, 26 Feb 2024 21:27:37 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

> When adjusting LAB sizes, round down rather than rounding up.  Otherwise, we may violate the ShenandoahHumongousThreshold bound.

Changes requested by ysr (Committer).

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

PR Review: https://git.openjdk.org/shenandoah/pull/401#pullrequestreview-1923822421

From ysr at openjdk.org  Fri Mar  8 00:53:14 2024
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Fri, 8 Mar 2024 00:53:14 GMT
Subject: RFR: 8327097: GenShen: Align PLAB sizes down rather than up
In-Reply-To: <eXK3thsHz9Yiil_Sd00EMQ3mgel01QLbxZo4e6NAezQ=.7865b9a4-649b-41dd-ad69-9f5921aec328@github.com>
References: <ubIf-lmCiowlGhyHfBvq-zudoKSzp6MWHaB9UZh5FuM=.27238aa1-a55b-4a19-9cac-e9c4de961613@github.com>
 <eXK3thsHz9Yiil_Sd00EMQ3mgel01QLbxZo4e6NAezQ=.7865b9a4-649b-41dd-ad69-9f5921aec328@github.com>
Message-ID: <A0S4fIqHFmrNs_fJQkQdAAca9pCqaEJGymYbD0f9Giw=.d7bce5e4-1bb2-478c-8896-f12b1d119710@github.com>

On Wed, 6 Mar 2024 20:43:03 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

>> When adjusting LAB sizes, round down rather than rounding up.  Otherwise, we may violate the ShenandoahHumongousThreshold bound.
>
> src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp line 1114:
> 
>> 1112:   future_size = MIN2(future_size, PLAB::max_size());
>> 1113:   future_size = MAX2(future_size, PLAB::min_size());
>> 1114:   future_size = align_down(future_size, CardTable::card_size_in_words());
> 
> Can one use cardsize-aligned min and max sizes (taking whetever PLAB gives us, may be by using a ShenandoahPLAB subclass). We then first align future_size up wrt card size, then floor/clamp it with the already cardsize-aligned min and max?
> 
> In particular if cur_size starts off a multiple of cardsize then any doubling keeps it a multiple of cardsize, and you can more simply perhaps just assert that it's always  a cardsize-multiple.

We also need a comment somewhere stating why we need these to be card-aligned.

I wonder also if this is entirely correct in itself, unless the shared allocation itself also always leaves us with a card-aligned top from which these PLABs are allocated.

In particular, it would be good to assert that `allocate_new_plab()` always gives us back a card-aligned start address.

Would be good to also use `align_up` or `align_down` in `allocate_new_plab()` as well. Indeed, it might be a good idea to do so in any code in Shenandoah where we are unnecessarily rolling our own custom alignment code.

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

PR Review Comment: https://git.openjdk.org/shenandoah/pull/401#discussion_r1517018057

From ysr at openjdk.org  Fri Mar  8 00:53:14 2024
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Fri, 8 Mar 2024 00:53:14 GMT
Subject: RFR: 8327097: GenShen: Align PLAB sizes down rather than up
In-Reply-To: <A0S4fIqHFmrNs_fJQkQdAAca9pCqaEJGymYbD0f9Giw=.d7bce5e4-1bb2-478c-8896-f12b1d119710@github.com>
References: <ubIf-lmCiowlGhyHfBvq-zudoKSzp6MWHaB9UZh5FuM=.27238aa1-a55b-4a19-9cac-e9c4de961613@github.com>
 <eXK3thsHz9Yiil_Sd00EMQ3mgel01QLbxZo4e6NAezQ=.7865b9a4-649b-41dd-ad69-9f5921aec328@github.com>
 <A0S4fIqHFmrNs_fJQkQdAAca9pCqaEJGymYbD0f9Giw=.d7bce5e4-1bb2-478c-8896-f12b1d119710@github.com>
Message-ID: <mWLjI1Jn_8Pvc45ufglRPgd1RNnPci9KmKcfXorxm6M=.29a39f66-f7cf-4e87-b760-88a8802360d0@github.com>

On Fri, 8 Mar 2024 00:30:55 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

>> src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp line 1114:
>> 
>>> 1112:   future_size = MIN2(future_size, PLAB::max_size());
>>> 1113:   future_size = MAX2(future_size, PLAB::min_size());
>>> 1114:   future_size = align_down(future_size, CardTable::card_size_in_words());
>> 
>> Can one use cardsize-aligned min and max sizes (taking whetever PLAB gives us, may be by using a ShenandoahPLAB subclass). We then first align future_size up wrt card size, then floor/clamp it with the already cardsize-aligned min and max?
>> 
>> In particular if cur_size starts off a multiple of cardsize then any doubling keeps it a multiple of cardsize, and you can more simply perhaps just assert that it's always  a cardsize-multiple.
>
> We also need a comment somewhere stating why we need these to be card-aligned.
> 
> I wonder also if this is entirely correct in itself, unless the shared allocation itself also always leaves us with a card-aligned top from which these PLABs are allocated.
> 
> In particular, it would be good to assert that `allocate_new_plab()` always gives us back a card-aligned start address.
> 
> Would be good to also use `align_up` or `align_down` in `allocate_new_plab()` as well. Indeed, it might be a good idea to do so in any code in Shenandoah where we are unnecessarily rolling our own custom alignment code.

There's also a couple of assertion checks in `ShenandoahFreeSet::allocate_aligned_plab()` that use the modulus operation, which should probably use `is_aligned()` instead.

Would be good to clean those up as well while we are taking care of this.

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

PR Review Comment: https://git.openjdk.org/shenandoah/pull/401#discussion_r1517028913

From ihse at openjdk.org  Fri Mar  8 08:10:53 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 8 Mar 2024 08:10:53 GMT
Subject: RFR: 8327460: Compile tests with the same visibility rules as
 product code [v2]
In-Reply-To: <qrvOs87-Kt6FXps9AhHaYb4uBfwN-zdNkvgy4ym6H8Q=.eeca8b49-0baf-4c8e-9217-f4133b41830f@github.com>
References: <W2Xv4ln5Hn3tPW8C10dkuyynyqbLFvB8uxds0huGMms=.16a88981-b23c-4ceb-88fb-bff303de2076@github.com>
 <pnjREovJalRYYzpMToibwGdUxZbOZ2FfO6hJowlG2J0=.e0947aa0-2af9-4785-93bb-18f1cf6bfef3@github.com>
 <qrvOs87-Kt6FXps9AhHaYb4uBfwN-zdNkvgy4ym6H8Q=.eeca8b49-0baf-4c8e-9217-f4133b41830f@github.com>
Message-ID: <fjS6N3QoLZ6q-2scpsHhs5z6eQOo920Toq9o-ACeNT8=.b1cc8955-ee9f-4b8a-bbd0-59573c34e9e5@github.com>

On Wed, 6 Mar 2024 13:53:06 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> I am currently running tier 4-10

This is now done. A handful of tests failed, but all are due to transient environmental problems, known errors, or seemingly intermittent product errors -- none are due to symbol visibility.

So I'd argue that this is one of the most well-tested PRs posted ever. :-)

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

PR Comment: https://git.openjdk.org/jdk/pull/18135#issuecomment-1985232111

From wkemper at openjdk.org  Fri Mar  8 14:19:30 2024
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 8 Mar 2024 14:19:30 GMT
Subject: RFR: Merge openjdk/jdk:master
Message-ID: <YxtDv_HGCQSXqEpNmPAYgPU3PBbXc0jDrHEN_WDq9hQ=.8de63ded-c2bf-43d8-b39b-2b659453483c@github.com>

Merges tag jdk-23+13

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

Commit messages:
 - 8327172: C2 SuperWord: data node in loop has no input in loop: replace assert with bailout
 - 8327379: Make TimeLinearScan a develop flag
 - 8327434: Test java/util/PluggableLocale/TimeZoneNameProviderTest.java timed out
 - 8325532: serviceability/dcmd/compiler/PerfMapTest.java leaves created files in the /tmp dir.
 - 8327173: HotSpot Style Guide needs update regarding nullptr vs NULL
 - 8325878: Require minimum Clang version 13
 - 8325880: Require minimum Open XL C/C++ version 17.1.1
 - 8326718: Test java/util/Formatter/Padding.java should timeout on large inputs before fix in JDK-8299677
 - 8326983: Unused operands reported after JDK-8326135
 - 8327261: Parsing test for Double/Float succeeds w/o testing all bad cases
 - ... and 248 more: https://git.openjdk.org/shenandoah/compare/8cb9b479...f54e5983

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

Changes: https://git.openjdk.org/shenandoah/pull/404/files
  Stats: 99380 lines in 2172 files changed: 16750 ins; 74971 del; 7659 mod
  Patch: https://git.openjdk.org/shenandoah/pull/404.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah.git pull/404/head:pull/404

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

From ihse at openjdk.org  Fri Mar  8 17:01:54 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 8 Mar 2024 17:01:54 GMT
Subject: RFR: 8327460: Compile tests with the same visibility rules as
 product code [v2]
In-Reply-To: <pnjREovJalRYYzpMToibwGdUxZbOZ2FfO6hJowlG2J0=.e0947aa0-2af9-4785-93bb-18f1cf6bfef3@github.com>
References: <W2Xv4ln5Hn3tPW8C10dkuyynyqbLFvB8uxds0huGMms=.16a88981-b23c-4ceb-88fb-bff303de2076@github.com>
 <pnjREovJalRYYzpMToibwGdUxZbOZ2FfO6hJowlG2J0=.e0947aa0-2af9-4785-93bb-18f1cf6bfef3@github.com>
Message-ID: <iJXCpxHnzpiPbZBMD92Qayac44EVPs5-pAsQCKEXl7g=.eb918138-03ac-4c56-95c8-424573780d45@github.com>

On Wed, 6 Mar 2024 13:43:00 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Currently, our symbol visibility handling for tests are sloppy; we only handle it properly on Windows. We need to bring it up to the same levels as product code. This is a prerequisite for [JDK-8327045](https://bugs.openjdk.org/browse/JDK-8327045), which in turn is a building block for Hermetic Java.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update line number for dereference_null  in TestDwarf

@JornVernee Are you okay with this solution? No JNI in foreign tests.

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

PR Comment: https://git.openjdk.org/jdk/pull/18135#issuecomment-1986062755

From jvernee at openjdk.org  Fri Mar  8 18:15:53 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Fri, 8 Mar 2024 18:15:53 GMT
Subject: RFR: 8327460: Compile tests with the same visibility rules as
 product code [v2]
In-Reply-To: <pnjREovJalRYYzpMToibwGdUxZbOZ2FfO6hJowlG2J0=.e0947aa0-2af9-4785-93bb-18f1cf6bfef3@github.com>
References: <W2Xv4ln5Hn3tPW8C10dkuyynyqbLFvB8uxds0huGMms=.16a88981-b23c-4ceb-88fb-bff303de2076@github.com>
 <pnjREovJalRYYzpMToibwGdUxZbOZ2FfO6hJowlG2J0=.e0947aa0-2af9-4785-93bb-18f1cf6bfef3@github.com>
Message-ID: <YvnZO9thUwxN_O0wk1moNpQvP8PLakWzD31_zlBQ5l0=.eee10e2d-5d7b-40ab-b5d9-c440d83671e6@github.com>

An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/shenandoah-dev/attachments/20240308/3b8237ac/attachment.htm>

From jpai at openjdk.org  Sun Mar 10 10:19:54 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sun, 10 Mar 2024 10:19:54 GMT
Subject: RFR: 8327729: Remove deprecated xxxObject methods from
 jdk.internal.misc.Unsafe [v2]
In-Reply-To: <Rmd6v71CRqIWWfLsOnONk1qlv9beucybuXC-b-4C3Ps=.17c4e509-6f78-468a-8f35-d007830b37f6@github.com>
References: <_R4_060_hbsKkeKvbuME6SLIfltbo5lmrQb0dHTpY1Q=.06c07eaa-5135-4dad-b4e1-65ef7a0000bc@github.com>
 <Rmd6v71CRqIWWfLsOnONk1qlv9beucybuXC-b-4C3Ps=.17c4e509-6f78-468a-8f35-d007830b37f6@github.com>
Message-ID: <KMVfpKIdNyS7-lp0oKh9BZ3XpUR2me_IJAxYaQXuhNA=.8199ca0c-7680-40d8-a430-21c79ef73f06@github.com>

On Sun, 10 Mar 2024 08:14:02 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

>> Please review this PR which removes the 19 deprecated `xxObject*` alias methods from `jdk.internal.misc.Unsafe`.
>> 
>> These methods were added in JDK-8213043 (JDK 12), presumably to allow `jsr166.jar` to be used across JDK versions. This was a follow-up fix after JDK-8207146 had renamed these methods to `xxReference*'.
>> 
>> Since OpenJDK is now the single source of truth for `java.util.concurrent`, time has come to remove these deprecated alias methods.
>> 
>> This change was initially discussed here: https://mail.openjdk.org/pipermail/core-libs-dev/2024-March/119993.html
>> 
>> Testing: This is a pure deletion of deprecated methods, so the PR includes no test changes and the `noreg-cleanup` label is added in the JBS. I have verified that all `test/jdk/java/util/concurrent/*` tests pass.
>> 
>> Tagging @DougLea and @Martin-Buchholz to verify that this removal is timely.
>
> Eirik Bj?rsn?s has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use getAndSetReference instead of getAndSetObject in test/hotspot/jtreg/gc/shenandoah/compiler/TestUnsafeLoadStoreMergedHeapStableTests.java

Hello Eirik, I've triggered internal CI testing of the current state of this PR to run tier1, tier2 and tier3.

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

PR Comment: https://git.openjdk.org/jdk/pull/18176#issuecomment-1987173153

From alanb at openjdk.org  Sun Mar 10 12:20:53 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 10 Mar 2024 12:20:53 GMT
Subject: RFR: 8327729: Remove deprecated xxxObject methods from
 jdk.internal.misc.Unsafe [v2]
In-Reply-To: <S9mqT3WkthYe2tbv3nrVvOoqrYDJMJtPn8YL9HNOejI=.52fa4627-5c6c-4e7e-a5b1-524e64d38a24@github.com>
References: <_R4_060_hbsKkeKvbuME6SLIfltbo5lmrQb0dHTpY1Q=.06c07eaa-5135-4dad-b4e1-65ef7a0000bc@github.com>
 <Rmd6v71CRqIWWfLsOnONk1qlv9beucybuXC-b-4C3Ps=.17c4e509-6f78-468a-8f35-d007830b37f6@github.com>
 <S9mqT3WkthYe2tbv3nrVvOoqrYDJMJtPn8YL9HNOejI=.52fa4627-5c6c-4e7e-a5b1-524e64d38a24@github.com>
Message-ID: <mvqdpLUoz04ti59FH9JT8ZyKSFei-0CIjEMWkJNm3NY=.e3144ab0-1fe5-49f9-a125-bb3eac04d057@github.com>

On Sun, 10 Mar 2024 08:24:42 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

> GHA revealed two call sites for `getAndSetObject` in the test `test/hotspot/jtreg/gc/shenandoah/compiler/TestUnsafeLoadStoreMergedHeapStableTests.java`.
> 
> I have replaced these with the `getAndSetReference`, grepped for any remaining uses without finding anything. Let's see what GHA says.

Yes, you'll need to run all tests to make sure that there aren't any others, e.g. test/hotspot/jtreg/compiler/stable/TestUnstableStable.java.

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

PR Comment: https://git.openjdk.org/jdk/pull/18176#issuecomment-1987207527

From eirbjo at openjdk.org  Sun Mar 10 13:47:06 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Sun, 10 Mar 2024 13:47:06 GMT
Subject: RFR: 8327729: Remove deprecated xxxObject methods from
 jdk.internal.misc.Unsafe [v3]
In-Reply-To: <_R4_060_hbsKkeKvbuME6SLIfltbo5lmrQb0dHTpY1Q=.06c07eaa-5135-4dad-b4e1-65ef7a0000bc@github.com>
References: <_R4_060_hbsKkeKvbuME6SLIfltbo5lmrQb0dHTpY1Q=.06c07eaa-5135-4dad-b4e1-65ef7a0000bc@github.com>
Message-ID: <4Z6CqKTSgNaTYilIvNjnGudJOs8qebTs4OhP5q7xShE=.e71ecd8c-5563-4daf-bf9c-56850d69d7ec@github.com>

> Please review this PR which removes the 19 deprecated `xxObject*` alias methods from `jdk.internal.misc.Unsafe`.
> 
> These methods were added in JDK-8213043 (JDK 12), presumably to allow `jsr166.jar` to be used across JDK versions. This was a follow-up fix after JDK-8207146 had renamed these methods to `xxReference*'.
> 
> Since OpenJDK is now the single source of truth for `java.util.concurrent`, time has come to remove these deprecated alias methods.
> 
> This change was initially discussed here: https://mail.openjdk.org/pipermail/core-libs-dev/2024-March/119993.html
> 
> Testing: This is a pure deletion of deprecated methods, so the PR includes no test changes and the `noreg-cleanup` label is added in the JBS. I have verified that all `test/jdk/java/util/concurrent/*` tests pass.
> 
> Tagging @DougLea and @Martin-Buchholz to verify that this removal is timely.

Eirik Bj?rsn?s has updated the pull request incrementally with two additional commits since the last revision:

 - Replace calls to Unsafe.putObject with Unsafe.putReference
 - Update a code comment referencing Unsafe.compareAndSetObject to reference Unsafe.compareAndSetReference instead

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18176/files
  - new: https://git.openjdk.org/jdk/pull/18176/files/a333ed30..e199f6b0

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

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

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

From eirbjo at openjdk.org  Sun Mar 10 13:50:54 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Sun, 10 Mar 2024 13:50:54 GMT
Subject: RFR: 8327729: Remove deprecated xxxObject methods from
 jdk.internal.misc.Unsafe [v2]
In-Reply-To: <mvqdpLUoz04ti59FH9JT8ZyKSFei-0CIjEMWkJNm3NY=.e3144ab0-1fe5-49f9-a125-bb3eac04d057@github.com>
References: <_R4_060_hbsKkeKvbuME6SLIfltbo5lmrQb0dHTpY1Q=.06c07eaa-5135-4dad-b4e1-65ef7a0000bc@github.com>
 <Rmd6v71CRqIWWfLsOnONk1qlv9beucybuXC-b-4C3Ps=.17c4e509-6f78-468a-8f35-d007830b37f6@github.com>
 <S9mqT3WkthYe2tbv3nrVvOoqrYDJMJtPn8YL9HNOejI=.52fa4627-5c6c-4e7e-a5b1-524e64d38a24@github.com>
 <mvqdpLUoz04ti59FH9JT8ZyKSFei-0CIjEMWkJNm3NY=.e3144ab0-1fe5-49f9-a125-bb3eac04d057@github.com>
Message-ID: <lWUvgOiCn6kMayaaXrtWDENNdBC_N5L01n0vIZoA__I=.0458150e-653d-40e1-91d0-4fe4e0a3cb9d@github.com>

On Sun, 10 Mar 2024 12:18:02 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Yes, you'll need to run all tests to make sure that there aren't any others, e.g. test/hotspot/jtreg/compiler/stable/TestUnstableStable.java.

I've updated `TestUnstableStable` to use `putReference` and also fixed a stray code comment reference to `Unsafe.compareAndSetObject` in `BufferedInputStream`.

@jaikiran Expect `TestUnstableStable` above to fail your CI run.

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

PR Comment: https://git.openjdk.org/jdk/pull/18176#issuecomment-1987238716

From dl at openjdk.org  Sun Mar 10 14:21:54 2024
From: dl at openjdk.org (Doug Lea)
Date: Sun, 10 Mar 2024 14:21:54 GMT
Subject: RFR: 8327729: Remove deprecated xxxObject methods from
 jdk.internal.misc.Unsafe [v3]
In-Reply-To: <4Z6CqKTSgNaTYilIvNjnGudJOs8qebTs4OhP5q7xShE=.e71ecd8c-5563-4daf-bf9c-56850d69d7ec@github.com>
References: <_R4_060_hbsKkeKvbuME6SLIfltbo5lmrQb0dHTpY1Q=.06c07eaa-5135-4dad-b4e1-65ef7a0000bc@github.com>
 <4Z6CqKTSgNaTYilIvNjnGudJOs8qebTs4OhP5q7xShE=.e71ecd8c-5563-4daf-bf9c-56850d69d7ec@github.com>
Message-ID: <q3LJbhfrH78puUKIeJVvOVRlXGaA8pQ3o5arGgMs8SM=.33d6482c-0184-42eb-a272-7bcdeed89380@github.com>

On Sun, 10 Mar 2024 13:47:06 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

>> Please review this PR which removes the 19 deprecated `xxObject*` alias methods from `jdk.internal.misc.Unsafe`.
>> 
>> These methods were added in JDK-8213043 (JDK 12), presumably to allow `jsr166.jar` to be used across JDK versions. This was a follow-up fix after JDK-8207146 had renamed these methods to `xxReference*'.
>> 
>> Since OpenJDK is now the single source of truth for `java.util.concurrent`, time has come to remove these deprecated alias methods.
>> 
>> This change was initially discussed here: https://mail.openjdk.org/pipermail/core-libs-dev/2024-March/119993.html
>> 
>> Testing: This is a pure deletion of deprecated methods, so the PR includes no test changes and the `noreg-cleanup` label is added in the JBS. I have verified that all `test/jdk/java/util/concurrent/*` tests pass.
>> 
>> Tagging @DougLea and @Martin-Buchholz to verify that this removal is timely.
>
> Eirik Bj?rsn?s has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Replace calls to Unsafe.putObject with Unsafe.putReference
>  - Update a code comment referencing Unsafe.compareAndSetObject to reference Unsafe.compareAndSetReference instead

OK with me.

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

PR Comment: https://git.openjdk.org/jdk/pull/18176#issuecomment-1987248843

From jpai at openjdk.org  Sun Mar 10 14:40:55 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sun, 10 Mar 2024 14:40:55 GMT
Subject: RFR: 8327729: Remove deprecated xxxObject methods from
 jdk.internal.misc.Unsafe [v2]
In-Reply-To: <KMVfpKIdNyS7-lp0oKh9BZ3XpUR2me_IJAxYaQXuhNA=.8199ca0c-7680-40d8-a430-21c79ef73f06@github.com>
References: <_R4_060_hbsKkeKvbuME6SLIfltbo5lmrQb0dHTpY1Q=.06c07eaa-5135-4dad-b4e1-65ef7a0000bc@github.com>
 <Rmd6v71CRqIWWfLsOnONk1qlv9beucybuXC-b-4C3Ps=.17c4e509-6f78-468a-8f35-d007830b37f6@github.com>
 <KMVfpKIdNyS7-lp0oKh9BZ3XpUR2me_IJAxYaQXuhNA=.8199ca0c-7680-40d8-a430-21c79ef73f06@github.com>
Message-ID: <286GDeeFd02bderE-7wTOh0uKX_VDz7b3uu0Hc-Wqv0=.770a55b9-8d0b-4f59-8c3c-e2e28def620b@github.com>

On Sun, 10 Mar 2024 10:17:23 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Eirik Bj?rsn?s has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Use getAndSetReference instead of getAndSetObject in test/hotspot/jtreg/gc/shenandoah/compiler/TestUnsafeLoadStoreMergedHeapStableTests.java
>
> Hello Eirik, I've triggered internal CI testing of the current state of this PR to run tier1, tier2 and tier3.

> @jaikiran Expect TestUnstableStable above to fail your CI run.

Right, that's the only test that failed (with a compilation error) on all platforms.

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

PR Comment: https://git.openjdk.org/jdk/pull/18176#issuecomment-1987254844

From dholmes at openjdk.org  Mon Mar 11 02:39:55 2024
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 11 Mar 2024 02:39:55 GMT
Subject: RFR: 8327460: Compile tests with the same visibility rules as
 product code [v2]
In-Reply-To: <pnjREovJalRYYzpMToibwGdUxZbOZ2FfO6hJowlG2J0=.e0947aa0-2af9-4785-93bb-18f1cf6bfef3@github.com>
References: <W2Xv4ln5Hn3tPW8C10dkuyynyqbLFvB8uxds0huGMms=.16a88981-b23c-4ceb-88fb-bff303de2076@github.com>
 <pnjREovJalRYYzpMToibwGdUxZbOZ2FfO6hJowlG2J0=.e0947aa0-2af9-4785-93bb-18f1cf6bfef3@github.com>
Message-ID: <qf1hQUA-XivudvebTcZWk3E1xkR5opV3pQy-qnNvbqo=.254083ec-ab5e-42d8-8cf2-9a5690cda466@github.com>

On Wed, 6 Mar 2024 13:43:00 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Currently, our symbol visibility handling for tests are sloppy; we only handle it properly on Windows. We need to bring it up to the same levels as product code. This is a prerequisite for [JDK-8327045](https://bugs.openjdk.org/browse/JDK-8327045), which in turn is a building block for Hermetic Java.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update line number for dereference_null  in TestDwarf

Looks like a nice cleanup - great to see all the duplicated EXPORT code gone!

test/hotspot/jtreg/runtime/ErrorHandling/libTestDwarfHelper.h line 24:

> 22:  */
> 23: 
> 24: #include <stdio.h>

Seems unneeded.

test/hotspot/jtreg/runtime/ErrorHandling/libTestDwarfHelper.h line 27:

> 25: 
> 26: #include "export.h"
> 27: #include "jni.h"

Seems unneeded.

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18135#pullrequestreview-1926822024
PR Review Comment: https://git.openjdk.org/jdk/pull/18135#discussion_r1519075894
PR Review Comment: https://git.openjdk.org/jdk/pull/18135#discussion_r1519076039

From alanb at openjdk.org  Mon Mar 11 07:00:56 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 11 Mar 2024 07:00:56 GMT
Subject: RFR: 8327460: Compile tests with the same visibility rules as
 product code
In-Reply-To: <D4VnoA_AetZT4vT_WasTrnfsavTpUH4oy8bCTL7HAWY=.5f2b4617-5854-4913-922e-aa84cd9c04a9@github.com>
References: <W2Xv4ln5Hn3tPW8C10dkuyynyqbLFvB8uxds0huGMms=.16a88981-b23c-4ceb-88fb-bff303de2076@github.com>
 <D4VnoA_AetZT4vT_WasTrnfsavTpUH4oy8bCTL7HAWY=.5f2b4617-5854-4913-922e-aa84cd9c04a9@github.com>
Message-ID: <_YFd8mgBis8mgRwfpafttLS2y1_-Aiy5aIdLr2eCXv8=.4890fb5d-cc8a-4cd8-a53d-3f18aa1dfbe6@github.com>

On Wed, 6 Mar 2024 12:14:10 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> * `test/jdk/java/lang/Thread/jni/AttachCurrentThread/libImplicitAttach.c` was missing an export. This had not been discovered before since that file was not compiled on Windows.

It's a Linux/macOS specific test so it wasn't needed.

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

PR Comment: https://git.openjdk.org/jdk/pull/18135#issuecomment-1987743188

From alanb at openjdk.org  Mon Mar 11 07:00:56 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 11 Mar 2024 07:00:56 GMT
Subject: RFR: 8327460: Compile tests with the same visibility rules as
 product code [v2]
In-Reply-To: <pnjREovJalRYYzpMToibwGdUxZbOZ2FfO6hJowlG2J0=.e0947aa0-2af9-4785-93bb-18f1cf6bfef3@github.com>
References: <W2Xv4ln5Hn3tPW8C10dkuyynyqbLFvB8uxds0huGMms=.16a88981-b23c-4ceb-88fb-bff303de2076@github.com>
 <pnjREovJalRYYzpMToibwGdUxZbOZ2FfO6hJowlG2J0=.e0947aa0-2af9-4785-93bb-18f1cf6bfef3@github.com>
Message-ID: <-9V3vdX_4NWhrgoEYdqy9W-PyT8HBwjKyMwF-IzM9Uo=.c5f3e91a-017e-42c1-abc3-ab90c94f3b75@github.com>

On Wed, 6 Mar 2024 13:43:00 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Currently, our symbol visibility handling for tests are sloppy; we only handle it properly on Windows. We need to bring it up to the same levels as product code. This is a prerequisite for [JDK-8327045](https://bugs.openjdk.org/browse/JDK-8327045), which in turn is a building block for Hermetic Java.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update line number for dereference_null  in TestDwarf

Good cleanup.

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

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18135#pullrequestreview-1927041103

From eirbjo at openjdk.org  Mon Mar 11 16:32:19 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Mon, 11 Mar 2024 16:32:19 GMT
Subject: RFR: 8327729: Remove deprecated xxxObject methods from
 jdk.internal.misc.Unsafe [v2]
In-Reply-To: <lWUvgOiCn6kMayaaXrtWDENNdBC_N5L01n0vIZoA__I=.0458150e-653d-40e1-91d0-4fe4e0a3cb9d@github.com>
References: <_R4_060_hbsKkeKvbuME6SLIfltbo5lmrQb0dHTpY1Q=.06c07eaa-5135-4dad-b4e1-65ef7a0000bc@github.com>
 <Rmd6v71CRqIWWfLsOnONk1qlv9beucybuXC-b-4C3Ps=.17c4e509-6f78-468a-8f35-d007830b37f6@github.com>
 <S9mqT3WkthYe2tbv3nrVvOoqrYDJMJtPn8YL9HNOejI=.52fa4627-5c6c-4e7e-a5b1-524e64d38a24@github.com>
 <mvqdpLUoz04ti59FH9JT8ZyKSFei-0CIjEMWkJNm3NY=.e3144ab0-1fe5-49f9-a125-bb3eac04d057@github.com>
 <lWUvgOiCn6kMayaaXrtWDENNdBC_N5L01n0vIZoA__I=.0458150e-653d-40e1-91d0-4fe4e0a3cb9d@github.com>
Message-ID: <2QMf5NUmk6LlLOdbIpIQdBJqWH7jYfqafG9zZPSZVTM=.45e54122-25b0-4df5-9ec8-2e6f7c71709b@github.com>

On Sun, 10 Mar 2024 13:47:43 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

> Yes, you'll need to run all tests to make sure that there aren't any others, e.g. test/hotspot/jtreg/compiler/stable/TestUnstableStable.java.

Alan,

With @jaikiran running Oracle CI tier1, tier2, tier3 and observing only the now-fixed `TestUnstableStable.java` test fail, would you consider re-approving the current state of this PR?

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

PR Comment: https://git.openjdk.org/jdk/pull/18176#issuecomment-1988559676

From mchung at openjdk.org  Mon Mar 11 19:37:20 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Mon, 11 Mar 2024 19:37:20 GMT
Subject: RFR: 8327729: Remove deprecated xxxObject methods from
 jdk.internal.misc.Unsafe [v3]
In-Reply-To: <4Z6CqKTSgNaTYilIvNjnGudJOs8qebTs4OhP5q7xShE=.e71ecd8c-5563-4daf-bf9c-56850d69d7ec@github.com>
References: <_R4_060_hbsKkeKvbuME6SLIfltbo5lmrQb0dHTpY1Q=.06c07eaa-5135-4dad-b4e1-65ef7a0000bc@github.com>
 <4Z6CqKTSgNaTYilIvNjnGudJOs8qebTs4OhP5q7xShE=.e71ecd8c-5563-4daf-bf9c-56850d69d7ec@github.com>
Message-ID: <A0OlDi72q7plzVUxp-irGrIeaN6kTWK7jFGBQJ9uJxM=.d82c8e5d-bb0f-453a-9ebd-0620c9436963@github.com>

On Sun, 10 Mar 2024 13:47:06 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

>> Please review this PR which removes the 19 deprecated `xxObject*` alias methods from `jdk.internal.misc.Unsafe`.
>> 
>> These methods were added in JDK-8213043 (JDK 12), presumably to allow `jsr166.jar` to be used across JDK versions. This was a follow-up fix after JDK-8207146 had renamed these methods to `xxReference*'.
>> 
>> Since OpenJDK is now the single source of truth for `java.util.concurrent`, time has come to remove these deprecated alias methods.
>> 
>> This change was initially discussed here: https://mail.openjdk.org/pipermail/core-libs-dev/2024-March/119993.html
>> 
>> Testing: This is a pure deletion of deprecated methods, so the PR includes no test changes and the `noreg-cleanup` label is added in the JBS. I have verified that all `test/jdk/java/util/concurrent/*` tests pass.
>> 
>> Tagging @DougLea and @Martin-Buchholz to verify that this removal is timely.
>
> Eirik Bj?rsn?s has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Replace calls to Unsafe.putObject with Unsafe.putReference
>  - Update a code comment referencing Unsafe.compareAndSetObject to reference Unsafe.compareAndSetReference instead

This should wait for @jaikiran approval confirming the test result is good.

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

Marked as reviewed by mchung (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18176#pullrequestreview-1928982510

From wkemper at openjdk.org  Mon Mar 11 22:12:34 2024
From: wkemper at openjdk.org (William Kemper)
Date: Mon, 11 Mar 2024 22:12:34 GMT
Subject: RFR: Merge openjdk/jdk21u-dev:master [v2]
In-Reply-To: <6SWEGqDCusPelZEKAhKJryDM5WGplxYy-pRlv7MPlwA=.3e6cce85-7abf-4422-a709-d6351920ea84@github.com>
References: <dYAtB-IsDr4tJuKhKLaq7TA3vKgBA4oIM_nxf_Lpp6s=.552be315-110b-44af-a468-c05a0b792f8a@github.com>
 <6SWEGqDCusPelZEKAhKJryDM5WGplxYy-pRlv7MPlwA=.3e6cce85-7abf-4422-a709-d6351920ea84@github.com>
Message-ID: <RXhkOEH7ynDdRAvzR5yRQqdPant6QbM9a95fjkjpGyo=.6a0d9236-491d-4878-8e2a-3a4a7c68d142@github.com>

On Fri, 16 Feb 2024 18:39:34 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> Merges tag jdk-21.0.3+3
>
> 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. The pull request contains 13 additional commits since the last revision:
> 
>  - Merge branch 'shenandoah-21u-master' into merge-jdk-21.0.3+3
>  - 8325194: GHA: Add macOS M1 testing
>    8325444: GHA: JDK-8325194 causes a regression
>    
>    Reviewed-by: shade
>    Backport-of: d1c82156ba6ede4b798ac15f935289cfcc99d1a0
>  - 8324753: [AIX] adjust os_posix after JDK-8318696
>    
>    Backport-of: 8950d68ddb36d35831fbb4b98969cd0537527070
>  - 8323671: DevKit build gcc libraries contain full paths to source location
>    
>    Backport-of: dd0694b9cbbfa2defdc3b09f86f20f686688cf7b
>  - 8323667: Library debug files contain non-reproducible full gcc include paths
>    
>    Backport-of: 57fad677819ae3142782f811a8fba94b38f5a74c
>  - 8318039: GHA: Bump macOS and Xcode versions
>    
>    Backport-of: 605c9767291ddf1c409c3e805ffb3182899d06c2
>  - 8325150: (tz) Update Timezone Data to 2024a
>    
>    Backport-of: 917838e0a564b1f2cbfb6cc214ccbfd1a237019f
>  - 8309109: AArch64: [TESTBUG] compiler/intrinsics/sha/cli/TestUseSHA3IntrinsicsOptionOnSupportedCPU.java fails on Neoverse N2 and V1
>    
>    Reviewed-by: aph
>    Backport-of: afdaa2a3305461538f3a36de2b0b540fe2da9b37
>  - 8324637: [aix] Implement support for reporting swap space in jdk.management
>    
>    Backport-of: 33324a59ccdb220250cb74e15ce13af0e99dcb07
>  - 8324598: use mem_unit when working with sysinfo memory and swap related information
>    
>    Backport-of: 7a798d3cebea0915f8a73af57333b3488c2091af
>  - ... and 3 more: https://git.openjdk.org/shenandoah-jdk21u/compare/5267c4d9...3e6fb7a6

Superseded by https://github.com/openjdk/shenandoah-jdk21u/pull/26

Superseded by https://github.com/openjdk/shenandoah-jdk21u/pull/26

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

PR Comment: https://git.openjdk.org/shenandoah-jdk21u/pull/21#issuecomment-1989534280
PR Comment: https://git.openjdk.org/shenandoah-jdk21u/pull/21#issuecomment-1989534405

From wkemper at openjdk.org  Mon Mar 11 22:12:34 2024
From: wkemper at openjdk.org (William Kemper)
Date: Mon, 11 Mar 2024 22:12:34 GMT
Subject: Withdrawn: Merge openjdk/jdk21u-dev:master
In-Reply-To: <dYAtB-IsDr4tJuKhKLaq7TA3vKgBA4oIM_nxf_Lpp6s=.552be315-110b-44af-a468-c05a0b792f8a@github.com>
References: <dYAtB-IsDr4tJuKhKLaq7TA3vKgBA4oIM_nxf_Lpp6s=.552be315-110b-44af-a468-c05a0b792f8a@github.com>
Message-ID: <1eAbdU6x0nVwAGmTnaTNVPxJfRtlJ7vJh8-7ojDOz7s=.bd9cfc45-499c-470f-b7d6-c6bbb11b8834@github.com>

On Thu, 15 Feb 2024 14:14:57 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Merges tag jdk-21.0.3+3

This pull request has been closed without being integrated.

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

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

From wkemper at openjdk.org  Mon Mar 11 22:13:59 2024
From: wkemper at openjdk.org (William Kemper)
Date: Mon, 11 Mar 2024 22:13:59 GMT
Subject: RFR: Merge openjdk/jdk21u-dev:master [v2]
In-Reply-To: <jFvzcTASabccYVlO7ye3pjBF44unuTmSCxlHv0CHuPM=.d7a4f6a5-cc30-4c3e-a388-178662311da1@github.com>
References: <jFvzcTASabccYVlO7ye3pjBF44unuTmSCxlHv0CHuPM=.d7a4f6a5-cc30-4c3e-a388-178662311da1@github.com>
Message-ID: <O3Oi253AbS2lTlQi28qXHNsQi-SlYlvtaPHvp8aPYXg=.efda5825-dc9e-43e1-9a8b-a005a44e9a81@github.com>

> Merges tag jdk-21.0.4+0

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

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

Changes:
  - all: https://git.openjdk.org/shenandoah-jdk21u/pull/23/files
  - new: https://git.openjdk.org/shenandoah-jdk21u/pull/23/files/36b5ac46..36b5ac46

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

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

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

From wkemper at openjdk.org  Mon Mar 11 22:13:59 2024
From: wkemper at openjdk.org (William Kemper)
Date: Mon, 11 Mar 2024 22:13:59 GMT
Subject: RFR: Merge openjdk/jdk21u-dev:master
In-Reply-To: <jFvzcTASabccYVlO7ye3pjBF44unuTmSCxlHv0CHuPM=.d7a4f6a5-cc30-4c3e-a388-178662311da1@github.com>
References: <jFvzcTASabccYVlO7ye3pjBF44unuTmSCxlHv0CHuPM=.d7a4f6a5-cc30-4c3e-a388-178662311da1@github.com>
Message-ID: <SRITx8JBHo1jrMpm_Re4TteLx2HnNhizXuyMcUV2Oec=.32af9039-614f-4069-b756-039f21040383@github.com>

On Thu, 29 Feb 2024 14:18:27 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Merges tag jdk-21.0.4+0

Superseded by https://github.com/openjdk/shenandoah-jdk21u/pull/26

Superseded by https://github.com/openjdk/shenandoah-jdk21u/pull/26

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

PR Comment: https://git.openjdk.org/shenandoah-jdk21u/pull/23#issuecomment-1989534921
PR Comment: https://git.openjdk.org/shenandoah-jdk21u/pull/23#issuecomment-1989535097

From wkemper at openjdk.org  Mon Mar 11 22:13:59 2024
From: wkemper at openjdk.org (William Kemper)
Date: Mon, 11 Mar 2024 22:13:59 GMT
Subject: Withdrawn: Merge openjdk/jdk21u-dev:master
In-Reply-To: <jFvzcTASabccYVlO7ye3pjBF44unuTmSCxlHv0CHuPM=.d7a4f6a5-cc30-4c3e-a388-178662311da1@github.com>
References: <jFvzcTASabccYVlO7ye3pjBF44unuTmSCxlHv0CHuPM=.d7a4f6a5-cc30-4c3e-a388-178662311da1@github.com>
Message-ID: <csBkbCNekuihZYnhchprSb4hmmqoRkTewACbDKm0I-A=.96b5fb80-2225-4ea0-a519-2522375240b9@github.com>

On Thu, 29 Feb 2024 14:18:27 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Merges tag jdk-21.0.4+0

This pull request has been closed without being integrated.

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

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

From wkemper at openjdk.org  Mon Mar 11 22:14:07 2024
From: wkemper at openjdk.org (William Kemper)
Date: Mon, 11 Mar 2024 22:14:07 GMT
Subject: RFR: Merge openjdk/jdk21u-dev:master [v2]
In-Reply-To: <8R15RlV-MVnyBG779EhSs6ZOYLCJmEBKdJ-z0IARgc0=.6b4d4d1c-16ce-4d2e-a651-8c6adda5bd6e@github.com>
References: <8R15RlV-MVnyBG779EhSs6ZOYLCJmEBKdJ-z0IARgc0=.6b4d4d1c-16ce-4d2e-a651-8c6adda5bd6e@github.com>
Message-ID: <polQUlenHkPlXAIwZ3tOGUFi4go_-lfiRidj8NpmXvA=.5e3f9c08-42dc-4800-86b5-75e834314bda@github.com>

> Merges tag jdk-21.0.3+6

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

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

Changes:
  - all: https://git.openjdk.org/shenandoah-jdk21u/pull/26/files
  - new: https://git.openjdk.org/shenandoah-jdk21u/pull/26/files/29bf21fd..29bf21fd

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

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

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

From wkemper at openjdk.org  Mon Mar 11 22:14:08 2024
From: wkemper at openjdk.org (William Kemper)
Date: Mon, 11 Mar 2024 22:14:08 GMT
Subject: RFR: Merge openjdk/jdk21u-dev:master
In-Reply-To: <8R15RlV-MVnyBG779EhSs6ZOYLCJmEBKdJ-z0IARgc0=.6b4d4d1c-16ce-4d2e-a651-8c6adda5bd6e@github.com>
References: <8R15RlV-MVnyBG779EhSs6ZOYLCJmEBKdJ-z0IARgc0=.6b4d4d1c-16ce-4d2e-a651-8c6adda5bd6e@github.com>
Message-ID: <brPNOBwkgB3It_-Qhx3mkJgt2mNmrOX6H_UF6mjBLR8=.30533529-4f93-4fba-a47f-e6ad8625e887@github.com>

On Thu, 7 Mar 2024 14:17:21 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Merges tag jdk-21.0.3+6

Build failure is on RISC platform.

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

PR Comment: https://git.openjdk.org/shenandoah-jdk21u/pull/26#issuecomment-1989533496

From wkemper at openjdk.org  Mon Mar 11 22:14:11 2024
From: wkemper at openjdk.org (William Kemper)
Date: Mon, 11 Mar 2024 22:14:11 GMT
Subject: Integrated: Merge openjdk/jdk21u-dev:master
In-Reply-To: <8R15RlV-MVnyBG779EhSs6ZOYLCJmEBKdJ-z0IARgc0=.6b4d4d1c-16ce-4d2e-a651-8c6adda5bd6e@github.com>
References: <8R15RlV-MVnyBG779EhSs6ZOYLCJmEBKdJ-z0IARgc0=.6b4d4d1c-16ce-4d2e-a651-8c6adda5bd6e@github.com>
Message-ID: <F2aYkQUmIZa9pv66dN9G84TKFB12HzgU4W_HCJcdnDY=.2f5bb7ac-5e99-4bca-90d6-c088b2cd317b@github.com>

On Thu, 7 Mar 2024 14:17:21 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Merges tag jdk-21.0.3+6

This pull request has now been integrated.

Changeset: 7449aab4
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.org/shenandoah-jdk21u/commit/7449aab4abac5e935c6c2fb90749e073c1f35d2b
Stats:     3260 lines in 177 files changed: 2507 ins; 194 del; 559 mod

Merge

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

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

From wkemper at openjdk.org  Mon Mar 11 22:15:03 2024
From: wkemper at openjdk.org (William Kemper)
Date: Mon, 11 Mar 2024 22:15:03 GMT
Subject: RFR: Merge openjdk/jdk21u-dev:master [v2]
In-Reply-To: <NqARfe_PmSUPtcdqdbE17yYQ_ex8sa-ws-QhLZi6cNc=.c9146322-976c-4f6f-85b9-fc0fcfca611f@github.com>
References: <NqARfe_PmSUPtcdqdbE17yYQ_ex8sa-ws-QhLZi6cNc=.c9146322-976c-4f6f-85b9-fc0fcfca611f@github.com>
Message-ID: <tKPZvoYzE08RkOp0k3V5NGFVaJ3mx7wNXOJl63iSarg=.87e08161-376c-468c-a132-cd8cb8d0f430@github.com>

> Merges tag jdk-21.0.3+4

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

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

Changes:
  - all: https://git.openjdk.org/shenandoah-jdk21u/pull/22/files
  - new: https://git.openjdk.org/shenandoah-jdk21u/pull/22/files/4fcc5c74..4fcc5c74

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

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

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

From wkemper at openjdk.org  Mon Mar 11 22:15:03 2024
From: wkemper at openjdk.org (William Kemper)
Date: Mon, 11 Mar 2024 22:15:03 GMT
Subject: RFR: Merge openjdk/jdk21u-dev:master
In-Reply-To: <NqARfe_PmSUPtcdqdbE17yYQ_ex8sa-ws-QhLZi6cNc=.c9146322-976c-4f6f-85b9-fc0fcfca611f@github.com>
References: <NqARfe_PmSUPtcdqdbE17yYQ_ex8sa-ws-QhLZi6cNc=.c9146322-976c-4f6f-85b9-fc0fcfca611f@github.com>
Message-ID: <vfQsVONtwWyE7FU3GLy3UBvMN02WmNxlNqsFGR97I0E=.752901a4-b1e0-461b-a912-dcf0d655b894@github.com>

On Thu, 22 Feb 2024 14:16:55 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Merges tag jdk-21.0.3+4

Superseded by https://github.com/openjdk/shenandoah-jdk21u/pull/26

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

PR Comment: https://git.openjdk.org/shenandoah-jdk21u/pull/22#issuecomment-1989534612

From wkemper at openjdk.org  Mon Mar 11 22:15:03 2024
From: wkemper at openjdk.org (William Kemper)
Date: Mon, 11 Mar 2024 22:15:03 GMT
Subject: Withdrawn: Merge openjdk/jdk21u-dev:master
In-Reply-To: <NqARfe_PmSUPtcdqdbE17yYQ_ex8sa-ws-QhLZi6cNc=.c9146322-976c-4f6f-85b9-fc0fcfca611f@github.com>
References: <NqARfe_PmSUPtcdqdbE17yYQ_ex8sa-ws-QhLZi6cNc=.c9146322-976c-4f6f-85b9-fc0fcfca611f@github.com>
Message-ID: <XNjcEpHlDWYS3JV_ntQiPRwkNxaZhpQgI1ANwHncEY0=.e1c8483c-8e71-4744-a576-5f78dbf232ca@github.com>

On Thu, 22 Feb 2024 14:16:55 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Merges tag jdk-21.0.3+4

This pull request has been closed without being integrated.

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

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

From jpai at openjdk.org  Tue Mar 12 06:42:13 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 12 Mar 2024 06:42:13 GMT
Subject: RFR: 8327729: Remove deprecated xxxObject methods from
 jdk.internal.misc.Unsafe [v3]
In-Reply-To: <4Z6CqKTSgNaTYilIvNjnGudJOs8qebTs4OhP5q7xShE=.e71ecd8c-5563-4daf-bf9c-56850d69d7ec@github.com>
References: <_R4_060_hbsKkeKvbuME6SLIfltbo5lmrQb0dHTpY1Q=.06c07eaa-5135-4dad-b4e1-65ef7a0000bc@github.com>
 <4Z6CqKTSgNaTYilIvNjnGudJOs8qebTs4OhP5q7xShE=.e71ecd8c-5563-4daf-bf9c-56850d69d7ec@github.com>
Message-ID: <Jt4vHKkIB89Kru9ZYKa6VP-7GwC8LZCGlNBzSnt4gGU=.eb731d76-9c25-4c51-8903-437e16777aae@github.com>

On Sun, 10 Mar 2024 13:47:06 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

>> Please review this PR which removes the 19 deprecated `xxObject*` alias methods from `jdk.internal.misc.Unsafe`.
>> 
>> These methods were added in JDK-8213043 (JDK 12), presumably to allow `jsr166.jar` to be used across JDK versions. This was a follow-up fix after JDK-8207146 had renamed these methods to `xxReference*'.
>> 
>> Since OpenJDK is now the single source of truth for `java.util.concurrent`, time has come to remove these deprecated alias methods.
>> 
>> This change was initially discussed here: https://mail.openjdk.org/pipermail/core-libs-dev/2024-March/119993.html
>> 
>> Testing: This is a pure deletion of deprecated methods, so the PR includes no test changes and the `noreg-cleanup` label is added in the JBS. I have verified that all `test/jdk/java/util/concurrent/*` tests pass.
>> 
>> Tagging @DougLea and @Martin-Buchholz to verify that this removal is timely.
>
> Eirik Bj?rsn?s has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Replace calls to Unsafe.putObject with Unsafe.putReference
>  - Update a code comment referencing Unsafe.compareAndSetObject to reference Unsafe.compareAndSetReference instead

Hello Eirik, Mandy, tier1, tier2, tier3 testing of the latest approved state of this PR passed without failures.

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

PR Comment: https://git.openjdk.org/jdk/pull/18176#issuecomment-1990867492

From ihse at openjdk.org  Tue Mar 12 13:54:16 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 12 Mar 2024 13:54:16 GMT
Subject: RFR: 8327460: Compile tests with the same visibility rules as
 product code [v2]
In-Reply-To: <YvnZO9thUwxN_O0wk1moNpQvP8PLakWzD31_zlBQ5l0=.eee10e2d-5d7b-40ab-b5d9-c440d83671e6@github.com>
References: <W2Xv4ln5Hn3tPW8C10dkuyynyqbLFvB8uxds0huGMms=.16a88981-b23c-4ceb-88fb-bff303de2076@github.com>
 <pnjREovJalRYYzpMToibwGdUxZbOZ2FfO6hJowlG2J0=.e0947aa0-2af9-4785-93bb-18f1cf6bfef3@github.com>
 <YvnZO9thUwxN_O0wk1moNpQvP8PLakWzD31_zlBQ5l0=.eee10e2d-5d7b-40ab-b5d9-c440d83671e6@github.com>
Message-ID: <qMUM0kdr3YlYGvvMkYv0G7HfdNrbrdu3HIHRbawKPus=.5051dd98-5622-4c43-9d1d-e016c3cf11c8@github.com>

On Fri, 8 Mar 2024 18:12:40 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update line number for dereference_null  in TestDwarf
>
> test/jdk/java/foreign/CallGeneratorHelper.java line 216:
> 
>> 214:         if (header) {
>> 215:             System.out.println(
>> 216:                 "#include \"export.h\"\n"
> 
> We don't generate these header files any more, so the changes to this file are not really needed.

I still wouldn't like to keep the bad hard-coded defines. Are you okay with me pushing these changes, and then you can remove the parts of the test that are not actually used anymore? If the code is not used it should not matter much to you either way.

(I mean I could back out these changes, but then we'd have the bad code in place while waiting for you to remove it, putting pressure on you to actually remove it.)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18135#discussion_r1521503942

From ihse at openjdk.org  Tue Mar 12 13:59:15 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 12 Mar 2024 13:59:15 GMT
Subject: RFR: 8327460: Compile tests with the same visibility rules as
 product code
In-Reply-To: <_YFd8mgBis8mgRwfpafttLS2y1_-Aiy5aIdLr2eCXv8=.4890fb5d-cc8a-4cd8-a53d-3f18aa1dfbe6@github.com>
References: <W2Xv4ln5Hn3tPW8C10dkuyynyqbLFvB8uxds0huGMms=.16a88981-b23c-4ceb-88fb-bff303de2076@github.com>
 <D4VnoA_AetZT4vT_WasTrnfsavTpUH4oy8bCTL7HAWY=.5f2b4617-5854-4913-922e-aa84cd9c04a9@github.com>
 <_YFd8mgBis8mgRwfpafttLS2y1_-Aiy5aIdLr2eCXv8=.4890fb5d-cc8a-4cd8-a53d-3f18aa1dfbe6@github.com>
Message-ID: <h_Yd8OW46LtAotIz6WNFAV1rg5e2iTulRAz9ze3PDr4=.aa91d29d-5d86-43f6-86a2-d11407bfa725@github.com>

On Mon, 11 Mar 2024 06:57:42 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> > test/jdk/java/lang/Thread/jni/AttachCurrentThread/libImplicitAttach.c was missing an export. This had not been discovered before since that file was not compiled on Windows.

> It's a Linux/macOS specific test so it wasn't needed.

Yeah. I understand. I just wanted to give an explanation for why this particular test needed changes that were not present elsewhere (since other exported methods all were tested on Windows).

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

PR Comment: https://git.openjdk.org/jdk/pull/18135#issuecomment-1991712352

From ihse at openjdk.org  Tue Mar 12 13:59:15 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 12 Mar 2024 13:59:15 GMT
Subject: RFR: 8327460: Compile tests with the same visibility rules as
 product code [v2]
In-Reply-To: <-9V3vdX_4NWhrgoEYdqy9W-PyT8HBwjKyMwF-IzM9Uo=.c5f3e91a-017e-42c1-abc3-ab90c94f3b75@github.com>
References: <W2Xv4ln5Hn3tPW8C10dkuyynyqbLFvB8uxds0huGMms=.16a88981-b23c-4ceb-88fb-bff303de2076@github.com>
 <pnjREovJalRYYzpMToibwGdUxZbOZ2FfO6hJowlG2J0=.e0947aa0-2af9-4785-93bb-18f1cf6bfef3@github.com>
 <-9V3vdX_4NWhrgoEYdqy9W-PyT8HBwjKyMwF-IzM9Uo=.c5f3e91a-017e-42c1-abc3-ab90c94f3b75@github.com>
Message-ID: <BV0oYa1m3BBtTzVWyMXkoFfeatyKzKf3yysaIZRsXzU=.710e8be3-2b21-4c4d-b3e5-ac9c1ca9e956@github.com>

On Mon, 11 Mar 2024 06:57:58 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Good cleanup.

Thanks!

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

PR Comment: https://git.openjdk.org/jdk/pull/18135#issuecomment-1991712859

From ihse at openjdk.org  Tue Mar 12 13:59:16 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 12 Mar 2024 13:59:16 GMT
Subject: RFR: 8327460: Compile tests with the same visibility rules as
 product code [v2]
In-Reply-To: <qf1hQUA-XivudvebTcZWk3E1xkR5opV3pQy-qnNvbqo=.254083ec-ab5e-42d8-8cf2-9a5690cda466@github.com>
References: <W2Xv4ln5Hn3tPW8C10dkuyynyqbLFvB8uxds0huGMms=.16a88981-b23c-4ceb-88fb-bff303de2076@github.com>
 <pnjREovJalRYYzpMToibwGdUxZbOZ2FfO6hJowlG2J0=.e0947aa0-2af9-4785-93bb-18f1cf6bfef3@github.com>
 <qf1hQUA-XivudvebTcZWk3E1xkR5opV3pQy-qnNvbqo=.254083ec-ab5e-42d8-8cf2-9a5690cda466@github.com>
Message-ID: <NPNGO0vJDEQgfQ5kydJCOKSwSIrbHausWtqj1fIUy18=.a8659776-e94d-4231-927c-1abf0677b077@github.com>

On Mon, 11 Mar 2024 02:31:02 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update line number for dereference_null  in TestDwarf
>
> test/hotspot/jtreg/runtime/ErrorHandling/libTestDwarfHelper.h line 24:
> 
>> 22:  */
>> 23: 
>> 24: #include <stdio.h>
> 
> Seems unneeded.

So what I did here was change:

#include "jni.h"
#include <stdio.h>


into 

#include <stdio.h>

#include "export.h"
#include "jni.h"


The reordering was strictly not needed, but putting user includes in front of system ones looked like bad coding to me, and put me in a difficult spot in where to add the new `#include "export.h"` -- next to the current user include even if I thought that was wrong, or have the system includes "sandwitched" between two user includes.

Or do you mean that it seems unneeded to include `jni.h` at all? Yes, I agree, but it was there before, and I don't want to make any other changes to the tests. This change is scary enough as it is :-). If you want, I can file a follow-up to remove this include instead.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18135#discussion_r1521510510

From jvernee at openjdk.org  Tue Mar 12 15:49:13 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Tue, 12 Mar 2024 15:49:13 GMT
Subject: RFR: 8327460: Compile tests with the same visibility rules as
 product code [v2]
In-Reply-To: <qMUM0kdr3YlYGvvMkYv0G7HfdNrbrdu3HIHRbawKPus=.5051dd98-5622-4c43-9d1d-e016c3cf11c8@github.com>
References: <W2Xv4ln5Hn3tPW8C10dkuyynyqbLFvB8uxds0huGMms=.16a88981-b23c-4ceb-88fb-bff303de2076@github.com>
 <pnjREovJalRYYzpMToibwGdUxZbOZ2FfO6hJowlG2J0=.e0947aa0-2af9-4785-93bb-18f1cf6bfef3@github.com>
 <YvnZO9thUwxN_O0wk1moNpQvP8PLakWzD31_zlBQ5l0=.eee10e2d-5d7b-40ab-b5d9-c440d83671e6@github.com>
 <qMUM0kdr3YlYGvvMkYv0G7HfdNrbrdu3HIHRbawKPus=.5051dd98-5622-4c43-9d1d-e016c3cf11c8@github.com>
Message-ID: <aDKgOefES3-P0FW9khDHtVynX6PAsjEiTVwVOViO4RM=.e8decd7f-f77f-4c53-960a-af7fc6c61820@github.com>

On Tue, 12 Mar 2024 13:51:28 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> test/jdk/java/foreign/CallGeneratorHelper.java line 216:
>> 
>>> 214:         if (header) {
>>> 215:             System.out.println(
>>> 216:                 "#include \"export.h\"\n"
>> 
>> We don't generate these header files any more, so the changes to this file are not really needed.
>
> I still wouldn't like to keep the bad hard-coded defines. Are you okay with me pushing these changes, and then you can remove the parts of the test that are not actually used anymore? If the code is not used it should not matter much to you either way.
> 
> (I mean I could back out these changes, but then we'd have the bad code in place while waiting for you to remove it, putting pressure on you to actually remove it.)

Yes, that's fine. Sorry, I meant to file a JBS issue and come back with another comment last time, but I got distracted. Filed: https://bugs.openjdk.org/browse/JDK-8327994 now

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18135#discussion_r1521715617

From eirbjo at openjdk.org  Tue Mar 12 17:40:18 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Tue, 12 Mar 2024 17:40:18 GMT
Subject: RFR: 8327729: Remove deprecated xxxObject methods from
 jdk.internal.misc.Unsafe [v3]
In-Reply-To: <4Z6CqKTSgNaTYilIvNjnGudJOs8qebTs4OhP5q7xShE=.e71ecd8c-5563-4daf-bf9c-56850d69d7ec@github.com>
References: <_R4_060_hbsKkeKvbuME6SLIfltbo5lmrQb0dHTpY1Q=.06c07eaa-5135-4dad-b4e1-65ef7a0000bc@github.com>
 <4Z6CqKTSgNaTYilIvNjnGudJOs8qebTs4OhP5q7xShE=.e71ecd8c-5563-4daf-bf9c-56850d69d7ec@github.com>
Message-ID: <mM9LLxHzydMXaeJ3ulyrDg8w_klXGqOAJ8Q3eFk6Xrc=.cfac5403-2f36-4082-b0e2-d4bc49f60c37@github.com>

On Sun, 10 Mar 2024 13:47:06 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

>> Please review this PR which removes the 19 deprecated `xxObject*` alias methods from `jdk.internal.misc.Unsafe`.
>> 
>> These methods were added in JDK-8213043 (JDK 12), presumably to allow `jsr166.jar` to be used across JDK versions. This was a follow-up fix after JDK-8207146 had renamed these methods to `xxReference*'.
>> 
>> Since OpenJDK is now the single source of truth for `java.util.concurrent`, time has come to remove these deprecated alias methods.
>> 
>> This change was initially discussed here: https://mail.openjdk.org/pipermail/core-libs-dev/2024-March/119993.html
>> 
>> Testing: This is a pure deletion of deprecated methods, so the PR includes no test changes and the `noreg-cleanup` label is added in the JBS. I have verified that all `test/jdk/java/util/concurrent/*` tests pass.
>> 
>> Tagging @DougLea and @Martin-Buchholz to verify that this removal is timely.
>
> Eirik Bj?rsn?s has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Replace calls to Unsafe.putObject with Unsafe.putReference
>  - Update a code comment referencing Unsafe.compareAndSetObject to reference Unsafe.compareAndSetReference instead

Thanks for helping out with this cleanup effort, Jaikiran, Alan, Mandy, Doug and Martin!

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

PR Comment: https://git.openjdk.org/jdk/pull/18176#issuecomment-1992202476

From eirbjo at openjdk.org  Tue Mar 12 17:40:19 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Tue, 12 Mar 2024 17:40:19 GMT
Subject: Integrated: 8327729: Remove deprecated xxxObject methods from
 jdk.internal.misc.Unsafe
In-Reply-To: <_R4_060_hbsKkeKvbuME6SLIfltbo5lmrQb0dHTpY1Q=.06c07eaa-5135-4dad-b4e1-65ef7a0000bc@github.com>
References: <_R4_060_hbsKkeKvbuME6SLIfltbo5lmrQb0dHTpY1Q=.06c07eaa-5135-4dad-b4e1-65ef7a0000bc@github.com>
Message-ID: <pHXoWOb6lVroq94zjgVv7YoNkPKdjGtjRHTYhVVE6Zk=.11fc8351-62c9-43fa-92bd-1e1ee4f5961b@github.com>

On Sun, 10 Mar 2024 05:50:33 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

> Please review this PR which removes the 19 deprecated `xxObject*` alias methods from `jdk.internal.misc.Unsafe`.
> 
> These methods were added in JDK-8213043 (JDK 12), presumably to allow `jsr166.jar` to be used across JDK versions. This was a follow-up fix after JDK-8207146 had renamed these methods to `xxReference*'.
> 
> Since OpenJDK is now the single source of truth for `java.util.concurrent`, time has come to remove these deprecated alias methods.
> 
> This change was initially discussed here: https://mail.openjdk.org/pipermail/core-libs-dev/2024-March/119993.html
> 
> Testing: This is a pure deletion of deprecated methods, so the PR includes no test changes and the `noreg-cleanup` label is added in the JBS. I have verified that all `test/jdk/java/util/concurrent/*` tests pass.
> 
> Tagging @DougLea and @Martin-Buchholz to verify that this removal is timely.

This pull request has now been integrated.

Changeset: 5b414662
Author:    Eirik Bj?rsn?s <eirbjo at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/5b4146627580834bcd3ad0962d07d0d374fe3cce
Stats:     94 lines in 4 files changed: 0 ins; 87 del; 7 mod

8327729: Remove deprecated xxxObject methods from jdk.internal.misc.Unsafe

Reviewed-by: martin, alanb, mchung

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

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

From dholmes at openjdk.org  Wed Mar 13 07:28:17 2024
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 13 Mar 2024 07:28:17 GMT
Subject: RFR: 8327460: Compile tests with the same visibility rules as
 product code [v2]
In-Reply-To: <NPNGO0vJDEQgfQ5kydJCOKSwSIrbHausWtqj1fIUy18=.a8659776-e94d-4231-927c-1abf0677b077@github.com>
References: <W2Xv4ln5Hn3tPW8C10dkuyynyqbLFvB8uxds0huGMms=.16a88981-b23c-4ceb-88fb-bff303de2076@github.com>
 <pnjREovJalRYYzpMToibwGdUxZbOZ2FfO6hJowlG2J0=.e0947aa0-2af9-4785-93bb-18f1cf6bfef3@github.com>
 <qf1hQUA-XivudvebTcZWk3E1xkR5opV3pQy-qnNvbqo=.254083ec-ab5e-42d8-8cf2-9a5690cda466@github.com>
 <NPNGO0vJDEQgfQ5kydJCOKSwSIrbHausWtqj1fIUy18=.a8659776-e94d-4231-927c-1abf0677b077@github.com>
Message-ID: <RHQle2EpproXwXQQ3kzKVeNiiV07Q-Bm-eoNyn-8j_s=.2f054d4f-de39-42f1-8fa1-bbcbaaf749a4@github.com>

On Tue, 12 Mar 2024 13:55:11 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> test/hotspot/jtreg/runtime/ErrorHandling/libTestDwarfHelper.h line 24:
>> 
>>> 22:  */
>>> 23: 
>>> 24: #include <stdio.h>
>> 
>> Seems unneeded.
>
> So what I did here was change:
> 
> #include "jni.h"
> #include <stdio.h>
> 
> 
> into 
> 
> #include <stdio.h>
> 
> #include "export.h"
> #include "jni.h"
> 
> 
> The reordering was strictly not needed, but putting user includes in front of system ones looked like bad coding to me, and put me in a difficult spot in where to add the new `#include "export.h"` -- next to the current user include even if I thought that was wrong, or have the system includes "sandwitched" between two user includes.
> 
> Or do you mean that it seems unneeded to include `jni.h` at all? Yes, I agree, but it was there before, and I don't want to make any other changes to the tests. This change is scary enough as it is :-). If you want, I can file a follow-up to remove this include instead.

Yes I meant the include is actually unnecessary, but fine to not make that change here.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18135#discussion_r1522659393

From ihse at openjdk.org  Wed Mar 13 08:12:19 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 13 Mar 2024 08:12:19 GMT
Subject: Integrated: 8327460: Compile tests with the same visibility rules as
 product code
In-Reply-To: <W2Xv4ln5Hn3tPW8C10dkuyynyqbLFvB8uxds0huGMms=.16a88981-b23c-4ceb-88fb-bff303de2076@github.com>
References: <W2Xv4ln5Hn3tPW8C10dkuyynyqbLFvB8uxds0huGMms=.16a88981-b23c-4ceb-88fb-bff303de2076@github.com>
Message-ID: <LTCoRGSsPh0q-7waOa5cPfIaPaGjw0C29kVx8Xallo8=.d5acc553-cdcf-41f0-b666-b0642fee7d3d@github.com>

On Wed, 6 Mar 2024 11:33:30 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Currently, our symbol visibility handling for tests are sloppy; we only handle it properly on Windows. We need to bring it up to the same levels as product code. This is a prerequisite for [JDK-8327045](https://bugs.openjdk.org/browse/JDK-8327045), which in turn is a building block for Hermetic Java.

This pull request has now been integrated.

Changeset: cc9a8aba
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/cc9a8aba67f4e240c8de2d1ae15d1b80bfa446a0
Stats:     304 lines in 39 files changed: 69 ins; 159 del; 76 mod

8327460: Compile tests with the same visibility rules as product code

Reviewed-by: erikj, jvernee, dholmes, alanb

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

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

From kdnilsen at openjdk.org  Wed Mar 13 17:11:27 2024
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Wed, 13 Mar 2024 17:11:27 GMT
Subject: RFR: 8324649: Shenandoah: refactor implementation of free set
 [v14]
In-Reply-To: <PVrVW-I2bKkYzrdBafHAaWF8mw6WtANB3PoOZW5ekRw=.2ab54392-0f5b-4f6f-b5d7-7b7a9b6a0a97@github.com>
References: <VAkn0SrKYZWmnflpM8ZwVAXjUF1LjA0_FCBmRJJ4VSc=.c2f979bd-2957-434e-95ca-7b11b1573900@github.com>
 <DtAJtZcZPNv2FMbF9-FeJIT6T8Oio1TW9yYnw3cceF0=.ed94d2d3-39c2-4f8d-9e00-5dbd81683c93@github.com>
 <PVrVW-I2bKkYzrdBafHAaWF8mw6WtANB3PoOZW5ekRw=.2ab54392-0f5b-4f6f-b5d7-7b7a9b6a0a97@github.com>
Message-ID: <OC6vxq9Re-GtSSMaCz2QBY-Oey84J6V5LrD1qvUzxkw=.d290c0db-fd33-4f76-9288-85dff1c67d78@github.com>

On Fri, 1 Mar 2024 15:21:58 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Kelvin Nilsen has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 60 commits:
>> 
>>  - Remove instrumentation and cleanup magic numbers
>>    
>>    Two places, I had used 63 when I should have used
>>    _bits_per_array_element -1.
>>  - Address 32-bit compile issues
>>  - Fix 32-bit size formatting in log messages
>>  - Fix white space
>>  - Merge remote-tracking branch 'origin/master' into restructure-free-set
>>  - Merge branch 'openjdk:master' into master
>>  - Two bug fixes for better performance
>>    
>>    1. Collector reserve size is based on memory available within regions
>>       rather than the region size (oops).
>>    
>>    2. If an attempt to allocate within a region fails and the region has
>>       already provided the percentage presumed by ShenandoahEvacWaste,
>>       retire this region.  This is motivated by observations that
>>       otherwise, we end up with large numbers of regions that have only
>>       a small amount of memory within them (e.g. 4k) and every allocation
>>       request has to wade through all of these regions before it eventually
>>       finds a region that has a sufficiently large amount of available
>>       memory.  In the original Shenandoah free-set implementation, the
>>       behavior was to retire the first time an allocation within that
>>       regions fails, regardless of whether the region has already reached
>>       the ShenandoahEvacWaste threshold.
>>  - Fix off-by-one error in is_forward_consecutive_ones()
>>  - Fix whitespace
>>  - Bug fixes and performance improvements
>>    
>>    1. Correct off-b-one-error in count of trailingones
>>    2. Speed up search for contiguous regions (for humongous allocations) by
>>       sliding window instead of initiating new search each time
>>    3. Bias regular region allocations to favor regions that are already
>>       partially consumed
>>    4. Fix bug in move_regions_from_collector_to_mutator which caused some
>>       non-empty regions to be ignored.
>>  - ... and 50 more: https://git.openjdk.org/jdk/compare/be2b92bd...1aa5a3e6
>
> src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp line 50:
> 
>> 48:   size_t element_bits = _bitmap[array_idx];
>> 49:   size_t bit_number = start_idx % _bits_per_array_element;
>> 50:   size_t the_bit = ((size_t) 0x01) << bit_number;
> 
> Here and later, we have a special macro for this, `nth_bit`.

Thanks.  I've replaced all explicit bit manipulation with nth_bit where appropriate.

> src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp line 52:
> 
>> 50:   size_t the_bit = ((size_t) 0x01) << bit_number;
>> 51:   size_t omit_mask = the_bit - 1;
>> 52:   size_t mask = ((size_t) ((ssize_t) -1)) & omit_mask;
> 
> Same, we have `right_n_bits` to generate the masks like this.

Thanks.  I've replaced all explicit bit manipulation with right_n_bits() where appropriate.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17561#discussion_r1523634584
PR Review Comment: https://git.openjdk.org/jdk/pull/17561#discussion_r1523635073

From kdnilsen at openjdk.org  Wed Mar 13 18:16:40 2024
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Wed, 13 Mar 2024 18:16:40 GMT
Subject: RFR: 8324649: Shenandoah: refactor implementation of free set
 [v30]
In-Reply-To: <VAkn0SrKYZWmnflpM8ZwVAXjUF1LjA0_FCBmRJJ4VSc=.c2f979bd-2957-434e-95ca-7b11b1573900@github.com>
References: <VAkn0SrKYZWmnflpM8ZwVAXjUF1LjA0_FCBmRJJ4VSc=.c2f979bd-2957-434e-95ca-7b11b1573900@github.com>
Message-ID: <wxzGKchhycznOxmDbUPCsGeeqChsRD9X8y113nL6E7s=.4db4e9a9-8162-4da2-8bff-59d2d24b4fc0@github.com>

> Several objectives:
> 1. Reduce humongous allocation failures by segregating regular regions from humongous regions
> 2. Do not retire regions just because an allocation failed within the region if the memory remaining within the region is large enough to represent a LAB
> 3. Track range of empty regions in addition to range of available regions in order to expedite humongous allocations
> 4. Treat collector reserves as available for Mutator allocations after evacuation completes
> 5. Improve encapsulation so as to enable an OldCollector reserve for future integration of generational Shenandoah
> 
> We have compared performance of existing FreeSet implementation with the proposed PR over a broad set of performance workloads and see that the impact is mostly neutral.
> 
> Comparing 105235.0 metrics from control, 220638.0 from experiment.
> Compare: 0.589s
>                           Most impacted benchmarks |                              Most impacted metrics
> -------------------------------------------------------------------------------------------------------
>                                  Shenandoah/jython |                                          cwr_total
> 
> 
>                                 Only in experiment |                                    Only in control
> -------------------------------------------------------------------------------------------------------
>                  crypto.signverify/trigger_failure |                        crypto.rsa/cmr_thread_roots
>                 extremem-large-31g/adjust_pointers |       scimark.sparse.small/concurrent_thread_roots
>             extremem-large-31g/calculate_addresses |              xml.transform/concurrent_thread_roots
>       crypto.signverify/class_unloading_rendezvous |                    mpegaudio/concurrent_weak_roots
>                                   serial/cmr_total |                        crypto.rsa/ctr_thread_roots
> 
> Shenandoah
> -------------------------------------------------------------------------------------------------------
> +5.64% jython/cwr_total p=0.00037
>   Control:      1.928ms (+/-272.40us)        170
>   Test:         2.037ms (+/-322.73us)        344

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

 - Move comments that describe functions into header file
   
   Also, remove redundant comments from the .cpp and inline-hpp files.
 - Reduce strength of bit manipulation operations
   
   Replace /, %, and * with >>, &, <<.
 - Use existing macros for bit twiddling

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17561/files
  - new: https://git.openjdk.org/jdk/pull/17561/files/6d71c324..baaca573

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17561&range=29
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17561&range=28-29

  Stats: 191 lines in 3 files changed: 48 ins; 71 del; 72 mod
  Patch: https://git.openjdk.org/jdk/pull/17561.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17561/head:pull/17561

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

From kdnilsen at openjdk.org  Wed Mar 13 18:16:42 2024
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Wed, 13 Mar 2024 18:16:42 GMT
Subject: RFR: 8324649: Shenandoah: refactor implementation of free set
 [v14]
In-Reply-To: <PVrVW-I2bKkYzrdBafHAaWF8mw6WtANB3PoOZW5ekRw=.2ab54392-0f5b-4f6f-b5d7-7b7a9b6a0a97@github.com>
References: <VAkn0SrKYZWmnflpM8ZwVAXjUF1LjA0_FCBmRJJ4VSc=.c2f979bd-2957-434e-95ca-7b11b1573900@github.com>
 <DtAJtZcZPNv2FMbF9-FeJIT6T8Oio1TW9yYnw3cceF0=.ed94d2d3-39c2-4f8d-9e00-5dbd81683c93@github.com>
 <PVrVW-I2bKkYzrdBafHAaWF8mw6WtANB3PoOZW5ekRw=.2ab54392-0f5b-4f6f-b5d7-7b7a9b6a0a97@github.com>
Message-ID: <7XV2JsXbPCIsQq-zuJo-Y-Qq8qigUXrgawzgBM_-nFo=.0d31fc31-6903-47ae-9ce5-deb211e5da01@github.com>

On Fri, 1 Mar 2024 17:24:53 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Kelvin Nilsen has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 60 commits:
>> 
>>  - Remove instrumentation and cleanup magic numbers
>>    
>>    Two places, I had used 63 when I should have used
>>    _bits_per_array_element -1.
>>  - Address 32-bit compile issues
>>  - Fix 32-bit size formatting in log messages
>>  - Fix white space
>>  - Merge remote-tracking branch 'origin/master' into restructure-free-set
>>  - Merge branch 'openjdk:master' into master
>>  - Two bug fixes for better performance
>>    
>>    1. Collector reserve size is based on memory available within regions
>>       rather than the region size (oops).
>>    
>>    2. If an attempt to allocate within a region fails and the region has
>>       already provided the percentage presumed by ShenandoahEvacWaste,
>>       retire this region.  This is motivated by observations that
>>       otherwise, we end up with large numbers of regions that have only
>>       a small amount of memory within them (e.g. 4k) and every allocation
>>       request has to wade through all of these regions before it eventually
>>       finds a region that has a sufficiently large amount of available
>>       memory.  In the original Shenandoah free-set implementation, the
>>       behavior was to retire the first time an allocation within that
>>       regions fails, regardless of whether the region has already reached
>>       the ShenandoahEvacWaste threshold.
>>  - Fix off-by-one error in is_forward_consecutive_ones()
>>  - Fix whitespace
>>  - Bug fixes and performance improvements
>>    
>>    1. Correct off-b-one-error in count of trailingones
>>    2. Speed up search for contiguous regions (for humongous allocations) by
>>       sliding window instead of initiating new search each time
>>    3. Bias regular region allocations to favor regions that are already
>>       partially consumed
>>    4. Fix bug in move_regions_from_collector_to_mutator which caused some
>>       non-empty regions to be ignored.
>>  - ... and 50 more: https://git.openjdk.org/jdk/compare/be2b92bd...1aa5a3e6
>
> src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp line 67:
> 
>> 65: 
>> 66: // Count consecutive ones in reverse order, starting from last_idx.  Requires that there is at least one zero
>> 67: // between last_idx and index value zero, inclusive.
> 
> Here and later: This duplicates the documentation in header. No need to put it here, saves us from desyncs between duplicate comments.

Thanks.  I've removed redundant comments from the .cpp file and have moved other function descriptions from the .cpp file to the .hpp file.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17561#discussion_r1523715578

From kdnilsen at openjdk.org  Wed Mar 13 18:24:20 2024
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Wed, 13 Mar 2024 18:24:20 GMT
Subject: RFR: 8324649: Shenandoah: refactor implementation of free set [v4]
In-Reply-To: <gViARkv0jhXfIL4ekepO4LblHADqn1AvzTRdW3xvCw0=.8113e2a5-9c84-41c5-ad63-dc239931b1ea@github.com>
References: <VAkn0SrKYZWmnflpM8ZwVAXjUF1LjA0_FCBmRJJ4VSc=.c2f979bd-2957-434e-95ca-7b11b1573900@github.com>
 <Uw8Ao0F2vQhi35yNeJtfSsoZbSzgYhrW1-ExVDmJTCM=.65b8d60a-d490-4456-984b-40be92a83fb4@github.com>
 <gViARkv0jhXfIL4ekepO4LblHADqn1AvzTRdW3xvCw0=.8113e2a5-9c84-41c5-ad63-dc239931b1ea@github.com>
Message-ID: <dJzNN76IqhxFJ8or46baI63oUZht52l73dqJWgnEPKc=.18703057-453a-4416-a258-25e76ade59e2@github.com>

On Sun, 28 Jan 2024 23:42:47 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

>> Kelvin Nilsen has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Fix typo in comment
>>  - Remove unnecessary include
>
> src/hotspot/share/gc/shenandoah/shenandoahFreeSet.hpp line 168:
> 
>> 166:   HeapWord* allocate_contiguous(ShenandoahAllocRequest& req);
>> 167: 
>> 168:   void flip_to_gc(ShenandoahHeapRegion* r);
> 
> Document the contract(s) of this method.

Thanks.  I've added a comment to the .hpp file to describe this function's behavior.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17561#discussion_r1523722271

From kdnilsen at openjdk.org  Wed Mar 13 18:24:22 2024
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Wed, 13 Mar 2024 18:24:22 GMT
Subject: RFR: 8324649: Shenandoah: refactor implementation of free set
 [v30]
In-Reply-To: <PVrVW-I2bKkYzrdBafHAaWF8mw6WtANB3PoOZW5ekRw=.2ab54392-0f5b-4f6f-b5d7-7b7a9b6a0a97@github.com>
References: <VAkn0SrKYZWmnflpM8ZwVAXjUF1LjA0_FCBmRJJ4VSc=.c2f979bd-2957-434e-95ca-7b11b1573900@github.com>
 <DtAJtZcZPNv2FMbF9-FeJIT6T8Oio1TW9yYnw3cceF0=.ed94d2d3-39c2-4f8d-9e00-5dbd81683c93@github.com>
 <PVrVW-I2bKkYzrdBafHAaWF8mw6WtANB3PoOZW5ekRw=.2ab54392-0f5b-4f6f-b5d7-7b7a9b6a0a97@github.com>
Message-ID: <l4QAQ52qDc87mXbr3X3IeMis4upIeQTsBCYis8HVDS8=.143dc5f4-ac08-4f82-81ca-c590983b90fa@github.com>

On Fri, 1 Mar 2024 18:00:58 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Kelvin Nilsen has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - Move comments that describe functions into header file
>>    
>>    Also, remove redundant comments from the .cpp and inline-hpp files.
>>  - Reduce strength of bit manipulation operations
>>    
>>    Replace /, %, and * with >>, &, <<.
>>  - Use existing macros for bit twiddling
>
> src/hotspot/share/gc/shenandoah/shenandoahFullGC.cpp line 1089:
> 
>> 1087:     heap->heap_region_iterate(&post_compact);
>> 1088:     heap->set_used(post_compact.get_live());
>> 1089: 
> 
> Is this change necessary?

Sorry.  Reverted.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17561#discussion_r1523725007

From kdnilsen at openjdk.org  Wed Mar 13 18:56:36 2024
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Wed, 13 Mar 2024 18:56:36 GMT
Subject: RFR: 8324649: Shenandoah: refactor implementation of free set
 [v31]
In-Reply-To: <VAkn0SrKYZWmnflpM8ZwVAXjUF1LjA0_FCBmRJJ4VSc=.c2f979bd-2957-434e-95ca-7b11b1573900@github.com>
References: <VAkn0SrKYZWmnflpM8ZwVAXjUF1LjA0_FCBmRJJ4VSc=.c2f979bd-2957-434e-95ca-7b11b1573900@github.com>
Message-ID: <Bb-c4IJ3dRP0aHey3eS5zPHWHvc_pnhOIwDGtagFJf0=.47abfa07-c8b7-4719-854e-016ebe10e121@github.com>

> Several objectives:
> 1. Reduce humongous allocation failures by segregating regular regions from humongous regions
> 2. Do not retire regions just because an allocation failed within the region if the memory remaining within the region is large enough to represent a LAB
> 3. Track range of empty regions in addition to range of available regions in order to expedite humongous allocations
> 4. Treat collector reserves as available for Mutator allocations after evacuation completes
> 5. Improve encapsulation so as to enable an OldCollector reserve for future integration of generational Shenandoah
> 
> We have compared performance of existing FreeSet implementation with the proposed PR over a broad set of performance workloads and see that the impact is mostly neutral.
> 
> Comparing 105235.0 metrics from control, 220638.0 from experiment.
> Compare: 0.589s
>                           Most impacted benchmarks |                              Most impacted metrics
> -------------------------------------------------------------------------------------------------------
>                                  Shenandoah/jython |                                          cwr_total
> 
> 
>                                 Only in experiment |                                    Only in control
> -------------------------------------------------------------------------------------------------------
>                  crypto.signverify/trigger_failure |                        crypto.rsa/cmr_thread_roots
>                 extremem-large-31g/adjust_pointers |       scimark.sparse.small/concurrent_thread_roots
>             extremem-large-31g/calculate_addresses |              xml.transform/concurrent_thread_roots
>       crypto.signverify/class_unloading_rendezvous |                    mpegaudio/concurrent_weak_roots
>                                   serial/cmr_total |                        crypto.rsa/ctr_thread_roots
> 
> Shenandoah
> -------------------------------------------------------------------------------------------------------
> +5.64% jython/cwr_total p=0.00037
>   Control:      1.928ms (+/-272.40us)        170
>   Test:         2.037ms (+/-322.73us)        344

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

 - Restore call to notify_Mutator_alloc_words() following humongous alloc
   
   This was accidentally removed.  Caught during code review.
 - Revert another accidental deletion of a blank line
 - Revert accidental deletion of blank line
 - Add comment to describe flip_to_gc()

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17561/files
  - new: https://git.openjdk.org/jdk/pull/17561/files/baaca573..9cdb82e5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17561&range=30
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17561&range=29-30

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

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

From kdnilsen at openjdk.org  Wed Mar 13 18:56:39 2024
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Wed, 13 Mar 2024 18:56:39 GMT
Subject: RFR: 8324649: Shenandoah: refactor implementation of free set
 [v14]
In-Reply-To: <PVrVW-I2bKkYzrdBafHAaWF8mw6WtANB3PoOZW5ekRw=.2ab54392-0f5b-4f6f-b5d7-7b7a9b6a0a97@github.com>
References: <VAkn0SrKYZWmnflpM8ZwVAXjUF1LjA0_FCBmRJJ4VSc=.c2f979bd-2957-434e-95ca-7b11b1573900@github.com>
 <DtAJtZcZPNv2FMbF9-FeJIT6T8Oio1TW9yYnw3cceF0=.ed94d2d3-39c2-4f8d-9e00-5dbd81683c93@github.com>
 <PVrVW-I2bKkYzrdBafHAaWF8mw6WtANB3PoOZW5ekRw=.2ab54392-0f5b-4f6f-b5d7-7b7a9b6a0a97@github.com>
Message-ID: <PRpSWDmP6ruBTrdz2FaADffHPpafs4s2mpFoZMpt8v8=.111e061d-140c-481b-95b2-de77970374c0@github.com>

On Fri, 1 Mar 2024 17:51:58 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Kelvin Nilsen has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 60 commits:
>> 
>>  - Remove instrumentation and cleanup magic numbers
>>    
>>    Two places, I had used 63 when I should have used
>>    _bits_per_array_element -1.
>>  - Address 32-bit compile issues
>>  - Fix 32-bit size formatting in log messages
>>  - Fix white space
>>  - Merge remote-tracking branch 'origin/master' into restructure-free-set
>>  - Merge branch 'openjdk:master' into master
>>  - Two bug fixes for better performance
>>    
>>    1. Collector reserve size is based on memory available within regions
>>       rather than the region size (oops).
>>    
>>    2. If an attempt to allocate within a region fails and the region has
>>       already provided the percentage presumed by ShenandoahEvacWaste,
>>       retire this region.  This is motivated by observations that
>>       otherwise, we end up with large numbers of regions that have only
>>       a small amount of memory within them (e.g. 4k) and every allocation
>>       request has to wade through all of these regions before it eventually
>>       finds a region that has a sufficiently large amount of available
>>       memory.  In the original Shenandoah free-set implementation, the
>>       behavior was to retire the first time an allocation within that
>>       regions fails, regardless of whether the region has already reached
>>       the ShenandoahEvacWaste threshold.
>>  - Fix off-by-one error in is_forward_consecutive_ones()
>>  - Fix whitespace
>>  - Bug fixes and performance improvements
>>    
>>    1. Correct off-b-one-error in count of trailingones
>>    2. Speed up search for contiguous regions (for humongous allocations) by
>>       sliding window instead of initiating new search each time
>>    3. Bias regular region allocations to favor regions that are already
>>       partially consumed
>>    4. Fix bug in move_regions_from_collector_to_mutator which caused some
>>       non-empty regions to be ignored.
>>  - ... and 50 more: https://git.openjdk.org/jdk/compare/be2b92bd...1aa5a3e6
>
> src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp line 1152:
> 
>> 1150:   _partitions.retire_range_from_partition(Mutator, beg, end);
>> 1151: 
>> 1152:   size_t total_humongous_size = ShenandoahHeapRegion::region_size_bytes() * num;
> 
> Lost the original comment. Also, where did the call to `notify_mutator_alloc_words` went?

Good catch.  I've added the call to notify_mutator_alloc_words() back in.  I've also added a comment to clarify that retire_range_from_partition() adjusts the bounds if necessary.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17561#discussion_r1523763408

From kdnilsen at openjdk.org  Wed Mar 13 18:56:39 2024
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Wed, 13 Mar 2024 18:56:39 GMT
Subject: RFR: 8324649: Shenandoah: refactor implementation of free set
 [v14]
In-Reply-To: <PRpSWDmP6ruBTrdz2FaADffHPpafs4s2mpFoZMpt8v8=.111e061d-140c-481b-95b2-de77970374c0@github.com>
References: <VAkn0SrKYZWmnflpM8ZwVAXjUF1LjA0_FCBmRJJ4VSc=.c2f979bd-2957-434e-95ca-7b11b1573900@github.com>
 <DtAJtZcZPNv2FMbF9-FeJIT6T8Oio1TW9yYnw3cceF0=.ed94d2d3-39c2-4f8d-9e00-5dbd81683c93@github.com>
 <PVrVW-I2bKkYzrdBafHAaWF8mw6WtANB3PoOZW5ekRw=.2ab54392-0f5b-4f6f-b5d7-7b7a9b6a0a97@github.com>
 <PRpSWDmP6ruBTrdz2FaADffHPpafs4s2mpFoZMpt8v8=.111e061d-140c-481b-95b2-de77970374c0@github.com>
Message-ID: <Ze0FsFAH4Ds3-ZiotTKIDXpzmXHyQAP03Nu00LqwPhM=.feb3c85b-4ad8-498e-beb2-52195d72f208@github.com>

On Wed, 13 Mar 2024 18:50:17 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp line 1152:
>> 
>>> 1150:   _partitions.retire_range_from_partition(Mutator, beg, end);
>>> 1151: 
>>> 1152:   size_t total_humongous_size = ShenandoahHeapRegion::region_size_bytes() * num;
>> 
>> Lost the original comment. Also, where did the call to `notify_mutator_alloc_words` went?
>
> Good catch.  I've added the call to notify_mutator_alloc_words() back in.  I've also added a comment to clarify that retire_range_from_partition() adjusts the bounds if necessary.

Fixed.  Thanks.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17561#discussion_r1523766561

From kdnilsen at openjdk.org  Wed Mar 13 19:04:22 2024
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Wed, 13 Mar 2024 19:04:22 GMT
Subject: RFR: 8324649: Shenandoah: refactor implementation of free set
 [v14]
In-Reply-To: <PVrVW-I2bKkYzrdBafHAaWF8mw6WtANB3PoOZW5ekRw=.2ab54392-0f5b-4f6f-b5d7-7b7a9b6a0a97@github.com>
References: <VAkn0SrKYZWmnflpM8ZwVAXjUF1LjA0_FCBmRJJ4VSc=.c2f979bd-2957-434e-95ca-7b11b1573900@github.com>
 <DtAJtZcZPNv2FMbF9-FeJIT6T8Oio1TW9yYnw3cceF0=.ed94d2d3-39c2-4f8d-9e00-5dbd81683c93@github.com>
 <PVrVW-I2bKkYzrdBafHAaWF8mw6WtANB3PoOZW5ekRw=.2ab54392-0f5b-4f6f-b5d7-7b7a9b6a0a97@github.com>
Message-ID: <EUW6zgJNy-eVOOCP_2sfv1ne901auG67wIojlenEGnA=.2726ee1b-1cd8-4836-a258-13916914c846@github.com>

On Fri, 1 Mar 2024 17:57:49 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Kelvin Nilsen has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 60 commits:
>> 
>>  - Remove instrumentation and cleanup magic numbers
>>    
>>    Two places, I had used 63 when I should have used
>>    _bits_per_array_element -1.
>>  - Address 32-bit compile issues
>>  - Fix 32-bit size formatting in log messages
>>  - Fix white space
>>  - Merge remote-tracking branch 'origin/master' into restructure-free-set
>>  - Merge branch 'openjdk:master' into master
>>  - Two bug fixes for better performance
>>    
>>    1. Collector reserve size is based on memory available within regions
>>       rather than the region size (oops).
>>    
>>    2. If an attempt to allocate within a region fails and the region has
>>       already provided the percentage presumed by ShenandoahEvacWaste,
>>       retire this region.  This is motivated by observations that
>>       otherwise, we end up with large numbers of regions that have only
>>       a small amount of memory within them (e.g. 4k) and every allocation
>>       request has to wade through all of these regions before it eventually
>>       finds a region that has a sufficiently large amount of available
>>       memory.  In the original Shenandoah free-set implementation, the
>>       behavior was to retire the first time an allocation within that
>>       regions fails, regardless of whether the region has already reached
>>       the ShenandoahEvacWaste threshold.
>>  - Fix off-by-one error in is_forward_consecutive_ones()
>>  - Fix whitespace
>>  - Bug fixes and performance improvements
>>    
>>    1. Correct off-b-one-error in count of trailingones
>>    2. Speed up search for contiguous regions (for humongous allocations) by
>>       sliding window instead of initiating new search each time
>>    3. Bias regular region allocations to favor regions that are already
>>       partially consumed
>>    4. Fix bug in move_regions_from_collector_to_mutator which caused some
>>       non-empty regions to be ignored.
>>  - ... and 50 more: https://git.openjdk.org/jdk/compare/be2b92bd...1aa5a3e6
>
> src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp line 1372:
> 
>> 1370:     if (move_to_collector) {
>> 1371:       // Note: In a previous implementation, regions were only placed into the survivor space (collector_is_free) if
>> 1372:       // they were entirely empty.  I'm not sure I understand the rationale for that.  That alternative behavior would
> 
> We should not leave "I'm not sure..." comments in the code. I believe the reason is exactly what you stated below: we do not want to put evacuated objects (implicitly live) to the region that might be mostly garbage, thus prolonging the garbage lifetime.

Thanks.  I've rewritten the comment in the affirmative.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17561#discussion_r1523776278

From kdnilsen at openjdk.org  Wed Mar 13 19:12:46 2024
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Wed, 13 Mar 2024 19:12:46 GMT
Subject: RFR: 8324649: Shenandoah: refactor implementation of free set
 [v32]
In-Reply-To: <VAkn0SrKYZWmnflpM8ZwVAXjUF1LjA0_FCBmRJJ4VSc=.c2f979bd-2957-434e-95ca-7b11b1573900@github.com>
References: <VAkn0SrKYZWmnflpM8ZwVAXjUF1LjA0_FCBmRJJ4VSc=.c2f979bd-2957-434e-95ca-7b11b1573900@github.com>
Message-ID: <Mu9wTnVX6kIS89pKXTUOHQT2CB7P_m_kSWGQHOQU-ko=.77851b17-c53b-4b59-8a84-6d518a19d35b@github.com>

> Several objectives:
> 1. Reduce humongous allocation failures by segregating regular regions from humongous regions
> 2. Do not retire regions just because an allocation failed within the region if the memory remaining within the region is large enough to represent a LAB
> 3. Track range of empty regions in addition to range of available regions in order to expedite humongous allocations
> 4. Treat collector reserves as available for Mutator allocations after evacuation completes
> 5. Improve encapsulation so as to enable an OldCollector reserve for future integration of generational Shenandoah
> 
> We have compared performance of existing FreeSet implementation with the proposed PR over a broad set of performance workloads and see that the impact is mostly neutral.
> 
> Comparing 105235.0 metrics from control, 220638.0 from experiment.
> Compare: 0.589s
>                           Most impacted benchmarks |                              Most impacted metrics
> -------------------------------------------------------------------------------------------------------
>                                  Shenandoah/jython |                                          cwr_total
> 
> 
>                                 Only in experiment |                                    Only in control
> -------------------------------------------------------------------------------------------------------
>                  crypto.signverify/trigger_failure |                        crypto.rsa/cmr_thread_roots
>                 extremem-large-31g/adjust_pointers |       scimark.sparse.small/concurrent_thread_roots
>             extremem-large-31g/calculate_addresses |              xml.transform/concurrent_thread_roots
>       crypto.signverify/class_unloading_rendezvous |                    mpegaudio/concurrent_weak_roots
>                                   serial/cmr_total |                        crypto.rsa/ctr_thread_roots
> 
> Shenandoah
> -------------------------------------------------------------------------------------------------------
> +5.64% jython/cwr_total p=0.00037
>   Control:      1.928ms (+/-272.40us)        170
>   Test:         2.037ms (+/-322.73us)        344

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

 - Remove comment that pertains only to generational mode
 - Rewrite comment describing rationale for Collector free set membership

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17561/files
  - new: https://git.openjdk.org/jdk/pull/17561/files/9cdb82e5..57d2e71f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17561&range=31
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17561&range=30-31

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

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

From kdnilsen at openjdk.org  Wed Mar 13 19:12:49 2024
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Wed, 13 Mar 2024 19:12:49 GMT
Subject: RFR: 8324649: Shenandoah: refactor implementation of free set
 [v32]
In-Reply-To: <l4QAQ52qDc87mXbr3X3IeMis4upIeQTsBCYis8HVDS8=.143dc5f4-ac08-4f82-81ca-c590983b90fa@github.com>
References: <VAkn0SrKYZWmnflpM8ZwVAXjUF1LjA0_FCBmRJJ4VSc=.c2f979bd-2957-434e-95ca-7b11b1573900@github.com>
 <DtAJtZcZPNv2FMbF9-FeJIT6T8Oio1TW9yYnw3cceF0=.ed94d2d3-39c2-4f8d-9e00-5dbd81683c93@github.com>
 <PVrVW-I2bKkYzrdBafHAaWF8mw6WtANB3PoOZW5ekRw=.2ab54392-0f5b-4f6f-b5d7-7b7a9b6a0a97@github.com>
 <l4QAQ52qDc87mXbr3X3IeMis4upIeQTsBCYis8HVDS8=.143dc5f4-ac08-4f82-81ca-c590983b90fa@github.com>
Message-ID: <-iALTrmYmbI_uzWfWOqIjSK_G4BERqhu-X5G5FHi5Uk=.1a1eaf20-94c8-41e8-97a6-912d1352223c@github.com>

On Wed, 13 Mar 2024 18:22:04 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> src/hotspot/share/gc/shenandoah/shenandoahFullGC.cpp line 1089:
>> 
>>> 1087:     heap->set_used(post_compact.get_live());
>>> 1088:     heap->collection_set()->clear();
>>> 1089:     heap->free_set()->rebuild();
>> 
>> Is this change necessary?
>
> Sorry.  Reverted.

Fixed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17561#discussion_r1523789868

From kdnilsen at openjdk.org  Wed Mar 13 19:12:49 2024
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Wed, 13 Mar 2024 19:12:49 GMT
Subject: RFR: 8324649: Shenandoah: refactor implementation of free set
 [v14]
In-Reply-To: <PVrVW-I2bKkYzrdBafHAaWF8mw6WtANB3PoOZW5ekRw=.2ab54392-0f5b-4f6f-b5d7-7b7a9b6a0a97@github.com>
References: <VAkn0SrKYZWmnflpM8ZwVAXjUF1LjA0_FCBmRJJ4VSc=.c2f979bd-2957-434e-95ca-7b11b1573900@github.com>
 <DtAJtZcZPNv2FMbF9-FeJIT6T8Oio1TW9yYnw3cceF0=.ed94d2d3-39c2-4f8d-9e00-5dbd81683c93@github.com>
 <PVrVW-I2bKkYzrdBafHAaWF8mw6WtANB3PoOZW5ekRw=.2ab54392-0f5b-4f6f-b5d7-7b7a9b6a0a97@github.com>
Message-ID: <1couqu-BqxyzZLCeUTZwhwj4xaBgyH309rH2O82znjM=.8ffad079-4025-41f0-80d2-587a7fd0e3a8@github.com>

On Fri, 1 Mar 2024 17:59:10 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Kelvin Nilsen has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 60 commits:
>> 
>>  - Remove instrumentation and cleanup magic numbers
>>    
>>    Two places, I had used 63 when I should have used
>>    _bits_per_array_element -1.
>>  - Address 32-bit compile issues
>>  - Fix 32-bit size formatting in log messages
>>  - Fix white space
>>  - Merge remote-tracking branch 'origin/master' into restructure-free-set
>>  - Merge branch 'openjdk:master' into master
>>  - Two bug fixes for better performance
>>    
>>    1. Collector reserve size is based on memory available within regions
>>       rather than the region size (oops).
>>    
>>    2. If an attempt to allocate within a region fails and the region has
>>       already provided the percentage presumed by ShenandoahEvacWaste,
>>       retire this region.  This is motivated by observations that
>>       otherwise, we end up with large numbers of regions that have only
>>       a small amount of memory within them (e.g. 4k) and every allocation
>>       request has to wade through all of these regions before it eventually
>>       finds a region that has a sufficiently large amount of available
>>       memory.  In the original Shenandoah free-set implementation, the
>>       behavior was to retire the first time an allocation within that
>>       regions fails, regardless of whether the region has already reached
>>       the ShenandoahEvacWaste threshold.
>>  - Fix off-by-one error in is_forward_consecutive_ones()
>>  - Fix whitespace
>>  - Bug fixes and performance improvements
>>    
>>    1. Correct off-b-one-error in count of trailingones
>>    2. Speed up search for contiguous regions (for humongous allocations) by
>>       sliding window instead of initiating new search each time
>>    3. Bias regular region allocations to favor regions that are already
>>       partially consumed
>>    4. Fix bug in move_regions_from_collector_to_mutator which caused some
>>       non-empty regions to be ignored.
>>  - ... and 50 more: https://git.openjdk.org/jdk/compare/be2b92bd...1aa5a3e6
>
> src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp line 1541:
> 
>> 1539:   shenandoah_assert_heaplocked();
>> 1540: 
>> 1541:   // Allocation request is known to satisfy all memory budgeting constraints.
> 
> What does it mean?

I'll remove this comment.  It is a future vestige belonging to generational GC.  In that realm, we enforce independent budgets on OLD allocations for the purpose of promoting vs OLD allocations for the purpose of compacting.  We may reject certain promotions "at the moment" if they run a risk of compromising our ability to finish compaction of a mixed evacuation's OLD collection set.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17561#discussion_r1523788231

From rkennke at openjdk.org  Wed Mar 13 20:20:54 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Wed, 13 Mar 2024 20:20:54 GMT
Subject: RFR: 8324649: Shenandoah: refactor implementation of free set
 [v32]
In-Reply-To: <Mu9wTnVX6kIS89pKXTUOHQT2CB7P_m_kSWGQHOQU-ko=.77851b17-c53b-4b59-8a84-6d518a19d35b@github.com>
References: <VAkn0SrKYZWmnflpM8ZwVAXjUF1LjA0_FCBmRJJ4VSc=.c2f979bd-2957-434e-95ca-7b11b1573900@github.com>
 <Mu9wTnVX6kIS89pKXTUOHQT2CB7P_m_kSWGQHOQU-ko=.77851b17-c53b-4b59-8a84-6d518a19d35b@github.com>
Message-ID: <HgHiTh_t5gXIEQnpJ8EbuF3mVuuyGOOh0DFsikSmo9E=.906d3f45-9210-4c24-9817-720935389846@github.com>

On Wed, 13 Mar 2024 19:12:46 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> Several objectives:
>> 1. Reduce humongous allocation failures by segregating regular regions from humongous regions
>> 2. Do not retire regions just because an allocation failed within the region if the memory remaining within the region is large enough to represent a LAB
>> 3. Track range of empty regions in addition to range of available regions in order to expedite humongous allocations
>> 4. Treat collector reserves as available for Mutator allocations after evacuation completes
>> 5. Improve encapsulation so as to enable an OldCollector reserve for future integration of generational Shenandoah
>> 
>> We have compared performance of existing FreeSet implementation with the proposed PR over a broad set of performance workloads and see that the impact is mostly neutral.
>> 
>> Comparing 105235.0 metrics from control, 220638.0 from experiment.
>> Compare: 0.589s
>>                           Most impacted benchmarks |                              Most impacted metrics
>> -------------------------------------------------------------------------------------------------------
>>                                  Shenandoah/jython |                                          cwr_total
>> 
>> 
>>                                 Only in experiment |                                    Only in control
>> -------------------------------------------------------------------------------------------------------
>>                  crypto.signverify/trigger_failure |                        crypto.rsa/cmr_thread_roots
>>                 extremem-large-31g/adjust_pointers |       scimark.sparse.small/concurrent_thread_roots
>>             extremem-large-31g/calculate_addresses |              xml.transform/concurrent_thread_roots
>>       crypto.signverify/class_unloading_rendezvous |                    mpegaudio/concurrent_weak_roots
>>                                   serial/cmr_total |                        crypto.rsa/ctr_thread_roots
>> 
>> Shenandoah
>> -------------------------------------------------------------------------------------------------------
>> +5.64% jython/cwr_total p=0.00037
>>   Control:      1.928ms (+/-272.40us)        170
>>   Test:         2.037ms (+/-322.73us)        344
>
> Kelvin Nilsen has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Remove comment that pertains only to generational mode
>  - Rewrite comment describing rationale for Collector free set membership

Not a complete review by any means, only a few comments/questions on design choices, the answer to which may affect the rest of the review.

src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp line 46:

> 44: }
> 45: 
> 46: size_t ShenandoahSimpleBitMap::count_leading_ones(ssize_t start_idx) const {

Are you sure that you can't use the BitMap class in src/hotspot/share/utilities/bitMap.*? Or maybe only src/hotspot/share/utilities/count_leading_zeros.hpp or src/hotspot/share/utilities/count_trailing_zeros.hpp? That would emit CPU instructions that do the counting really fast, if possible. I.e. reverse all bits after loading, then find leading/trailing zeros, problem solved real fast. I would even argue to augment the BitMap class with count_* methods as needed, using the CPU-optimized routines.

src/hotspot/share/gc/shenandoah/shenandoahFreeSet.hpp line 41:

> 39: 
> 40: 
> 41: // ShenandoahSimpleBitMap resembles CHeapBitMap but adds missing support for find_next_consecutive_bits() and

Ah I see you have considered using bitMap.* ... but why not 'simply' add the required methods there, instead?

src/hotspot/share/gc/shenandoah/shenandoahFreeSet.hpp line 48:

> 46:   const ssize_t _num_bits;
> 47:   const size_t _num_words;
> 48:   size_t* const _bitmap;

I'd question the choice of size_t as type for the bitmap elements. size_t is typically used as size of index of arrays. If you want word-sized type, use intx or uintx instead?

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

> 1: /*

I don't think any of the code in shenandoahFreeSet.inline.hpp is public/used by any code outside of shenandoahFreeSet.cpp, which means that all of it should go into shenandoahFreeSet.cpp. The methods can still be 'inline'. The convention for .inline.hpp is mostly used to allow sharing inlined code and resolving circular dependencies.

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

PR Review: https://git.openjdk.org/jdk/pull/17561#pullrequestreview-1935079978
PR Review Comment: https://git.openjdk.org/jdk/pull/17561#discussion_r1523846507
PR Review Comment: https://git.openjdk.org/jdk/pull/17561#discussion_r1523854593
PR Review Comment: https://git.openjdk.org/jdk/pull/17561#discussion_r1523860910
PR Review Comment: https://git.openjdk.org/jdk/pull/17561#discussion_r1523834166

From kdnilsen at openjdk.org  Wed Mar 13 20:36:41 2024
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Wed, 13 Mar 2024 20:36:41 GMT
Subject: RFR: 8328126: GenShen: Reduce verbosity of logging for satb mode
Message-ID: <6VP789upiihNbveBH6smGkdpmrmYWGjg8lWre00dWSo=.8b2471cc-e92e-4f8b-a41d-626cb482b09b@github.com>

Only dump collection-set details if Debug logging is enabled.  With this change, generational-mode and satb-mode logging will match in this regard.

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

Commit messages:
 - Make satb-mode GC logging less verbose
 - Revert "Make satb-mode Info logging less verbose"
 - Make satb-mode Info logging less verbose
 - Merge branch 'openjdk:master' into master
 - Merge branch 'openjdk:master' into master
 - Revert "Round LAB sizes down rather than up to force alignment"
 - Round LAB sizes down rather than up to force alignment
 - Revert "Remove dead code for inelastic plabs"
 - Remove dead code for inelastic plabs

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

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

From rkennke at openjdk.org  Thu Mar 14 08:24:28 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Thu, 14 Mar 2024 08:24:28 GMT
Subject: RFR: 8328075: Shenandoah: Avoid forwarding when objects don't move in
 full-GC
Message-ID: <E8tebKZ60mW5qFLqpLEhzkNcAALi7rPIVQJSHoVTUDk=.59785bed-a0a1-45af-b4cc-52ec6491ba7b@github.com>

Currently, in Shenandoah's full-GC, we forward all marked objects (and preserve their headers), even if they don't move. This typically happens for a certain amount of 'sediment' that accumulates at the bottom of the heap. This results in wasted CPU cycles and memory accesses and usage. It can easily be avoided by not forwarding objects that don't move.

The fix is to simply not forward objects when they don't move.

Testing:
 - [x] hotspot_gc_shenandoah
 - [x] tier1 +UseShenandoahGC

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

Commit messages:
 - 8328107: Shenandoah/C2: TestVerifyLoopOptimizations test failure

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

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

From wkemper at openjdk.org  Thu Mar 14 16:00:17 2024
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 14 Mar 2024 16:00:17 GMT
Subject: RFR: 8328126: GenShen: Reduce verbosity of logging for satb mode
In-Reply-To: <6VP789upiihNbveBH6smGkdpmrmYWGjg8lWre00dWSo=.8b2471cc-e92e-4f8b-a41d-626cb482b09b@github.com>
References: <6VP789upiihNbveBH6smGkdpmrmYWGjg8lWre00dWSo=.8b2471cc-e92e-4f8b-a41d-626cb482b09b@github.com>
Message-ID: <zSCo-6FskqmT-ZeL3bSIq3ym3wwCPM60YSYOiHUvhnw=.811a2214-b901-4fcc-af70-6a5761c8f166@github.com>

On Wed, 13 Mar 2024 20:21:54 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

> Only dump collection-set details if Debug logging is enabled.  With this change, generational-mode and satb-mode logging will match in this regard.

Marked as reviewed by wkemper (Committer).

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

PR Review: https://git.openjdk.org/shenandoah/pull/405#pullrequestreview-1937126688

From wkemper at openjdk.org  Thu Mar 14 16:01:43 2024
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 14 Mar 2024 16:01:43 GMT
Subject: RFR: 8328075: Shenandoah: Avoid forwarding when objects don't move
 in full-GC
In-Reply-To: <E8tebKZ60mW5qFLqpLEhzkNcAALi7rPIVQJSHoVTUDk=.59785bed-a0a1-45af-b4cc-52ec6491ba7b@github.com>
References: <E8tebKZ60mW5qFLqpLEhzkNcAALi7rPIVQJSHoVTUDk=.59785bed-a0a1-45af-b4cc-52ec6491ba7b@github.com>
Message-ID: <Qa5r5UnJxeHxZOROWueJJxmo07I4kbKNd89grORDuI4=.3e3037cc-3b80-41be-9005-b86b8a78d60e@github.com>

On Wed, 13 Mar 2024 16:26:30 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> Currently, in Shenandoah's full-GC, we forward all marked objects (and preserve their headers), even if they don't move. This typically happens for a certain amount of 'sediment' that accumulates at the bottom of the heap. This results in wasted CPU cycles and memory accesses and usage. It can easily be avoided by not forwarding objects that don't move.
> 
> The fix is to simply not forward objects when they don't move.
> 
> Testing:
>  - [x] hotspot_gc_shenandoah
>  - [x] tier1 +UseShenandoahGC

LGTM

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

Marked as reviewed by wkemper (Committer).

PR Review: https://git.openjdk.org/jdk/pull/18280#pullrequestreview-1937132581

From shade at openjdk.org  Thu Mar 14 17:43:46 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 14 Mar 2024 17:43:46 GMT
Subject: RFR: 8328075: Shenandoah: Avoid forwarding when objects don't move
 in full-GC
In-Reply-To: <E8tebKZ60mW5qFLqpLEhzkNcAALi7rPIVQJSHoVTUDk=.59785bed-a0a1-45af-b4cc-52ec6491ba7b@github.com>
References: <E8tebKZ60mW5qFLqpLEhzkNcAALi7rPIVQJSHoVTUDk=.59785bed-a0a1-45af-b4cc-52ec6491ba7b@github.com>
Message-ID: <fWD3noUDyHneZZ1iyj4WSN0TcIvZYu5SUXTw2Oh4xrw=.6c80c27e-5f14-4860-878f-550e519fbadf@github.com>

On Wed, 13 Mar 2024 16:26:30 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> Currently, in Shenandoah's full-GC, we forward all marked objects (and preserve their headers), even if they don't move. This typically happens for a certain amount of 'sediment' that accumulates at the bottom of the heap. This results in wasted CPU cycles and memory accesses and usage. It can easily be avoided by not forwarding objects that don't move.
> 
> The fix is to simply not forward objects when they don't move.
> 
> Testing:
>  - [x] hotspot_gc_shenandoah
>  - [x] tier1 +UseShenandoahGC

A few nits. I think we do the same thing for humongous objects already (where it is really painful), no particular reason not to do the same for regular ones. Any performance tests for Full GC improve?

src/hotspot/share/gc/shenandoah/shenandoahFullGC.cpp line 367:

> 365:     }
> 366: 
> 367:     // Object fits into current region, record new location:

", record new location if object needs to move:"?

src/hotspot/share/gc/shenandoah/shenandoahFullGC.cpp line 869:

> 867:       HeapWord* compact_from = cast_from_oop<HeapWord*>(p);
> 868:       HeapWord* compact_to = cast_from_oop<HeapWord*>(p->forwardee());
> 869:       assert(compact_from != compact_to, "forwarded object doesn't move");

"Forwarded object should move"?

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

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18280#pullrequestreview-1937293992
PR Review Comment: https://git.openjdk.org/jdk/pull/18280#discussion_r1525228752
PR Review Comment: https://git.openjdk.org/jdk/pull/18280#discussion_r1525275438

From kdnilsen at openjdk.org  Thu Mar 14 18:34:39 2024
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Thu, 14 Mar 2024 18:34:39 GMT
Subject: RFR: 8328075: Shenandoah: Avoid forwarding when objects don't move
 in full-GC
In-Reply-To: <E8tebKZ60mW5qFLqpLEhzkNcAALi7rPIVQJSHoVTUDk=.59785bed-a0a1-45af-b4cc-52ec6491ba7b@github.com>
References: <E8tebKZ60mW5qFLqpLEhzkNcAALi7rPIVQJSHoVTUDk=.59785bed-a0a1-45af-b4cc-52ec6491ba7b@github.com>
Message-ID: <YcM-iAptetmO859WvBA7OHLMjbkYv3wNPoMtqc6rgZo=.bb4d013d-08b6-4f75-a0b3-df46e93a7241@github.com>

On Wed, 13 Mar 2024 16:26:30 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> Currently, in Shenandoah's full-GC, we forward all marked objects (and preserve their headers), even if they don't move. This typically happens for a certain amount of 'sediment' that accumulates at the bottom of the heap. This results in wasted CPU cycles and memory accesses and usage. It can easily be avoided by not forwarding objects that don't move.
> 
> The fix is to simply not forward objects when they don't move.
> 
> Testing:
>  - [x] hotspot_gc_shenandoah
>  - [x] tier1 +UseShenandoahGC

Looks good after Aleksey's assertion comment fix.  (FWIW, i've seen many back-to-back Full GCs that do not relocate any objects on some of the jtreg tests.  Of course, these back-to-back Full GCs hopefully don't represent typical behavior of real workloads.)

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

Marked as reviewed by kdnilsen (no project role).

PR Review: https://git.openjdk.org/jdk/pull/18280#pullrequestreview-1937463062

From rkennke at openjdk.org  Thu Mar 14 20:01:02 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Thu, 14 Mar 2024 20:01:02 GMT
Subject: RFR: 8328075: Shenandoah: Avoid forwarding when objects don't move
 in full-GC [v2]
In-Reply-To: <E8tebKZ60mW5qFLqpLEhzkNcAALi7rPIVQJSHoVTUDk=.59785bed-a0a1-45af-b4cc-52ec6491ba7b@github.com>
References: <E8tebKZ60mW5qFLqpLEhzkNcAALi7rPIVQJSHoVTUDk=.59785bed-a0a1-45af-b4cc-52ec6491ba7b@github.com>
Message-ID: <PNWsMggyJ6QALF6jQEtoOsu65G1-IJNrdl26L4WOyj0=.35945cee-4252-4917-874a-c6630b5e4a14@github.com>

> Currently, in Shenandoah's full-GC, we forward all marked objects (and preserve their headers), even if they don't move. This typically happens for a certain amount of 'sediment' that accumulates at the bottom of the heap. This results in wasted CPU cycles and memory accesses and usage. It can easily be avoided by not forwarding objects that don't move.
> 
> The fix is to simply not forward objects when they don't move.
> 
> Testing:
>  - [x] hotspot_gc_shenandoah
>  - [x] tier1 +UseShenandoahGC

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

  Comment and assert msg improvement

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18280/files
  - new: https://git.openjdk.org/jdk/pull/18280/files/079fe89d..69493333

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

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

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

From wkemper at openjdk.org  Thu Mar 14 21:50:06 2024
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 14 Mar 2024 21:50:06 GMT
Subject: RFR: 8328220: GenShen: Move generational mode operational parameters
 out of ShenandoahHeap
Message-ID: <EFKLJAJVQOUxjmsQp2-ToB827pP0YJAUJ0AKWxQjmDk=.49cd0029-f280-40f2-bf82-8438fab02337@github.com>

* Many fields previously defined in `ShenandoahHeap` have been moved to `ShenandoahOldGeneration`.
* Generational specific serviceability has been moved to `ShenandoahGenerationalHeap`.
* Methods for sizing the old generation have been moved to `ShenandoahGenerationalHeap`.
* `ShenandoahGenerationalHeap::heap()` now asserts that the generational mode is active.

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

Commit messages:
 - Pre-PR review cleanup
 - Improve comment
 - So long ShenandoahCollectionSetParameters, we hardly new ye
 - Find better homes for evacuation reserves
 - Move generational memory pools into shGenHeap
 - Move surplus/deficit calculations into shGenHeap
 - Move card marking for old evacuations to old generation
 - Move reporting of failed promotion from heap to old gen
 - Move failed old gen evac flag from heap to old gen
 - Fix issues
 - ... and 4 more: https://git.openjdk.org/shenandoah/compare/e9a1c699...00f8778b

Changes: https://git.openjdk.org/shenandoah/pull/406/files
  Webrev: https://webrevs.openjdk.org/?repo=shenandoah&pr=406&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8328220
  Stats: 1425 lines in 24 files changed: 646 ins; 661 del; 118 mod
  Patch: https://git.openjdk.org/shenandoah/pull/406.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah.git pull/406/head:pull/406

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

From ysr at openjdk.org  Fri Mar 15 01:06:38 2024
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Fri, 15 Mar 2024 01:06:38 GMT
Subject: RFR: 8328075: Shenandoah: Avoid forwarding when objects don't move
 in full-GC [v2]
In-Reply-To: <PNWsMggyJ6QALF6jQEtoOsu65G1-IJNrdl26L4WOyj0=.35945cee-4252-4917-874a-c6630b5e4a14@github.com>
References: <E8tebKZ60mW5qFLqpLEhzkNcAALi7rPIVQJSHoVTUDk=.59785bed-a0a1-45af-b4cc-52ec6491ba7b@github.com>
 <PNWsMggyJ6QALF6jQEtoOsu65G1-IJNrdl26L4WOyj0=.35945cee-4252-4917-874a-c6630b5e4a14@github.com>
Message-ID: <4VO0BOJb7PSdfmggszVenivo33O-_MADHrBaqBarh4M=.2fcab177-2466-44bc-baff-bc530bd4f543@github.com>

On Thu, 14 Mar 2024 20:01:02 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> Currently, in Shenandoah's full-GC, we forward all marked objects (and preserve their headers), even if they don't move. This typically happens for a certain amount of 'sediment' that accumulates at the bottom of the heap. This results in wasted CPU cycles and memory accesses and usage. It can easily be avoided by not forwarding objects that don't move.
>> 
>> The fix is to simply not forward objects when they don't move.
>> 
>> Testing:
>>  - [x] hotspot_gc_shenandoah
>>  - [x] tier1 +UseShenandoahGC
>
> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Comment and assert msg improvement

Marked as reviewed by ysr (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/18280#pullrequestreview-1937954833

From ysr at openjdk.org  Fri Mar 15 01:50:22 2024
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Fri, 15 Mar 2024 01:50:22 GMT
Subject: RFR: 8328235: GenShen: Robustify ShenandoahGCSession and fix missing
 use
Message-ID: <ViHIdrG0sja7rFJOMLnOkso6t--zQrnoQSnsrkLz4B0=.859112c8-2064-4a51-912c-0ce5667af37d@github.com>

ShenandoahGCSession is intended to create a scope where the ShenandoahHeap's _gc_cause and _gc_generation field reflect the current gc cycle. We now check that we do not overwrite existing non-default settings (respectively _no_gc and nullptr). The destructor of the scope/stack object also resets these fields to their default settings, ensuring intended uses. This uncovered a situation where the scope was not entered when it should have been, which we have now fixed.

Testing in progress.

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

Commit messages:
 - Robustify ShenandoahGCSession, and fix a missing use for

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

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

From rkennke at openjdk.org  Fri Mar 15 11:10:43 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Fri, 15 Mar 2024 11:10:43 GMT
Subject: RFR: 8328075: Shenandoah: Avoid forwarding when objects don't move
 in full-GC [v2]
In-Reply-To: <PNWsMggyJ6QALF6jQEtoOsu65G1-IJNrdl26L4WOyj0=.35945cee-4252-4917-874a-c6630b5e4a14@github.com>
References: <E8tebKZ60mW5qFLqpLEhzkNcAALi7rPIVQJSHoVTUDk=.59785bed-a0a1-45af-b4cc-52ec6491ba7b@github.com>
 <PNWsMggyJ6QALF6jQEtoOsu65G1-IJNrdl26L4WOyj0=.35945cee-4252-4917-874a-c6630b5e4a14@github.com>
Message-ID: <naprt8esK2uHLaYdfzn2ZVX4Yt1cK2P7rykf2jGDl90=.7a184744-663e-4d05-94db-02d1306798f2@github.com>

On Thu, 14 Mar 2024 20:01:02 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> Currently, in Shenandoah's full-GC, we forward all marked objects (and preserve their headers), even if they don't move. This typically happens for a certain amount of 'sediment' that accumulates at the bottom of the heap. This results in wasted CPU cycles and memory accesses and usage. It can easily be avoided by not forwarding objects that don't move.
>> 
>> The fix is to simply not forward objects when they don't move.
>> 
>> Testing:
>>  - [x] hotspot_gc_shenandoah
>>  - [x] tier1 +UseShenandoahGC
>
> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Comment and assert msg improvement

Thanks!

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

PR Comment: https://git.openjdk.org/jdk/pull/18280#issuecomment-1999427203

From rkennke at openjdk.org  Fri Mar 15 11:10:43 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Fri, 15 Mar 2024 11:10:43 GMT
Subject: Integrated: 8328075: Shenandoah: Avoid forwarding when objects don't
 move in full-GC
In-Reply-To: <E8tebKZ60mW5qFLqpLEhzkNcAALi7rPIVQJSHoVTUDk=.59785bed-a0a1-45af-b4cc-52ec6491ba7b@github.com>
References: <E8tebKZ60mW5qFLqpLEhzkNcAALi7rPIVQJSHoVTUDk=.59785bed-a0a1-45af-b4cc-52ec6491ba7b@github.com>
Message-ID: <rWb1HOHHkI9S2G9svvX_5cA6vOYQl8Wx8Xn1uUovILY=.fbce1fad-eddc-41b3-89b9-7bf48e8b1eb5@github.com>

On Wed, 13 Mar 2024 16:26:30 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> Currently, in Shenandoah's full-GC, we forward all marked objects (and preserve their headers), even if they don't move. This typically happens for a certain amount of 'sediment' that accumulates at the bottom of the heap. This results in wasted CPU cycles and memory accesses and usage. It can easily be avoided by not forwarding objects that don't move.
> 
> The fix is to simply not forward objects when they don't move.
> 
> Testing:
>  - [x] hotspot_gc_shenandoah
>  - [x] tier1 +UseShenandoahGC

This pull request has now been integrated.

Changeset: 80ccc989
Author:    Roman Kennke <rkennke at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/80ccc989a892e4d9f4e2c9395a100cfabbdcda64
Stats:     6 lines in 1 file changed: 3 ins; 0 del; 3 mod

8328075: Shenandoah: Avoid forwarding when objects don't move in full-GC

Reviewed-by: wkemper, shade, kdnilsen, ysr

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

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

From ysr at openjdk.org  Sat Mar 16 22:33:47 2024
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Sat, 16 Mar 2024 22:33:47 GMT
Subject: RFR: 8328235: GenShen: Robustify ShenandoahGCSession and fix
 missing use
In-Reply-To: <ViHIdrG0sja7rFJOMLnOkso6t--zQrnoQSnsrkLz4B0=.859112c8-2064-4a51-912c-0ce5667af37d@github.com>
References: <ViHIdrG0sja7rFJOMLnOkso6t--zQrnoQSnsrkLz4B0=.859112c8-2064-4a51-912c-0ce5667af37d@github.com>
Message-ID: <HJEZZYkNHZEclDUCiMlaM0nYxxKg2L4aB-qhFtmc5BE=.8dbe565f-871f-433b-88cb-7d6043f4efc5@github.com>

On Fri, 15 Mar 2024 01:45:51 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

> ShenandoahGCSession is intended to create a scope where the ShenandoahHeap's _gc_cause and _gc_generation field reflect the current gc cycle. We now check that we do not overwrite existing non-default settings (respectively _no_gc and nullptr). The destructor of the scope/stack object also resets these fields to their default settings, ensuring intended uses. This uncovered a situation where the scope was not entered when it should have been, which we have now fixed.
> 
> *Testing*:
> - [ ] code pipeline : in progress
> - [x] specjbb
> - [x] jtreg:hotspot_gc w/fastdebug
> - [x] GHA: existing failures unrelated to this change

Code pipeline testing revealed a further scenario when `active_generation()` was used outside of what should have been a gc session (temporal) scope. I'll revert this to a draft until I fix that issue as well.

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

PR Comment: https://git.openjdk.org/shenandoah/pull/407#issuecomment-2000082870

From wkemper at openjdk.org  Sat Mar 16 22:34:33 2024
From: wkemper at openjdk.org (William Kemper)
Date: Sat, 16 Mar 2024 22:34:33 GMT
Subject: RFR: Merge openjdk/jdk:master [v4]
In-Reply-To: <RZZe4VbaACWsfqB8dD1xlG2wJuhMugi3sT71hGkx9ks=.5e2d2671-f91b-4e69-b59c-6e8253c991e3@github.com>
References: <AS_pM2SZw7OhfafGXUXGMWgKw8MwuYj4XDt9Yfet2MQ=.2ef4c4fc-a51e-44e2-80e7-10c22a13ff07@github.com>
 <RZZe4VbaACWsfqB8dD1xlG2wJuhMugi3sT71hGkx9ks=.5e2d2671-f91b-4e69-b59c-6e8253c991e3@github.com>
Message-ID: <u6xnEBIvtXppuf3ggIETuwms_8nkNlvzmPxPab1VEyw=.c0e19635-4cb7-4c44-ae08-7767b53f4d26@github.com>

On Fri, 1 Mar 2024 22:18:46 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> Merges tag jdk-23+11
>
> William Kemper has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 95 commits:
> 
>  - Merge branch 'shenandoah-master' into merge-jdk-23+11
>  - Fix zero build
>  - Merge remote-tracking branch 'shenandoah/master' into merge-jdk-23+11
>  - 8326461: tools/jlink/CheckExecutable.java fails as .debuginfo files are not executable
>    
>    Reviewed-by: shade, alanb
>  - 8325870: Zap end padding bits for ArrayOops in non-release builds
>    
>    Reviewed-by: stefank, ayang
>  - 8326414: Serial: Inline SerialHeap::create_rem_set
>    
>    Reviewed-by: kbarrett
>  - 8323695: RenderPerf (2D) enhancements (23.12)
>    
>    Reviewed-by: avu, prr
>  - 8324243: Compilation failures in java.desktop module with gcc 14
>    
>    Reviewed-by: jwaters, ihse, kbarrett, prr
>  - 8325342: Remove unneeded exceptions in compare.sh
>    
>    Reviewed-by: erikj
>  - 8326158: Javadoc for java.time.DayOfWeek#minus(long)
>    
>    Reviewed-by: iris, lancea
>  - ... and 85 more: https://git.openjdk.org/shenandoah/compare/b7c68eb3...bb8c2163

Superseded by https://github.com/openjdk/shenandoah/pull/408

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

PR Comment: https://git.openjdk.org/shenandoah/pull/399#issuecomment-2000324920

From wkemper at openjdk.org  Sat Mar 16 22:34:32 2024
From: wkemper at openjdk.org (William Kemper)
Date: Sat, 16 Mar 2024 22:34:32 GMT
Subject: RFR: Merge openjdk/jdk:master
In-Reply-To: <YxtDv_HGCQSXqEpNmPAYgPU3PBbXc0jDrHEN_WDq9hQ=.8de63ded-c2bf-43d8-b39b-2b659453483c@github.com>
References: <YxtDv_HGCQSXqEpNmPAYgPU3PBbXc0jDrHEN_WDq9hQ=.8de63ded-c2bf-43d8-b39b-2b659453483c@github.com>
Message-ID: <_lbu4Ep-FIKfvvkWB3eAFJK9tbkRIJS6lpmx0XinMGc=.b9f0a851-2944-4451-a4eb-90cd11b1df3f@github.com>

On Fri, 8 Mar 2024 14:10:37 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Merges tag jdk-23+13

Superseded by https://github.com/openjdk/shenandoah/pull/408

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

PR Comment: https://git.openjdk.org/shenandoah/pull/404#issuecomment-2000324396

From wkemper at openjdk.org  Sat Mar 16 22:34:33 2024
From: wkemper at openjdk.org (William Kemper)
Date: Sat, 16 Mar 2024 22:34:33 GMT
Subject: Withdrawn: Merge openjdk/jdk:master
In-Reply-To: <YxtDv_HGCQSXqEpNmPAYgPU3PBbXc0jDrHEN_WDq9hQ=.8de63ded-c2bf-43d8-b39b-2b659453483c@github.com>
References: <YxtDv_HGCQSXqEpNmPAYgPU3PBbXc0jDrHEN_WDq9hQ=.8de63ded-c2bf-43d8-b39b-2b659453483c@github.com>
Message-ID: <eYANZiyZpHrkAzVKSoLIlp_b5_wSaMJXJ0FPivZnPGs=.3300606f-c9c0-4aa9-ae98-1eb0b3899712@github.com>

On Fri, 8 Mar 2024 14:10:37 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Merges tag jdk-23+13

This pull request has been closed without being integrated.

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

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

From wkemper at openjdk.org  Sat Mar 16 22:34:35 2024
From: wkemper at openjdk.org (William Kemper)
Date: Sat, 16 Mar 2024 22:34:35 GMT
Subject: Withdrawn: Merge openjdk/jdk:master
In-Reply-To: <AS_pM2SZw7OhfafGXUXGMWgKw8MwuYj4XDt9Yfet2MQ=.2ef4c4fc-a51e-44e2-80e7-10c22a13ff07@github.com>
References: <AS_pM2SZw7OhfafGXUXGMWgKw8MwuYj4XDt9Yfet2MQ=.2ef4c4fc-a51e-44e2-80e7-10c22a13ff07@github.com>
Message-ID: <9XZxGA3KffgIorEImMPjkIfHbyrIkdb5tFDeC8s9sdQ=.c15a646c-3495-40cc-9547-38847bb7fcd5@github.com>

On Fri, 23 Feb 2024 14:09:44 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Merges tag jdk-23+11

This pull request has been closed without being integrated.

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

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

From wkemper at openjdk.org  Sat Mar 16 22:34:40 2024
From: wkemper at openjdk.org (William Kemper)
Date: Sat, 16 Mar 2024 22:34:40 GMT
Subject: RFR: Merge openjdk/jdk:master
Message-ID: <HgFAcSGUcLkt_mP0HAT7r_Tkhgs2fwoxUVq-SYnEq0g=.b0f4b0b4-154f-46bb-b238-d917cd58ee2f@github.com>

Merges tag jdk-23+14

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

Commit messages:
 - Merge branch 'shenandoah-master' into merge-jdk-23+14
 - 8328064: Remove obsolete comments in constantPool and metadataFactory
 - 8328030: Convert javax/swing/text/GlyphView/4984669/bug4984669.java applet test to main
 - 8325897: Parallel: Remove PSYoungGen::is_maximal_no_gc
 - 8327755: Convert javax/swing/JScrollBar/8039464/Test8039464.java applet to main
 - 8327754: Convert javax/swing/JPopupMenu/7160604/bug7160604.java applet to main
 - 8327753: Convert javax/swing/JOptionPane/8024926/bug8024926.java applet to main
 - 8327752: Convert javax/swing/JOptionPane/4174551/bug4174551.java applet to main
 - 8328004: Minor updates to TrayIcon test DisposeInActionEventTest.java
 - 8185862: AWT Assertion Failure in ::GetDIBits(hBMDC, hBM, 0, 1, 0, gpBitmapInfo, 0) 'awt_Win32GraphicsDevice.cpp', at line 185
 - ... and 348 more: https://git.openjdk.org/shenandoah/compare/e9a1c699...71b112c3

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

Changes: https://git.openjdk.org/shenandoah/pull/408/files
  Stats: 118798 lines in 2512 files changed: 27172 ins; 82679 del; 8947 mod
  Patch: https://git.openjdk.org/shenandoah/pull/408.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah.git pull/408/head:pull/408

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

From kdnilsen at openjdk.org  Mon Mar 18 13:36:56 2024
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Mon, 18 Mar 2024 13:36:56 GMT
Subject: RFR: 8328307: GenShen: Re-enable old-has-grown trigger for
 old-generation GC
Message-ID: <V2UNOek4Z21vTS_GBk5oi3MfJyC8hkELnTcGc-OxpGU=.09e42b4e-5b0c-493f-8292-6bf78658c553@github.com>

Enable old-gen growth triggers, which were inadvertantly disabled.  This passes the internal regression pipeline tests.

As would be expected, we see an increase in mixed-evacuation triggers.  We also see significant improvement on certain extremem workloads due to improved clearing of old-gen.


   Control: shenandoah-x86-template
Experiment: enable-old-growth-triggers-gh-x86

                          Most impacted benchmarks |                              Most impacted metrics
-------------------------------------------------------------------------------------------------------
                           Genshen/extremem-phased |                             trigger_expedite_mixed
                Genshen/specjbb2015_weak_ref_patch |                                    trigger_failure
                               Genshen/specjbb2015 |                               context_switch_count
                    Genshen/hyperalloc_a3072_o4096 |                                     sla_25000_jops
                            Shenandoah/specjbb2015 |                                      trigger_learn


                                Only in experiment |                                    Only in control
-------------------------------------------------------------------------------------------------------
     hyperalloc_a2048_o2048/trigger_expedite_mixed |                   compress/concurrent_thread_roots
     hyperalloc_a2048_o4096/trigger_expedite_mixed |                        crypto.rsa/ctr_thread_roots
     hyperalloc_a3072_o2048/trigger_expedite_mixed |                               crypto.rsa/ctr_total
     hyperalloc_a3072_o4096/trigger_expedite_mixed |               extremem-large-31g/trigger_expansion
              extremem-large-31g/trigger_overgrown |                  extremem-phased/trigger_expansion

Genshen
-------------------------------------------------------------------------------------------------------
+685.00% specjbb2015_weak_ref_patch/trigger_expedite_mixed p=0.00002
  Control:      2.500   (+/-  0.68  )         30
  Test:        19.625   (+/-  4.79  )         10

+561.90% specjbb2015/trigger_expedite_mixed p=0.00001
  Control:      2.625   (+/-  0.92  )         30
  Test:        17.375   (+/-  3.89  )         10

+225.42% extremem-phased/trigger_expedite_mixed p=0.00000
  Control:      9.833   (+/-  3.48  )         30
  Test:        32.000   (+/-  2.58  )         10

+63.84% hyperalloc_a3072_o4096/evacuation p=0.02662
  Control:     37.260ms (+/- 15.92ms)         42
  Test:        61.045ms (+/- 36.61ms)         18

+46.92% xml.transform/concurrent_class_unloading p=0.00036
  Control:     11.433ms (+/-  5.62ms)         30
  Test:        16.798ms (+/-  3.54ms)         10

+30.00% hyperalloc_a3072_o4096/trigger_failure p=0.00705
  Control:      5.000   (+/-  1.17  )         30
  Test:         6.500   (+/-  1.26  )         10

+14.40% hyperalloc_a2048_o4096/context_switch_count p=0.00000
  Control:   3599.083   (+/-193.26  )         30
  Test:      4117.500   (+/-230.83  )         10

+12.85% hyperalloc_a3072_o4096/context_switch_count p=0.00004
  Control:   4740.125   (+/-321.27  )         30
  Test:      5349.000   (+/-258.71  )         10

+12.21% extremem-phased/degen_update_roots p=0.00263
  Control:      1.323ms (+/- 95.21us)         39
  Test:         1.484ms (+/-113.46us)          3

+9.29% specjbb2015/sla_25000_jops p=0.01885
  Control:   4695.333   (+/-456.15  )         30
  Test:      5131.375   (+/-543.33  )         10

-97102.38% extremem-phased/browsing_history_p100 p=0.00571
  Control:    829.744ms (+/-  1.27s )         30
  Test:       853.625us (+/-710.96ms)         10

-95076.16% extremem-phased/sales_transaction_p100 p=0.00444
  Control:    974.842ms (+/-  1.53s )         30
  Test:         1.024ms (+/-  1.02s )         10

-37209.24% extremem-phased/product_replacement_p100 p=0.00206
  Control:      1.048s  (+/-  1.47s )         30
  Test:         2.810ms (+/-156.82us)         10

-22224.40% extremem-phased/customer_replacement_p100 p=0.00813
  Control:    589.671ms (+/-982.52ms)         30
  Test:         2.641ms (+/-392.66ms)         10

-2919.20% extremem-phased/customer_preparation_p100 p=0.00055
  Control:      2.200s  (+/-  2.57s )         30
  Test:        72.871ms (+/-  1.05s )         10

-1210.30% extremem-phased/customer_purchase_p99_999 p=0.00007
  Control:      2.265s  (+/-  2.34s )         30
  Test:       172.899ms (+/-  1.01s )         10

-831.11% extremem-phased/customer_purchase_p100 p=0.00019
  Control:      2.427s  (+/-  2.45s )         30
  Test:       260.653ms (+/-999.78ms)         10

-828.82% extremem-phased/customer_save_for_later_p100 p=0.00020
  Control:      2.408s  (+/-  2.36s )         30
  Test:       259.252ms (+/-  1.00s )         10

-226.18% extremem-phased/trigger_failure p=0.00019
  Control:     11.960   (+/-  9.07  )         29
  Test:         3.667   (+/-  1.63  )          6

-114.63% specjbb2015/concurrent_reset_old p=0.00000
  Control:     10.276ms (+/-  2.69ms)         30
  Test:         4.788ms (+/-  1.12ms)         98


Shenandoah
-------------------------------------------------------------------------------------------------------
+13.64% specjbb2015/context_switch_count p=0.03029
  Control: 12676397.583   (+/-2132032.46  )         30
  Test:    14405702.000   (+/-1872405.31  )         10

+11.50% specjbb2015/cpu_system p=0.03445
  Control:    238.974s  (+/- 33.40s )         30
  Test:       266.447s  (+/- 31.21s )         10

+9.89% specjbb2015/sla_25000_jops p=0.00140
  Control:   5310.750   (+/-385.68  )         30
  Test:      5835.750   (+/-388.85  )         10

-40.40% scimark.lu.large/concurrent_evacuation p=0.01539
  Control:     10.070ms (+/-  5.53ms)         30
  Test:         7.172ms (+/-  1.30ms)         10

-38.03% serial/concurrent_update_refs p=0.01773
  Control:     21.753ms (+/-  8.87ms)         30
  Test:        15.760ms (+/-  3.97ms)         10

-6.05% extremem-phased/customer_replacement_p99 p=0.02487
  Control:      2.184ms (+/-155.53us)         30
  Test:         2.059ms (+/-128.84us)         10

-5.82% fop/iterations p=0.04415
  Control:      8.333   (+/-  0.61  )         30
  Test:         7.875   (+/-  0.57  )         10

I do not have a good explanation for why aarch64 does not show similar improvement in extremem metrics:

   Control: shenandoah-aarch64-template
Experiment: enable-old-growth-triggers-gh-aarch64

                          Most impacted benchmarks |                              Most impacted metrics
-------------------------------------------------------------------------------------------------------
                           Genshen/extremem-phased |                                      trigger_spike
                Genshen/specjbb2015_weak_ref_patch |                             trigger_expedite_mixed
                               Genshen/specjbb2015 |                            customer_purchase_p99_9
                        Shenandoah/extremem-phased |                      customer_save_for_later_p99_9
                    Genshen/hyperalloc_a3072_o4096 |                                      trigger_learn


                                Only in experiment |                                    Only in control
-------------------------------------------------------------------------------------------------------
     hyperalloc_a2048_o2048/trigger_expedite_mixed |                 scimark.fft.large/cmr_thread_roots
     hyperalloc_a2048_o4096/trigger_expedite_mixed |              scimark.sparse.small/cmr_thread_roots
     hyperalloc_a3072_o2048/trigger_expedite_mixed |                   compress/concurrent_thread_roots
     hyperalloc_a3072_o4096/trigger_expedite_mixed |       scimark.sparse.small/concurrent_thread_roots
                 extremem-phased/trigger_overgrown |                        crypto.rsa/ctr_thread_roots

Genshen
-------------------------------------------------------------------------------------------------------
+526.47% specjbb2015_weak_ref_patch/trigger_expedite_mixed p=0.00000
  Control:      2.833   (+/-  0.97  )         30
  Test:        17.750   (+/-  6.27  )         10

+484.62% specjbb2015/trigger_expedite_mixed p=0.00000
  Control:      3.250   (+/-  0.86  )         30
  Test:        19.000   (+/-  3.00  )         10

+172.37% extremem-phased/trigger_expedite_mixed p=0.00000
  Control:      9.500   (+/-  2.48  )         30
  Test:        25.875   (+/-  1.05  )         10

+115.80% extremem-phased/customer_replacement_p100 p=0.00741
  Control:      1.365s  (+/-  1.65s )         30
  Test:         2.947s  (+/-  1.01s )         10

+110.64% extremem-phased/browsing_history_p100 p=0.00092
  Control:      1.673s  (+/-  2.04s )         30
  Test:         3.524s  (+/-949.61ms)         10

+62.44% extremem-phased/product_replacement_p100 p=0.00909
  Control:      2.018s  (+/-  2.09s )         30
  Test:         3.279s  (+/-822.89ms)         10

+50.72% extremem-phased/customer_preparation_p99_9 p=0.00569
  Control:      2.755s  (+/-  2.33s )         30
  Test:         4.153s  (+/-482.67ms)         10

+50.00% hyperalloc_a3072_o4096/trigger_failure p=0.00001
  Control:      6.167   (+/-  1.46  )         30
  Test:         9.250   (+/-  1.75  )         10

+49.06% extremem-phased/customer_abandonment_p99_9 p=0.00597
  Control:      2.731s  (+/-  2.29s )         30
  Test:         4.071s  (+/-265.97ms)         10

+47.96% extremem-phased/customer_purchase_p99_9 p=0.00799
  Control:      2.699s  (+/-  2.25s )         30
  Test:         3.993s  (+/-229.72ms)         10

-376.43% specjbb2015_weak_ref_patch/concurrent_marking_old p=0.00000
  Control:      1.243s  (+/-406.88ms)         36
  Test:       260.798ms (+/-478.72ms)        542

-374.95% specjbb2015_weak_ref_patch/cm_total_old p=0.00000
  Control:      2.443s  (+/-802.00ms)         35
  Test:       514.416ms (+/-955.60ms)        541

-374.95% specjbb2015_weak_ref_patch/cm_parallel_mark_old p=0.00000
  Control:      2.443s  (+/-802.00ms)         35
  Test:       514.416ms (+/-955.60ms)        541

-140.00% eclipse/trigger_spike p=0.00088
  Control:      2.400   (+/-  1.44  )         24
  Test:         1.000   (+/-  0.00  )          7

-40.36% specjbb2015/trigger_spike p=0.00000
  Control:    119.833   (+/- 12.27  )         30
  Test:        85.375   (+/- 13.40  )         10

-39.37% specjbb2015_weak_ref_patch/trigger_spike p=0.00000
  Control:    124.042   (+/- 17.32  )         30
  Test:        89.000   (+/- 10.03  )         10

-19.93% extremem-phased/trigger_spike p=0.01121
  Control:     26.833   (+/-  5.04  )         30
  Test:        22.375   (+/-  2.99  )         10

-17.50% specjbb2015_weak_ref_patch/sla_100000_jops p=0.00002
  Control:   6127.125   (+/-423.49  )         30
  Test:      5214.375   (+/-583.96  )         10

-17.37% eclipse/context_switch_count p=0.00696
  Control:   7000.875   (+/-1522.26  )         30
  Test:      5964.625   (+/-1001.65  )         10

-16.36% specjbb2015_weak_ref_patch/sla_75000_jops p=0.00525
  Control:   5821.708   (+/-587.53  )         30
  Test:      5003.250   (+/-702.26  )         10


Shenandoah
-------------------------------------------------------------------------------------------------------
+5.25% specjbb2015_weak_ref_patch/fa_thread_roots p=0.00000
  Control:      2.410ms (+/-179.15us)        488
  Test:         2.537ms (+/-131.13us)         68

-49.81% extremem-phased/customer_save_for_later_p99_9 p=0.00988
  Control:      1.333s  (+/-363.67ms)         30
  Test:       889.507ms (+/-368.39ms)         10

-45.63% extremem-phased/customer_purchase_p99_9 p=0.01159
  Control:      1.306s  (+/-359.26ms)         30
  Test:       896.610ms (+/-370.49ms)         10

-41.96% diluvian_medium/context_switch_count p=0.01303
  Control:    101.500   (+/- 30.13  )         30
  Test:        71.500   (+/- 18.40  )         10

-20.89% extremem-phased/customer_preparation_p100 p=0.03521
  Control:      1.768s  (+/-375.37ms)         30
  Test:         1.463s  (+/-333.95ms)         10

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

Commit messages:
 - Add a jtreg test for old growth trigger
 - Re-enable old-growth trigger
 - Make satb-mode Info logging less verbose
 - Merge branch 'openjdk:master' into master
 - Merge branch 'openjdk:master' into master
 - Revert "Round LAB sizes down rather than up to force alignment"
 - Round LAB sizes down rather than up to force alignment
 - Revert "Remove dead code for inelastic plabs"
 - Remove dead code for inelastic plabs

Changes: https://git.openjdk.org/shenandoah/pull/409/files
  Webrev: https://webrevs.openjdk.org/?repo=shenandoah&pr=409&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8328307
  Stats: 149 lines in 3 files changed: 114 ins; 2 del; 33 mod
  Patch: https://git.openjdk.org/shenandoah/pull/409.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah.git pull/409/head:pull/409

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

From kdnilsen at openjdk.org  Mon Mar 18 14:08:47 2024
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Mon, 18 Mar 2024 14:08:47 GMT
Subject: RFR: 8328220: GenShen: Move generational mode operational
 parameters out of ShenandoahHeap
In-Reply-To: <EFKLJAJVQOUxjmsQp2-ToB827pP0YJAUJ0AKWxQjmDk=.49cd0029-f280-40f2-bf82-8438fab02337@github.com>
References: <EFKLJAJVQOUxjmsQp2-ToB827pP0YJAUJ0AKWxQjmDk=.49cd0029-f280-40f2-bf82-8438fab02337@github.com>
Message-ID: <yUhDOPBaN_4xi-jhlw_pz7af-q6skqn3fI7Rnr49jso=.449631e7-bd46-4def-8693-cb1c9e2606a7@github.com>

On Thu, 14 Mar 2024 21:46:14 GMT, William Kemper <wkemper at openjdk.org> wrote:

> * Many fields previously defined in `ShenandoahHeap` have been moved to `ShenandoahOldGeneration`.
> * Generational specific serviceability has been moved to `ShenandoahGenerationalHeap`.
> * Methods for sizing the old generation have been moved to `ShenandoahGenerationalHeap`.
> * `ShenandoahGenerationalHeap::heap()` now asserts that the generational mode is active.

Thank you so much for this much needed refactoring.  This was a lot of careful and thorough work.

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

Marked as reviewed by kdnilsen (Committer).

PR Review: https://git.openjdk.org/shenandoah/pull/406#pullrequestreview-1943184924

From wkemper at openjdk.org  Mon Mar 18 17:05:57 2024
From: wkemper at openjdk.org (William Kemper)
Date: Mon, 18 Mar 2024 17:05:57 GMT
Subject: RFR: 8328307: GenShen: Re-enable old-has-grown trigger for
 old-generation GC
In-Reply-To: <V2UNOek4Z21vTS_GBk5oi3MfJyC8hkELnTcGc-OxpGU=.09e42b4e-5b0c-493f-8292-6bf78658c553@github.com>
References: <V2UNOek4Z21vTS_GBk5oi3MfJyC8hkELnTcGc-OxpGU=.09e42b4e-5b0c-493f-8292-6bf78658c553@github.com>
Message-ID: <F-HDySBacTCd5_9XtsoOgNhLGo3pk4g_ednC7VgFICA=.0d607eb8-1999-462c-bb61-5ab197dab6b9@github.com>

On Mon, 18 Mar 2024 13:32:16 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

> Enable old-gen growth triggers, which were inadvertantly disabled.  This passes the internal regression pipeline tests.
> 
> As would be expected, we see an increase in mixed-evacuation triggers.  We also see significant improvement on certain extremem workloads due to improved clearing of old-gen.
> 
> 
>    Control: shenandoah-x86-template
> Experiment: enable-old-growth-triggers-gh-x86
> 
>                           Most impacted benchmarks |                              Most impacted metrics
> -------------------------------------------------------------------------------------------------------
>                            Genshen/extremem-phased |                             trigger_expedite_mixed
>                 Genshen/specjbb2015_weak_ref_patch |                                    trigger_failure
>                                Genshen/specjbb2015 |                               context_switch_count
>                     Genshen/hyperalloc_a3072_o4096 |                                     sla_25000_jops
>                             Shenandoah/specjbb2015 |                                      trigger_learn
> 
> 
>                                 Only in experiment |                                    Only in control
> -------------------------------------------------------------------------------------------------------
>      hyperalloc_a2048_o2048/trigger_expedite_mixed |                   compress/concurrent_thread_roots
>      hyperalloc_a2048_o4096/trigger_expedite_mixed |                        crypto.rsa/ctr_thread_roots
>      hyperalloc_a3072_o2048/trigger_expedite_mixed |                               crypto.rsa/ctr_total
>      hyperalloc_a3072_o4096/trigger_expedite_mixed |               extremem-large-31g/trigger_expansion
>               extremem-large-31g/trigger_overgrown |                  extremem-phased/trigger_expansion
> 
> Genshen
> -------------------------------------------------------------------------------------------------------
> +685.00% specjbb2015_weak_ref_patch/trigger_expedite_mixed p=0.00002
>   Control:      2.500   (+/-  0.68  )         30
>   Test:        19.625   (+/-  4.79  )         10
> 
> +561.90% specjbb2015/trigger_expedite_mixed p=0.00001
>   Control:      2.625   (+/-  0.92  )         30
>   Test:        17.375   (+/-  3.89  )         10
> 
> +225.42% extremem-phased/trigger_expedite_mixed p=0.00000
>   Control:      9.833   (+/-  3.48  )         30
>   Test:        32.000   (+/-  2.58  )         10
> 
> +63.84% hyperalloc_a3072_o4096/evacuation p=0.02662
>   Control:     37....

test/hotspot/jtreg/gc/shenandoah/generational/TestOldGrowthTriggers.java line 42:

> 40: public class TestOldGrowthTriggers {
> 41: 
> 42:   public static void do_old_allocations() {

Nit, but Java convention is usually camel case: `doOldAllocations` or `makeOldAllocations` if the `oO` looks weird to you ;)

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

PR Review Comment: https://git.openjdk.org/shenandoah/pull/409#discussion_r1528941440

From wkemper at openjdk.org  Mon Mar 18 17:16:47 2024
From: wkemper at openjdk.org (William Kemper)
Date: Mon, 18 Mar 2024 17:16:47 GMT
Subject: RFR: 8328307: GenShen: Re-enable old-has-grown trigger for
 old-generation GC
In-Reply-To: <V2UNOek4Z21vTS_GBk5oi3MfJyC8hkELnTcGc-OxpGU=.09e42b4e-5b0c-493f-8292-6bf78658c553@github.com>
References: <V2UNOek4Z21vTS_GBk5oi3MfJyC8hkELnTcGc-OxpGU=.09e42b4e-5b0c-493f-8292-6bf78658c553@github.com>
Message-ID: <TfsTJl0K9aiKVBd-VYS6wjmqbBSOvIM-HI9g6B7b12g=.b69c76b4-47d2-4e7e-b9bf-1f13a4930ff3@github.com>

On Mon, 18 Mar 2024 13:32:16 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

> Enable old-gen growth triggers, which were inadvertantly disabled.  This passes the internal regression pipeline tests.
> 
> As would be expected, we see an increase in mixed-evacuation triggers.  We also see significant improvement on certain extremem workloads due to improved clearing of old-gen.
> 
> 
>    Control: shenandoah-x86-template
> Experiment: enable-old-growth-triggers-gh-x86
> 
>                           Most impacted benchmarks |                              Most impacted metrics
> -------------------------------------------------------------------------------------------------------
>                            Genshen/extremem-phased |                             trigger_expedite_mixed
>                 Genshen/specjbb2015_weak_ref_patch |                                    trigger_failure
>                                Genshen/specjbb2015 |                               context_switch_count
>                     Genshen/hyperalloc_a3072_o4096 |                                     sla_25000_jops
>                             Shenandoah/specjbb2015 |                                      trigger_learn
> 
> 
>                                 Only in experiment |                                    Only in control
> -------------------------------------------------------------------------------------------------------
>      hyperalloc_a2048_o2048/trigger_expedite_mixed |                   compress/concurrent_thread_roots
>      hyperalloc_a2048_o4096/trigger_expedite_mixed |                        crypto.rsa/ctr_thread_roots
>      hyperalloc_a3072_o2048/trigger_expedite_mixed |                               crypto.rsa/ctr_total
>      hyperalloc_a3072_o4096/trigger_expedite_mixed |               extremem-large-31g/trigger_expansion
>               extremem-large-31g/trigger_overgrown |                  extremem-phased/trigger_expansion
> 
> Genshen
> -------------------------------------------------------------------------------------------------------
> +685.00% specjbb2015_weak_ref_patch/trigger_expedite_mixed p=0.00002
>   Control:      2.500   (+/-  0.68  )         30
>   Test:        19.625   (+/-  4.79  )         10
> 
> +561.90% specjbb2015/trigger_expedite_mixed p=0.00001
>   Control:      2.625   (+/-  0.92  )         30
>   Test:        17.375   (+/-  3.89  )         10
> 
> +225.42% extremem-phased/trigger_expedite_mixed p=0.00000
>   Control:      9.833   (+/-  3.48  )         30
>   Test:        32.000   (+/-  2.58  )         10
> 
> +63.84% hyperalloc_a3072_o4096/evacuation p=0.02662
>   Control:     37....

Changes requested by wkemper (Committer).

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

> 3192:   _free_set->rebuild(young_cset_regions, old_cset_regions);
> 3193: 
> 3194:   if (mode()->is_generational()) {

In the spirit of moving generational mode things out of `ShenandoahHeap`, may I suggest factoring out two methods here for `ShenandoahOldGeneration`:
* `trigger_collection_if_fragmented`
* `trigger_collection_if_overgrown`

Or perhaps, make `ShenandoahHeap::rebuild_free_set` virtual and put all the generational code into an override in `ShenandoahGenerationalHeap`?

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

PR Review: https://git.openjdk.org/shenandoah/pull/409#pullrequestreview-1943714568
PR Review Comment: https://git.openjdk.org/shenandoah/pull/409#discussion_r1528955590

From kdnilsen at openjdk.org  Mon Mar 18 17:27:47 2024
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Mon, 18 Mar 2024 17:27:47 GMT
Subject: RFR: 8328307: GenShen: Re-enable old-has-grown trigger for
 old-generation GC
In-Reply-To: <V2UNOek4Z21vTS_GBk5oi3MfJyC8hkELnTcGc-OxpGU=.09e42b4e-5b0c-493f-8292-6bf78658c553@github.com>
References: <V2UNOek4Z21vTS_GBk5oi3MfJyC8hkELnTcGc-OxpGU=.09e42b4e-5b0c-493f-8292-6bf78658c553@github.com>
Message-ID: <t8YntjQPeet6t5dZj-8eQanw15WNo8VX0EO0e2m_WpU=.6e57d042-b317-4956-a539-5cf25b9956c9@github.com>

On Mon, 18 Mar 2024 13:32:16 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

> Enable old-gen growth triggers, which were inadvertantly disabled.  This passes the internal regression pipeline tests.
> 
> As would be expected, we see an increase in mixed-evacuation triggers.  We also see significant improvement on certain extremem workloads due to improved clearing of old-gen.
> 
> 
>    Control: shenandoah-x86-template
> Experiment: enable-old-growth-triggers-gh-x86
> 
>                           Most impacted benchmarks |                              Most impacted metrics
> -------------------------------------------------------------------------------------------------------
>                            Genshen/extremem-phased |                             trigger_expedite_mixed
>                 Genshen/specjbb2015_weak_ref_patch |                                    trigger_failure
>                                Genshen/specjbb2015 |                               context_switch_count
>                     Genshen/hyperalloc_a3072_o4096 |                                     sla_25000_jops
>                             Shenandoah/specjbb2015 |                                      trigger_learn
> 
> 
>                                 Only in experiment |                                    Only in control
> -------------------------------------------------------------------------------------------------------
>      hyperalloc_a2048_o2048/trigger_expedite_mixed |                   compress/concurrent_thread_roots
>      hyperalloc_a2048_o4096/trigger_expedite_mixed |                        crypto.rsa/ctr_thread_roots
>      hyperalloc_a3072_o2048/trigger_expedite_mixed |                               crypto.rsa/ctr_total
>      hyperalloc_a3072_o4096/trigger_expedite_mixed |               extremem-large-31g/trigger_expansion
>               extremem-large-31g/trigger_overgrown |                  extremem-phased/trigger_expansion
> 
> Genshen
> -------------------------------------------------------------------------------------------------------
> +685.00% specjbb2015_weak_ref_patch/trigger_expedite_mixed p=0.00002
>   Control:      2.500   (+/-  0.68  )         30
>   Test:        19.625   (+/-  4.79  )         10
> 
> +561.90% specjbb2015/trigger_expedite_mixed p=0.00001
>   Control:      2.625   (+/-  0.92  )         30
>   Test:        17.375   (+/-  3.89  )         10
> 
> +225.42% extremem-phased/trigger_expedite_mixed p=0.00000
>   Control:      9.833   (+/-  3.48  )         30
>   Test:        32.000   (+/-  2.58  )         10
> 
> +63.84% hyperalloc_a3072_o4096/evacuation p=0.02662
>   Control:     37....

test/hotspot/jtreg/gc/shenandoah/generational/TestOldGrowthTriggers.java line 61:

> 59:         int derive_index = r.nextInt(array_size);
> 60:         switch (i & 0x3) {
> 61:           case 0:

Intended to break after each case.  Let me fix this and adjust refill iterations.

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

PR Review Comment: https://git.openjdk.org/shenandoah/pull/409#discussion_r1528974098

From kdnilsen at openjdk.org  Mon Mar 18 17:58:01 2024
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Mon, 18 Mar 2024 17:58:01 GMT
Subject: RFR: 8327097: GenShen: Align PLAB sizes down rather than up
In-Reply-To: <ubIf-lmCiowlGhyHfBvq-zudoKSzp6MWHaB9UZh5FuM=.27238aa1-a55b-4a19-9cac-e9c4de961613@github.com>
References: <ubIf-lmCiowlGhyHfBvq-zudoKSzp6MWHaB9UZh5FuM=.27238aa1-a55b-4a19-9cac-e9c4de961613@github.com>
Message-ID: <tRtzI8M-X9ao62R7xInhIGwSVpwRldbH9w-IolE1ScU=.925a0d39-20e5-4ed0-9624-b55233740edf@github.com>

On Mon, 26 Feb 2024 21:27:37 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

> When adjusting LAB sizes, round down rather than rounding up.  Otherwise, we may violate the ShenandoahHumongousThreshold bound.

test/hotspot/jtreg/ProblemList.txt line 94:

> 92: gc/TestAllocHumongousFragment.java#static 8298781 generic-all
> 93: gc/stress/gclocker/TestExcessGCLockerCollections.java 8229120 generic-all
> 94: gc/shenandoah/TestHumongousThreshold.java#default 8327000 macosx-aarch64

Disable this on generic-all until 8327000 resolved.

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

PR Review Comment: https://git.openjdk.org/shenandoah/pull/401#discussion_r1529012994

From ysr at openjdk.org  Mon Mar 18 23:50:43 2024
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Mon, 18 Mar 2024 23:50:43 GMT
Subject: RFR: 8328220: GenShen: Move generational mode operational
 parameters out of ShenandoahHeap
In-Reply-To: <g5imn_5phIV--yFo82sYN_v9FOVkO_kptTBcLV0nyHw=.dbe008e0-20f4-49bd-8e22-ec47e4947999@github.com>
References: <EFKLJAJVQOUxjmsQp2-ToB827pP0YJAUJ0AKWxQjmDk=.49cd0029-f280-40f2-bf82-8438fab02337@github.com>
 <g5imn_5phIV--yFo82sYN_v9FOVkO_kptTBcLV0nyHw=.dbe008e0-20f4-49bd-8e22-ec47e4947999@github.com>
Message-ID: <gOqJm5MYy3DnguHvlYyswkPx12Ct0P00L2ZGoFhklI4=.b686e667-a48d-4933-8ab3-038c2eabd481@github.com>

On Mon, 18 Mar 2024 23:28:31 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

>> * Many fields previously defined in `ShenandoahHeap` have been moved to `ShenandoahOldGeneration`.
>> * Generational specific serviceability has been moved to `ShenandoahGenerationalHeap`.
>> * Methods for sizing the old generation have been moved to `ShenandoahGenerationalHeap`.
>> * `ShenandoahGenerationalHeap::heap()` now asserts that the generational mode is active.
>
> src/hotspot/share/gc/shenandoah/heuristics/shenandoahOldHeuristics.cpp line 91:
> 
>> 89:   // budget is constrained by availability of free memory.
>> 90:   size_t old_evacuation_reserve = heap->old_generation()->get_evacuation_reserve();
>> 91:   size_t old_evacuation_budget = (size_t) ((double) old_evacuation_reserve / ShenandoahOldEvacWaste);
> 
> const

There may be others too that could may be be const'ed, if you could check please (I didn't check for any others). Thanks!

> src/hotspot/share/gc/shenandoah/heuristics/shenandoahYoungHeuristics.cpp line 91:
> 
>> 89:   // This is young-gen collection or a mixed evacuation.
>> 90:   // If this is mixed evacuation, the old-gen candidate regions have already been added.
>> 91:   size_t max_cset = (size_t) (heap->young_generation()->get_evacuation_reserve() / ShenandoahEvacWaste);
> 
> const

free_target and min_garbage below can also be const'd.

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

PR Review Comment: https://git.openjdk.org/shenandoah/pull/406#discussion_r1529455654
PR Review Comment: https://git.openjdk.org/shenandoah/pull/406#discussion_r1529459376

From ysr at openjdk.org  Mon Mar 18 23:50:43 2024
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Mon, 18 Mar 2024 23:50:43 GMT
Subject: RFR: 8328220: GenShen: Move generational mode operational
 parameters out of ShenandoahHeap
In-Reply-To: <EFKLJAJVQOUxjmsQp2-ToB827pP0YJAUJ0AKWxQjmDk=.49cd0029-f280-40f2-bf82-8438fab02337@github.com>
References: <EFKLJAJVQOUxjmsQp2-ToB827pP0YJAUJ0AKWxQjmDk=.49cd0029-f280-40f2-bf82-8438fab02337@github.com>
Message-ID: <g5imn_5phIV--yFo82sYN_v9FOVkO_kptTBcLV0nyHw=.dbe008e0-20f4-49bd-8e22-ec47e4947999@github.com>

On Thu, 14 Mar 2024 21:46:14 GMT, William Kemper <wkemper at openjdk.org> wrote:

> * Many fields previously defined in `ShenandoahHeap` have been moved to `ShenandoahOldGeneration`.
> * Generational specific serviceability has been moved to `ShenandoahGenerationalHeap`.
> * Methods for sizing the old generation have been moved to `ShenandoahGenerationalHeap`.
> * `ShenandoahGenerationalHeap::heap()` now asserts that the generational mode is active.

I left a few comments. Happy to take a second look in case the suggestions are used and it leads to changes substantive enough to warrant a re-review. Looks good otherwise. Thanks for this cleanup/restructure and for the very nice documentation added in places.

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

> 89:   // budget is constrained by availability of free memory.
> 90:   size_t old_evacuation_reserve = heap->old_generation()->get_evacuation_reserve();
> 91:   size_t old_evacuation_budget = (size_t) ((double) old_evacuation_reserve / ShenandoahOldEvacWaste);

const

src/hotspot/share/gc/shenandoah/heuristics/shenandoahYoungHeuristics.cpp line 82:

> 80:                                                             size_t cur_young_garbage) const {
> 81: 
> 82:   auto heap = ShenandoahGenerationalHeap::heap();

I have noticed that you "auto" in a few places but not in others (any reason why it's been done selectively? :-). Is there a more desirable end-state between the possible idiomatic alternatives?

src/hotspot/share/gc/shenandoah/heuristics/shenandoahYoungHeuristics.cpp line 91:

> 89:   // This is young-gen collection or a mixed evacuation.
> 90:   // If this is mixed evacuation, the old-gen candidate regions have already been added.
> 91:   size_t max_cset = (size_t) (heap->young_generation()->get_evacuation_reserve() / ShenandoahEvacWaste);

const

src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp line 1185:

> 1183:   // Consult old-region surplus and deficit to make adjustments to current generation capacities and availability.
> 1184:   // The generation region transfers take place after we rebuild.
> 1185:   size_t old_region_surplus = old_generation->get_region_surplus();

To my earlier comment regarding carrying two variables one for +ve and one for -ve case, it looks like this would be text book case where a single variable with sign would shrink the code to half, make it more readable and get rid of the unnecessary if-then-else.

Not sure if it's also used somewhere else or how the values are set. May be worth a separate cleanup ticket.

src/hotspot/share/gc/shenandoah/shenandoahGenerationalHeap.cpp line 120:

> 118: }
> 119: 
> 120: ShenandoahGenerationalHeap::TransferResult ShenandoahGenerationalHeap::balance_generations() {

To a related comment on signed value of surplus (or deficit, as you will), one might probably change this if its only current role is to carry the directional information (by compressing all of that information into a sign, with canonical direction based on convention). You could still use this to make logging easier, though.

src/hotspot/share/gc/shenandoah/shenandoahGenerationalHeap.cpp line 144:

> 142:       success, old_region_deficit, "old"
> 143:     };
> 144:   }

Here again, a single field with sign and a sign comparison would work fine and may be even make it more natural.

src/hotspot/share/gc/shenandoah/shenandoahGenerationalHeap.cpp line 248:

> 246: 
> 247:   old_generation()->set_region_surplus(old_region_surplus);
> 248:   old_generation()->set_region_deficit(old_region_deficit);

We could just do a single signed quantity here. Not sure if the computation of the surplus/deficit could be simplified. Likely not.

src/hotspot/share/gc/shenandoah/shenandoahOldGeneration.hpp line 45:

> 43:   // be positive simultaneously.
> 44:   size_t _region_surplus;
> 45:   size_t _region_deficit;

This is an excellent comment and begs the question whether having an ssize_t to halve the representable range but carrying the surplus/deficit information as a sign would be better or worse for any reason. One variable is better than two is an argument in favor of one variable, but there may be reasons to need the greater range or problems with manipulating these where they are used?

src/hotspot/share/gc/shenandoah/shenandoahOldGeneration.hpp line 52:

> 50: 
> 51:   // Bytes reserved within old-gen to hold the results of promotion. This is separate from
> 52:   // and in addition to the evacuation reserve for intra-generation evacuations.

Is there a name for "evacuation reserve for intra-generational evacuation in old"? If so, let's reference that field/variable here by its name?

src/hotspot/share/gc/shenandoah/shenandoahOldGeneration.hpp line 102:

> 100: 
> 101:   // This is used to return unused memory from a retired promotion LAB
> 102:   size_t unexpend_promoted(size_t decrement);

May be mention in the `expend_promoted` comment that the accounting expends forward the space for an entire PLAB when its allocated, but "unexpends" any unused portion thereof when the PLAB is retired.

What this tells me is that `_promoted_expended` is non-monotonic in the evacuation phase as we expend and unexpend, which means that checks against promoted reserve might also be subject to "flickering" a bit during the latter phases of evacuation.

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

Marked as reviewed by ysr (Committer).

PR Review: https://git.openjdk.org/shenandoah/pull/406#pullrequestreview-1944394753
PR Review Comment: https://git.openjdk.org/shenandoah/pull/406#discussion_r1529453330
PR Review Comment: https://git.openjdk.org/shenandoah/pull/406#discussion_r1529456625
PR Review Comment: https://git.openjdk.org/shenandoah/pull/406#discussion_r1529457610
PR Review Comment: https://git.openjdk.org/shenandoah/pull/406#discussion_r1529449570
PR Review Comment: https://git.openjdk.org/shenandoah/pull/406#discussion_r1529469015
PR Review Comment: https://git.openjdk.org/shenandoah/pull/406#discussion_r1529450374
PR Review Comment: https://git.openjdk.org/shenandoah/pull/406#discussion_r1529452293
PR Review Comment: https://git.openjdk.org/shenandoah/pull/406#discussion_r1529410676
PR Review Comment: https://git.openjdk.org/shenandoah/pull/406#discussion_r1529413788
PR Review Comment: https://git.openjdk.org/shenandoah/pull/406#discussion_r1529442124

From ysr at openjdk.org  Tue Mar 19 00:05:47 2024
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Tue, 19 Mar 2024 00:05:47 GMT
Subject: RFR: 8328126: GenShen: Reduce verbosity of logging for satb mode
In-Reply-To: <6VP789upiihNbveBH6smGkdpmrmYWGjg8lWre00dWSo=.8b2471cc-e92e-4f8b-a41d-626cb482b09b@github.com>
References: <6VP789upiihNbveBH6smGkdpmrmYWGjg8lWre00dWSo=.8b2471cc-e92e-4f8b-a41d-626cb482b09b@github.com>
Message-ID: <t2UUZf1E-N4B-l-Pl9ZbtVLZvUQJ9ctQOyfBC9RNV_8=.987c8ee0-1d2f-4d61-a567-bf29cd9980d7@github.com>

On Wed, 13 Mar 2024 20:21:54 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

> Only dump collection-set details if Debug logging is enabled.  With this change, generational-mode and satb-mode logging will match in this regard.

LGTM... Thanks for finding and fixing this issue!

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

Marked as reviewed by ysr (Committer).

PR Review: https://git.openjdk.org/shenandoah/pull/405#pullrequestreview-1944572953

From wkemper at openjdk.org  Tue Mar 19 00:12:32 2024
From: wkemper at openjdk.org (William Kemper)
Date: Tue, 19 Mar 2024 00:12:32 GMT
Subject: RFR: 8328220: GenShen: Move generational mode operational
 parameters out of ShenandoahHeap
In-Reply-To: <g5imn_5phIV--yFo82sYN_v9FOVkO_kptTBcLV0nyHw=.dbe008e0-20f4-49bd-8e22-ec47e4947999@github.com>
References: <EFKLJAJVQOUxjmsQp2-ToB827pP0YJAUJ0AKWxQjmDk=.49cd0029-f280-40f2-bf82-8438fab02337@github.com>
 <g5imn_5phIV--yFo82sYN_v9FOVkO_kptTBcLV0nyHw=.dbe008e0-20f4-49bd-8e22-ec47e4947999@github.com>
Message-ID: <pZIUUQoD40HldN8PusdlmKF9mGeH_j47JLyR7P7aX7g=.b6df321b-224d-4f03-9301-a9455068fc12@github.com>

On Mon, 18 Mar 2024 23:33:03 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

>> * Many fields previously defined in `ShenandoahHeap` have been moved to `ShenandoahOldGeneration`.
>> * Generational specific serviceability has been moved to `ShenandoahGenerationalHeap`.
>> * Methods for sizing the old generation have been moved to `ShenandoahGenerationalHeap`.
>> * `ShenandoahGenerationalHeap::heap()` now asserts that the generational mode is active.
>
> src/hotspot/share/gc/shenandoah/heuristics/shenandoahYoungHeuristics.cpp line 82:
> 
>> 80:                                                             size_t cur_young_garbage) const {
>> 81: 
>> 82:   auto heap = ShenandoahGenerationalHeap::heap();
> 
> I have noticed that you "auto" in a few places but not in others (any reason why it's been done selectively? :-). Is there a more desirable end-state between the possible idiomatic alternatives?

It should mostly be in places where I wanted the declared type to be `ShenandoahGenerationalHeap`.

> src/hotspot/share/gc/shenandoah/shenandoahOldGeneration.hpp line 45:
> 
>> 43:   // be positive simultaneously.
>> 44:   size_t _region_surplus;
>> 45:   size_t _region_deficit;
> 
> This is an excellent comment and begs the question whether having an ssize_t to halve the representable range but carrying the surplus/deficit information as a sign would be better or worse for any reason. One variable is better than two is an argument in favor of one variable, but there may be reasons to need the greater range or problems with manipulating these where they are used?

Yes, I thought about that, but it seemed to invasive for this change.

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

PR Review Comment: https://git.openjdk.org/shenandoah/pull/406#discussion_r1529490128
PR Review Comment: https://git.openjdk.org/shenandoah/pull/406#discussion_r1529487674

From kdnilsen at openjdk.org  Tue Mar 19 00:16:43 2024
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Tue, 19 Mar 2024 00:16:43 GMT
Subject: Integrated: 8328126: GenShen: Reduce verbosity of logging for satb
 mode
In-Reply-To: <6VP789upiihNbveBH6smGkdpmrmYWGjg8lWre00dWSo=.8b2471cc-e92e-4f8b-a41d-626cb482b09b@github.com>
References: <6VP789upiihNbveBH6smGkdpmrmYWGjg8lWre00dWSo=.8b2471cc-e92e-4f8b-a41d-626cb482b09b@github.com>
Message-ID: <4Lt5hyRVFKLjVoNwUE1u1SokRbp1Z2--PpucZwPRBOo=.423587fb-89c2-4a8e-8bca-93dc2f438c76@github.com>

On Wed, 13 Mar 2024 20:21:54 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

> Only dump collection-set details if Debug logging is enabled.  With this change, generational-mode and satb-mode logging will match in this regard.

This pull request has now been integrated.

Changeset: db95e35e
Author:    Kelvin Nilsen <kdnilsen at openjdk.org>
URL:       https://git.openjdk.org/shenandoah/commit/db95e35e73992f01431e2844fe4cbff248f67c8c
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8328126: GenShen: Reduce verbosity of logging for satb mode

Reviewed-by: wkemper, ysr

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

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

From kdnilsen at openjdk.org  Tue Mar 19 13:16:12 2024
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Tue, 19 Mar 2024 13:16:12 GMT
Subject: RFR: 8327097: GenShen: Align PLAB sizes down rather than up [v2]
In-Reply-To: <ubIf-lmCiowlGhyHfBvq-zudoKSzp6MWHaB9UZh5FuM=.27238aa1-a55b-4a19-9cac-e9c4de961613@github.com>
References: <ubIf-lmCiowlGhyHfBvq-zudoKSzp6MWHaB9UZh5FuM=.27238aa1-a55b-4a19-9cac-e9c4de961613@github.com>
Message-ID: <UxUkTyKhBnOzZX-8zLEGJyMp_-XmOUAj0LETLO_rg7Q=.199104a5-caad-4c3a-8c9b-a996d1a2f1af@github.com>

> When adjusting LAB sizes, round down rather than rounding up.  Otherwise, we may violate the ShenandoahHumongousThreshold bound.

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

 - Add comment to explain requirement for PLAB alignment
 - Assure PLAB alignment by construction rather than fixup

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

Changes:
  - all: https://git.openjdk.org/shenandoah/pull/401/files
  - new: https://git.openjdk.org/shenandoah/pull/401/files/3aba4303..1ae9b1c4

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

  Stats: 39 lines in 3 files changed: 27 ins; 5 del; 7 mod
  Patch: https://git.openjdk.org/shenandoah/pull/401.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah.git pull/401/head:pull/401

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

From kdnilsen at openjdk.org  Tue Mar 19 13:23:35 2024
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Tue, 19 Mar 2024 13:23:35 GMT
Subject: RFR: 8327097: GenShen: Align PLAB sizes down rather than up [v2]
In-Reply-To: <mWLjI1Jn_8Pvc45ufglRPgd1RNnPci9KmKcfXorxm6M=.29a39f66-f7cf-4e87-b760-88a8802360d0@github.com>
References: <ubIf-lmCiowlGhyHfBvq-zudoKSzp6MWHaB9UZh5FuM=.27238aa1-a55b-4a19-9cac-e9c4de961613@github.com>
 <eXK3thsHz9Yiil_Sd00EMQ3mgel01QLbxZo4e6NAezQ=.7865b9a4-649b-41dd-ad69-9f5921aec328@github.com>
 <A0S4fIqHFmrNs_fJQkQdAAca9pCqaEJGymYbD0f9Giw=.d7bce5e4-1bb2-478c-8896-f12b1d119710@github.com>
 <mWLjI1Jn_8Pvc45ufglRPgd1RNnPci9KmKcfXorxm6M=.29a39f66-f7cf-4e87-b760-88a8802360d0@github.com>
Message-ID: <PaK3FqenF55IW2po4utDq6RjRaqg5WQ8Ry1z7vQ3O3k=.b2b2aa45-d39c-43a1-9eb2-04e366613f10@github.com>

On Fri, 8 Mar 2024 00:50:30 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

>> We also need a comment somewhere stating why we need these to be card-aligned.
>> 
>> I wonder also if this is entirely correct in itself, unless the shared allocation itself also always leaves us with a card-aligned top from which these PLABs are allocated.
>> 
>> In particular, it would be good to assert that `allocate_new_plab()` always gives us back a card-aligned start address.
>> 
>> Would be good to also use `align_up` or `align_down` in `allocate_new_plab()` as well. Indeed, it might be a good idea to do so in any code in Shenandoah where we are unnecessarily rolling our own custom alignment code.
>
> There's also a couple of assertion checks in `ShenandoahFreeSet::allocate_aligned_plab()` that use the modulus operation, which should probably use `is_aligned()` instead.
> 
> Would be good to clean those up as well while we are taking care of this.

Thanks for these suggestions.  I believe I have addressed each in the newest rev of the code.

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

PR Review Comment: https://git.openjdk.org/shenandoah/pull/401#discussion_r1530356387

From eosterlund at openjdk.org  Tue Mar 19 13:44:28 2024
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Tue, 19 Mar 2024 13:44:28 GMT
Subject: RFR: 8328507: Move StackWatermark code from safepoint cleanup
Message-ID: <KfeqCRDfFUvcktwgMdsAJue9YLYs59GmcD8tZkgbFfE=.ab777a29-cdaa-4249-9b92-4b3338954017@github.com>

There is some stack watermark code in safepoint cleanup that flushes out concurrent stack processing, as a defensive measure to guard safepoint operations that assume the stacks have been fixed up. However, we wish to get rid of safepoint cleanup so this operation should move out from the safepoint. This proposal moves it into CollectedHeap::safepoint_synchronize_begin instead which runs before we start shutting down Java threads. This moves the code into more obvious GC places and reduces time spent inside of non-GC safepoints.

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

Commit messages:
 - 8328507: Move StackWatermark code from safepoint cleanup

Changes: https://git.openjdk.org/jdk/pull/18378/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18378&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8328507
  Stats: 75 lines in 11 files changed: 23 ins; 44 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/18378.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18378/head:pull/18378

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

From kdnilsen at openjdk.org  Tue Mar 19 13:47:15 2024
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Tue, 19 Mar 2024 13:47:15 GMT
Subject: RFR: 8327097: GenShen: Align PLAB sizes down rather than up [v3]
In-Reply-To: <ubIf-lmCiowlGhyHfBvq-zudoKSzp6MWHaB9UZh5FuM=.27238aa1-a55b-4a19-9cac-e9c4de961613@github.com>
References: <ubIf-lmCiowlGhyHfBvq-zudoKSzp6MWHaB9UZh5FuM=.27238aa1-a55b-4a19-9cac-e9c4de961613@github.com>
Message-ID: <APOXOZ6Cn4zA1-piez9NZafUh6FMCtFUtcTIhovvmDU=.89b68746-22cb-48c6-b974-bd87525be35c@github.com>

> When adjusting LAB sizes, round down rather than rounding up.  Otherwise, we may violate the ShenandoahHumongousThreshold bound.

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

 - Disable TestHumongousThreshold test on generic-all for now
   
   This has experienced timeout failures on multiple platforms.
 - Cleanup code in response to reviewer feedback

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

Changes:
  - all: https://git.openjdk.org/shenandoah/pull/401/files
  - new: https://git.openjdk.org/shenandoah/pull/401/files/1ae9b1c4..e094aa03

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

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

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

From kdnilsen at openjdk.org  Tue Mar 19 13:47:16 2024
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Tue, 19 Mar 2024 13:47:16 GMT
Subject: RFR: 8327097: GenShen: Align PLAB sizes down rather than up [v2]
In-Reply-To: <UxUkTyKhBnOzZX-8zLEGJyMp_-XmOUAj0LETLO_rg7Q=.199104a5-caad-4c3a-8c9b-a996d1a2f1af@github.com>
References: <ubIf-lmCiowlGhyHfBvq-zudoKSzp6MWHaB9UZh5FuM=.27238aa1-a55b-4a19-9cac-e9c4de961613@github.com>
 <UxUkTyKhBnOzZX-8zLEGJyMp_-XmOUAj0LETLO_rg7Q=.199104a5-caad-4c3a-8c9b-a996d1a2f1af@github.com>
Message-ID: <nIkQxlL8bbBSEZQI9c6ObNlu3s5G4fX5L_-Sl3BxnJ8=.053c5451-4e40-4a89-8e92-0977ef810464@github.com>

On Tue, 19 Mar 2024 13:16:12 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> When adjusting LAB sizes, round down rather than rounding up.  Otherwise, we may violate the ShenandoahHumongousThreshold bound.
>
> Kelvin Nilsen has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Add comment to explain requirement for PLAB alignment
>  - Assure PLAB alignment by construction rather than fixup

I have made the suggested changes to ShenandoahHeap::allocate_new_plab() and ShenandoahFreeSet::allocate_aligned_plab()

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

PR Comment: https://git.openjdk.org/shenandoah/pull/401#issuecomment-2007220479

From kdnilsen at openjdk.org  Tue Mar 19 13:47:18 2024
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Tue, 19 Mar 2024 13:47:18 GMT
Subject: RFR: 8327097: GenShen: Align PLAB sizes down rather than up [v3]
In-Reply-To: <tRtzI8M-X9ao62R7xInhIGwSVpwRldbH9w-IolE1ScU=.925a0d39-20e5-4ed0-9624-b55233740edf@github.com>
References: <ubIf-lmCiowlGhyHfBvq-zudoKSzp6MWHaB9UZh5FuM=.27238aa1-a55b-4a19-9cac-e9c4de961613@github.com>
 <tRtzI8M-X9ao62R7xInhIGwSVpwRldbH9w-IolE1ScU=.925a0d39-20e5-4ed0-9624-b55233740edf@github.com>
Message-ID: <R0W8rDgi0RrrXVhzal7t9BN0CpISL-4GbBzdR1yOor0=.bd4daad0-2793-4cc6-a4fe-ecae94205bad@github.com>

On Mon, 18 Mar 2024 17:55:15 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> Kelvin Nilsen has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Disable TestHumongousThreshold test on generic-all for now
>>    
>>    This has experienced timeout failures on multiple platforms.
>>  - Cleanup code in response to reviewer feedback
>
> test/hotspot/jtreg/ProblemList.txt line 94:
> 
>> 92: gc/TestAllocHumongousFragment.java#static 8298781 generic-all
>> 93: gc/stress/gclocker/TestExcessGCLockerCollections.java 8229120 generic-all
>> 94: gc/shenandoah/TestHumongousThreshold.java#default 8327000 macosx-aarch64
> 
> Disable this on generic-all until 8327000 resolved.

Done

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

PR Review Comment: https://git.openjdk.org/shenandoah/pull/401#discussion_r1530397373

From aboldtch at openjdk.org  Tue Mar 19 13:50:20 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Tue, 19 Mar 2024 13:50:20 GMT
Subject: RFR: 8328507: Move StackWatermark code from safepoint cleanup
In-Reply-To: <KfeqCRDfFUvcktwgMdsAJue9YLYs59GmcD8tZkgbFfE=.ab777a29-cdaa-4249-9b92-4b3338954017@github.com>
References: <KfeqCRDfFUvcktwgMdsAJue9YLYs59GmcD8tZkgbFfE=.ab777a29-cdaa-4249-9b92-4b3338954017@github.com>
Message-ID: <YtXAg2bGtEY-Las67l6hEYMkN7N3xUxsuZ1KL0BLatE=.9bd60df1-343b-48c2-81ee-5bce3558ad9c@github.com>

On Tue, 19 Mar 2024 13:30:39 GMT, Erik ?sterlund <eosterlund at openjdk.org> wrote:

> There is some stack watermark code in safepoint cleanup that flushes out concurrent stack processing, as a defensive measure to guard safepoint operations that assume the stacks have been fixed up. However, we wish to get rid of safepoint cleanup so this operation should move out from the safepoint. This proposal moves it into CollectedHeap::safepoint_synchronize_begin instead which runs before we start shutting down Java threads. This moves the code into more obvious GC places and reduces time spent inside of non-GC safepoints.

lgtm.

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

Marked as reviewed by aboldtch (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18378#pullrequestreview-1946285372

From eosterlund at openjdk.org  Tue Mar 19 14:41:33 2024
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Tue, 19 Mar 2024 14:41:33 GMT
Subject: RFR: 8328507: Move StackWatermark code from safepoint cleanup [v2]
In-Reply-To: <KfeqCRDfFUvcktwgMdsAJue9YLYs59GmcD8tZkgbFfE=.ab777a29-cdaa-4249-9b92-4b3338954017@github.com>
References: <KfeqCRDfFUvcktwgMdsAJue9YLYs59GmcD8tZkgbFfE=.ab777a29-cdaa-4249-9b92-4b3338954017@github.com>
Message-ID: <LMUQuZEpeCPn_xdm329qS6K86GSx4T2l_jl2tWuVtuk=.f654c2f0-ddd1-488e-8535-e4f22e75a679@github.com>

> There is some stack watermark code in safepoint cleanup that flushes out concurrent stack processing, as a defensive measure to guard safepoint operations that assume the stacks have been fixed up. However, we wish to get rid of safepoint cleanup so this operation should move out from the safepoint. This proposal moves it into CollectedHeap::safepoint_synchronize_begin instead which runs before we start shutting down Java threads. This moves the code into more obvious GC places and reduces time spent inside of non-GC safepoints.

Erik ?sterlund has updated the pull request incrementally with one additional commit since the last revision:

  Remove incorrect assert

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18378/files
  - new: https://git.openjdk.org/jdk/pull/18378/files/f18381c8..e830146a

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

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

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

From wkemper at openjdk.org  Tue Mar 19 15:05:51 2024
From: wkemper at openjdk.org (William Kemper)
Date: Tue, 19 Mar 2024 15:05:51 GMT
Subject: RFR: 8328220: GenShen: Move generational mode operational
 parameters out of ShenandoahHeap
In-Reply-To: <g5imn_5phIV--yFo82sYN_v9FOVkO_kptTBcLV0nyHw=.dbe008e0-20f4-49bd-8e22-ec47e4947999@github.com>
References: <EFKLJAJVQOUxjmsQp2-ToB827pP0YJAUJ0AKWxQjmDk=.49cd0029-f280-40f2-bf82-8438fab02337@github.com>
 <g5imn_5phIV--yFo82sYN_v9FOVkO_kptTBcLV0nyHw=.dbe008e0-20f4-49bd-8e22-ec47e4947999@github.com>
Message-ID: <ykSBhMYW6ekIo5Lf81QblhjyX3f3Gt-LoNNikp6P97I=.d587484d-00e9-4f44-9736-0326ed2da153@github.com>

On Mon, 18 Mar 2024 23:17:43 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

>> * Many fields previously defined in `ShenandoahHeap` have been moved to `ShenandoahOldGeneration`.
>> * Generational specific serviceability has been moved to `ShenandoahGenerationalHeap`.
>> * Methods for sizing the old generation have been moved to `ShenandoahGenerationalHeap`.
>> * `ShenandoahGenerationalHeap::heap()` now asserts that the generational mode is active.
>
> src/hotspot/share/gc/shenandoah/shenandoahOldGeneration.hpp line 102:
> 
>> 100: 
>> 101:   // This is used to return unused memory from a retired promotion LAB
>> 102:   size_t unexpend_promoted(size_t decrement);
> 
> May be mention in the `expend_promoted` comment that the accounting expends forward the space for an entire PLAB when its allocated, but "unexpends" any unused portion thereof when the PLAB is retired.
> 
> What this tells me is that `_promoted_expended` is non-monotonic in the evacuation phase as we expend and unexpend, which means that checks against promoted reserve might also be subject to "flickering" a bit during the latter phases of evacuation.

I've added a comment to the field these methods operate on.

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

PR Review Comment: https://git.openjdk.org/shenandoah/pull/406#discussion_r1530568771

From wkemper at openjdk.org  Tue Mar 19 16:40:13 2024
From: wkemper at openjdk.org (William Kemper)
Date: Tue, 19 Mar 2024 16:40:13 GMT
Subject: RFR: 8328220: GenShen: Move generational mode operational
 parameters out of ShenandoahHeap [v2]
In-Reply-To: <EFKLJAJVQOUxjmsQp2-ToB827pP0YJAUJ0AKWxQjmDk=.49cd0029-f280-40f2-bf82-8438fab02337@github.com>
References: <EFKLJAJVQOUxjmsQp2-ToB827pP0YJAUJ0AKWxQjmDk=.49cd0029-f280-40f2-bf82-8438fab02337@github.com>
Message-ID: <L4DuYk-qtXq9qHRCmD9k31ettQWvU_9t0t8QxHeLMaQ=.e9ff032f-eece-4f9c-aa01-e6001ca27051@github.com>

> * Many fields previously defined in `ShenandoahHeap` have been moved to `ShenandoahOldGeneration`.
> * Generational specific serviceability has been moved to `ShenandoahGenerationalHeap`.
> * Methods for sizing the old generation have been moved to `ShenandoahGenerationalHeap`.
> * `ShenandoahGenerationalHeap::heap()` now asserts that the generational mode is active.

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

  Improve comments, make more variables const.

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

Changes:
  - all: https://git.openjdk.org/shenandoah/pull/406/files
  - new: https://git.openjdk.org/shenandoah/pull/406/files/00f8778b..375f1434

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

  Stats: 55 lines in 4 files changed: 4 ins; 9 del; 42 mod
  Patch: https://git.openjdk.org/shenandoah/pull/406.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah.git pull/406/head:pull/406

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

From kdnilsen at openjdk.org  Tue Mar 19 16:41:49 2024
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Tue, 19 Mar 2024 16:41:49 GMT
Subject: RFR: 8327097: GenShen: Align PLAB sizes down rather than up [v4]
In-Reply-To: <ubIf-lmCiowlGhyHfBvq-zudoKSzp6MWHaB9UZh5FuM=.27238aa1-a55b-4a19-9cac-e9c4de961613@github.com>
References: <ubIf-lmCiowlGhyHfBvq-zudoKSzp6MWHaB9UZh5FuM=.27238aa1-a55b-4a19-9cac-e9c4de961613@github.com>
Message-ID: <GlnW_nbwQYnvZ5yoFZL33MGxc6gGwW9rYNKTOkPAmCc=.4249df96-4493-47b5-8787-fa9e28bcd6a4@github.com>

> When adjusting LAB sizes, round down rather than rounding up.  Otherwise, we may violate the ShenandoahHumongousThreshold bound.

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

  Force size to align up
  
  A newly allocated PLAB needs, at minimum, to be as large as the object
  that is goign to be allocated from within it.

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

Changes:
  - all: https://git.openjdk.org/shenandoah/pull/401/files
  - new: https://git.openjdk.org/shenandoah/pull/401/files/e094aa03..5de18812

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

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

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

From ysr at openjdk.org  Tue Mar 19 20:13:49 2024
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Tue, 19 Mar 2024 20:13:49 GMT
Subject: RFR: 8328220: GenShen: Move generational mode operational
 parameters out of ShenandoahHeap [v2]
In-Reply-To: <pZIUUQoD40HldN8PusdlmKF9mGeH_j47JLyR7P7aX7g=.b6df321b-224d-4f03-9301-a9455068fc12@github.com>
References: <EFKLJAJVQOUxjmsQp2-ToB827pP0YJAUJ0AKWxQjmDk=.49cd0029-f280-40f2-bf82-8438fab02337@github.com>
 <g5imn_5phIV--yFo82sYN_v9FOVkO_kptTBcLV0nyHw=.dbe008e0-20f4-49bd-8e22-ec47e4947999@github.com>
 <pZIUUQoD40HldN8PusdlmKF9mGeH_j47JLyR7P7aX7g=.b6df321b-224d-4f03-9301-a9455068fc12@github.com>
Message-ID: <eF5S1mBXmKMNop7Haca-q8n9U-_Odq9sO-EKcKNDToo=.7fe83d10-37f2-4669-aed4-8f8e35744270@github.com>

On Tue, 19 Mar 2024 00:10:14 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> src/hotspot/share/gc/shenandoah/heuristics/shenandoahYoungHeuristics.cpp line 82:
>> 
>>> 80:                                                             size_t cur_young_garbage) const {
>>> 81: 
>>> 82:   auto heap = ShenandoahGenerationalHeap::heap();
>> 
>> I have noticed that you "auto" in a few places but not in others (any reason why it's been done selectively? :-). Is there a more desirable end-state between the possible idiomatic alternatives?
>
> It should mostly be in places where I wanted the declared type to be `ShenandoahGenerationalHeap`.

ok thanks that makes sense.

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

PR Review Comment: https://git.openjdk.org/shenandoah/pull/406#discussion_r1531033927

From ysr at openjdk.org  Tue Mar 19 20:16:42 2024
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Tue, 19 Mar 2024 20:16:42 GMT
Subject: RFR: 8328220: GenShen: Move generational mode operational
 parameters out of ShenandoahHeap [v2]
In-Reply-To: <L4DuYk-qtXq9qHRCmD9k31ettQWvU_9t0t8QxHeLMaQ=.e9ff032f-eece-4f9c-aa01-e6001ca27051@github.com>
References: <EFKLJAJVQOUxjmsQp2-ToB827pP0YJAUJ0AKWxQjmDk=.49cd0029-f280-40f2-bf82-8438fab02337@github.com>
 <L4DuYk-qtXq9qHRCmD9k31ettQWvU_9t0t8QxHeLMaQ=.e9ff032f-eece-4f9c-aa01-e6001ca27051@github.com>
Message-ID: <YSR5s9vfYMyk2rrGzhipa8M-P-7_2F3V1mhNpuU7Axc=.cef224fe-4f1f-4151-b1c7-5ba47eda1262@github.com>

On Tue, 19 Mar 2024 16:40:13 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> * Many fields previously defined in `ShenandoahHeap` have been moved to `ShenandoahOldGeneration`.
>> * Generational specific serviceability has been moved to `ShenandoahGenerationalHeap`.
>> * Methods for sizing the old generation have been moved to `ShenandoahGenerationalHeap`.
>> * `ShenandoahGenerationalHeap::heap()` now asserts that the generational mode is active.
>
> William Kemper has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improve comments, make more variables const.

Rereviewed; thanks for taking care of the feedback!

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

Marked as reviewed by ysr (Committer).

PR Review: https://git.openjdk.org/shenandoah/pull/406#pullrequestreview-1947290769

From wkemper at openjdk.org  Tue Mar 19 21:06:41 2024
From: wkemper at openjdk.org (William Kemper)
Date: Tue, 19 Mar 2024 21:06:41 GMT
Subject: RFR: 8328220: GenShen: Move generational mode operational
 parameters out of ShenandoahHeap [v2]
In-Reply-To: <g5imn_5phIV--yFo82sYN_v9FOVkO_kptTBcLV0nyHw=.dbe008e0-20f4-49bd-8e22-ec47e4947999@github.com>
References: <EFKLJAJVQOUxjmsQp2-ToB827pP0YJAUJ0AKWxQjmDk=.49cd0029-f280-40f2-bf82-8438fab02337@github.com>
 <g5imn_5phIV--yFo82sYN_v9FOVkO_kptTBcLV0nyHw=.dbe008e0-20f4-49bd-8e22-ec47e4947999@github.com>
Message-ID: <FCC-XVE3U-8y7CPZAIitGiIwEBgtRRSFWmnMhJ2SXWY=.d25e997d-45cb-4483-acf9-29d05b1e58fd@github.com>

On Mon, 18 Mar 2024 23:44:01 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

>> William Kemper has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Improve comments, make more variables const.
>
> src/hotspot/share/gc/shenandoah/shenandoahGenerationalHeap.cpp line 120:
> 
>> 118: }
>> 119: 
>> 120: ShenandoahGenerationalHeap::TransferResult ShenandoahGenerationalHeap::balance_generations() {
> 
> To a related comment on signed value of surplus (or deficit, as you will), one might probably change this if its only current role is to carry the directional information (by compressing all of that information into a sign, with canonical direction based on convention). You could still use this to make logging easier, though.

I'll pick up the surplus/deficit change in a subsequent PR.

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

PR Review Comment: https://git.openjdk.org/shenandoah/pull/406#discussion_r1531112442

From wkemper at openjdk.org  Tue Mar 19 21:06:42 2024
From: wkemper at openjdk.org (William Kemper)
Date: Tue, 19 Mar 2024 21:06:42 GMT
Subject: Integrated: 8328220: GenShen: Move generational mode operational
 parameters out of ShenandoahHeap
In-Reply-To: <EFKLJAJVQOUxjmsQp2-ToB827pP0YJAUJ0AKWxQjmDk=.49cd0029-f280-40f2-bf82-8438fab02337@github.com>
References: <EFKLJAJVQOUxjmsQp2-ToB827pP0YJAUJ0AKWxQjmDk=.49cd0029-f280-40f2-bf82-8438fab02337@github.com>
Message-ID: <hi5Rp0hWg2BIB7EcQm_wQjOdIKw-Ml2Ypf56fwr8YTA=.7e3591c8-4d2a-4b68-a58b-881888f509cf@github.com>

On Thu, 14 Mar 2024 21:46:14 GMT, William Kemper <wkemper at openjdk.org> wrote:

> * Many fields previously defined in `ShenandoahHeap` have been moved to `ShenandoahOldGeneration`.
> * Generational specific serviceability has been moved to `ShenandoahGenerationalHeap`.
> * Methods for sizing the old generation have been moved to `ShenandoahGenerationalHeap`.
> * `ShenandoahGenerationalHeap::heap()` now asserts that the generational mode is active.

This pull request has now been integrated.

Changeset: 71fc4c81
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.org/shenandoah/commit/71fc4c810e6f2578980c85c7c3dbed2157fb1ef3
Stats:     1463 lines in 24 files changed: 650 ins; 670 del; 143 mod

8328220: GenShen: Move generational mode operational parameters out of ShenandoahHeap

Reviewed-by: kdnilsen, ysr

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

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

From ysr at openjdk.org  Wed Mar 20 10:21:12 2024
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Wed, 20 Mar 2024 10:21:12 GMT
Subject: RFR: 8328235: GenShen: Robustify ShenandoahGCSession and fix
 missing use
In-Reply-To: <ViHIdrG0sja7rFJOMLnOkso6t--zQrnoQSnsrkLz4B0=.859112c8-2064-4a51-912c-0ce5667af37d@github.com>
References: <ViHIdrG0sja7rFJOMLnOkso6t--zQrnoQSnsrkLz4B0=.859112c8-2064-4a51-912c-0ce5667af37d@github.com>
Message-ID: <m8Tp_YOJb1nHgEOJCWhZLfMk_yw3fe2QOuvQIt5u3YA=.8cea7cf9-f80d-4d93-a857-f30420ed6281@github.com>

On Fri, 15 Mar 2024 01:45:51 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

> ShenandoahGCSession is intended to create a scope where the ShenandoahHeap's _gc_cause and _gc_generation field reflect the current gc cycle. We now check that we do not overwrite existing non-default settings (respectively _no_gc and nullptr). The destructor of the scope/stack object also resets these fields to their default settings, ensuring intended uses. This uncovered a situation where the scope was not entered when it should have been, which we have now fixed. A case of flickering of active_generation() was identified, and found to be benign. An assert now checks for this situation. The code has been made robust wrt the flickering (seen only by mutators executing load barriers).
> 
> *Testing*:
> - [ ] code pipeline : in progress
> - [x] specjbb
> - [x] jtreg:hotspot_gc w/fastdebug
> - [x] GHA: existing failures unrelated to this change

A case of flickering of active_generation() was identified, and found to be benign. An assert now checks for this situation. The code has been made robust wrt the flickering.

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

PR Comment: https://git.openjdk.org/shenandoah/pull/407#issuecomment-2009203885

From ysr at openjdk.org  Wed Mar 20 10:21:11 2024
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Wed, 20 Mar 2024 10:21:11 GMT
Subject: RFR: 8328235: GenShen: Robustify ShenandoahGCSession and fix
 missing use [v2]
In-Reply-To: <ViHIdrG0sja7rFJOMLnOkso6t--zQrnoQSnsrkLz4B0=.859112c8-2064-4a51-912c-0ce5667af37d@github.com>
References: <ViHIdrG0sja7rFJOMLnOkso6t--zQrnoQSnsrkLz4B0=.859112c8-2064-4a51-912c-0ce5667af37d@github.com>
Message-ID: <ypVZMdCjy119ULVp1pMTnlHIlV7czno82A3ruIh9ABE=.3e97d621-c3f1-4fe6-8fff-8cbf77c27164@github.com>

> ShenandoahGCSession is intended to create a scope where the ShenandoahHeap's _gc_cause and _gc_generation field reflect the current gc cycle. We now check that we do not overwrite existing non-default settings (respectively _no_gc and nullptr). The destructor of the scope/stack object also resets these fields to their default settings, ensuring intended uses. This uncovered a situation where the scope was not entered when it should have been, which we have now fixed. A case of flickering of active_generation() was identified, and found to be benign. An assert now checks for this situation. The code has been made robust wrt the flickering (seen only by mutators executing load barriers).
> 
> *Testing*:
> - [ ] code pipeline : in progress
> - [x] specjbb
> - [x] jtreg:hotspot_gc w/fastdebug
> - [x] GHA: existing failures unrelated to this change

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

 - Refine assertion further & modify comment block.
 - Merge branch 'master' into active_generation
 - jcheck cleanup.
 - Weaken assertion so it passes for now; add comment.
 - Clean up assertion checking for race.
 - Read active_generetion() only once in is_is_active_generation() to work
   around potential flicker; interlocking reads to detect flicker. Need
   better checks.
 - Robustify ShenandoahGCSession, and fix a missing use for
   coalesce_and_fill of old gen.

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

Changes:
  - all: https://git.openjdk.org/shenandoah/pull/407/files
  - new: https://git.openjdk.org/shenandoah/pull/407/files/6663406a..a86d3edd

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

  Stats: 1488 lines in 24 files changed: 668 ins; 670 del; 150 mod
  Patch: https://git.openjdk.org/shenandoah/pull/407.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah.git pull/407/head:pull/407

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

From kdnilsen at openjdk.org  Wed Mar 20 18:52:59 2024
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Wed, 20 Mar 2024 18:52:59 GMT
Subject: RFR: 8327097: GenShen: Align PLAB sizes down rather than up [v5]
In-Reply-To: <ubIf-lmCiowlGhyHfBvq-zudoKSzp6MWHaB9UZh5FuM=.27238aa1-a55b-4a19-9cac-e9c4de961613@github.com>
References: <ubIf-lmCiowlGhyHfBvq-zudoKSzp6MWHaB9UZh5FuM=.27238aa1-a55b-4a19-9cac-e9c4de961613@github.com>
Message-ID: <rYH2XnCxn5jX4r9oTWLVJTtPv9fXBsFdQsAJbvTlcxw=.2cff7c06-9143-4072-8529-d90c1dc825b4@github.com>

> When adjusting LAB sizes, round down rather than rounding up.  Otherwise, we may violate the ShenandoahHumongousThreshold bound.

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

  Do not align_up size of object allocated in plab slow
  
  Align the plab size, but not the size of the object to be allocated within the plab.
  If we increase the size of the allocated object, this creates confusion in that the
  object's size reported by its header does not span all of the bytes allocated for the
  object, so the memory is not parsable during remembered set scanning.

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

Changes:
  - all: https://git.openjdk.org/shenandoah/pull/401/files
  - new: https://git.openjdk.org/shenandoah/pull/401/files/5de18812..45695f04

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

  Stats: 39 lines in 2 files changed: 9 ins; 17 del; 13 mod
  Patch: https://git.openjdk.org/shenandoah/pull/401.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah.git pull/401/head:pull/401

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

From kdnilsen at openjdk.org  Wed Mar 20 19:07:52 2024
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Wed, 20 Mar 2024 19:07:52 GMT
Subject: RFR: 8327097: GenShen: Align PLAB sizes down rather than up [v6]
In-Reply-To: <ubIf-lmCiowlGhyHfBvq-zudoKSzp6MWHaB9UZh5FuM=.27238aa1-a55b-4a19-9cac-e9c4de961613@github.com>
References: <ubIf-lmCiowlGhyHfBvq-zudoKSzp6MWHaB9UZh5FuM=.27238aa1-a55b-4a19-9cac-e9c4de961613@github.com>
Message-ID: <f6x1UgGNOMAnvMGbsFeJ7k5VD6BGmDd6AmeCjqhTIHs=.22cdd3c5-112d-4360-bdea-13ec43edeb18@github.com>

> When adjusting LAB sizes, round down rather than rounding up.  Otherwise, we may violate the ShenandoahHumongousThreshold bound.

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

  Add comments to clarify behavior of retire_plab

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

Changes:
  - all: https://git.openjdk.org/shenandoah/pull/401/files
  - new: https://git.openjdk.org/shenandoah/pull/401/files/45695f04..66609d9b

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

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

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

From kdnilsen at openjdk.org  Wed Mar 20 19:31:32 2024
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Wed, 20 Mar 2024 19:31:32 GMT
Subject: RFR: 8327388: GenShen: census during marking is partial
In-Reply-To: <g_Iob3H5hUHpr6iN1nzSSSM_u7_8z9hO6Al52hRtyUc=.ee22a343-8e84-454f-8da0-541cd3146026@github.com>
References: <g_Iob3H5hUHpr6iN1nzSSSM_u7_8z9hO6Al52hRtyUc=.ee22a343-8e84-454f-8da0-541cd3146026@github.com>
Message-ID: <rwx3uzHTnKMcA2Yrm4DyXI-pWOiK9V3h84QHPOvgoJ4=.3e270c95-4170-47e7-8822-1f7d0d35c288@github.com>

On Tue, 5 Mar 2024 17:43:20 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

> There was a bug in the placement of the call to clear stale census data before starting a fresh one for a new marking cycle that marks through the younger generation. This bug resulted in the use of a co-terminal suffix of the census collection, losing all data from the earlier iterations of an iterative collection process that may run up to 5 times.
> 
> We stumbled upon the defect when working on a refactoring task involving separation of generational extensions of Shenandoah from its non-generational version. The (performance) defect has existed since day zero of the adaptive tenuring code in GenShen.
> 
> Along with fixing the defect, an assertion has been added to check the "reasonable completeness" of the census, which came in useful to detect a reset call inadvertently left behind in one place.
> 
> Some ShenandoahAgeCensus APIs have been narrowed and cleaned up a bit, and documentation clarified a bit more.
> 
> **Testing**:
> - [x] GHA : there are crashes unrelated to this change that are being addressed in other PRs
> - [ ] Code pipeline testing : there is a crash, unrelated to this change, that needs investigation
> - [x] SPECjbb
> 
> **Performance**:
> - [x] SPECjbb : the variance in tests appears to fail significance under 2-tailed Mann-Whitney
> - [ ] SPECjbb (patched for wk ref issue) : TBD
> - [ ] Extremem : in progress

Thanks. LGTM.

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

Marked as reviewed by kdnilsen (Committer).

PR Review: https://git.openjdk.org/shenandoah/pull/403#pullrequestreview-1949951717

From kdnilsen at openjdk.org  Wed Mar 20 19:51:31 2024
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Wed, 20 Mar 2024 19:51:31 GMT
Subject: RFR: 8324649: Shenandoah: refactor implementation of free set
 [v32]
In-Reply-To: <HgHiTh_t5gXIEQnpJ8EbuF3mVuuyGOOh0DFsikSmo9E=.906d3f45-9210-4c24-9817-720935389846@github.com>
References: <VAkn0SrKYZWmnflpM8ZwVAXjUF1LjA0_FCBmRJJ4VSc=.c2f979bd-2957-434e-95ca-7b11b1573900@github.com>
 <Mu9wTnVX6kIS89pKXTUOHQT2CB7P_m_kSWGQHOQU-ko=.77851b17-c53b-4b59-8a84-6d518a19d35b@github.com>
 <HgHiTh_t5gXIEQnpJ8EbuF3mVuuyGOOh0DFsikSmo9E=.906d3f45-9210-4c24-9817-720935389846@github.com>
Message-ID: <3ARy3NOXJ-cou2Tz_N4EPluRvD8FdB5za6uQ8i_b5AA=.cb6211f2-20a8-4265-9d39-d5e7a349cfc5@github.com>

On Wed, 13 Mar 2024 19:49:21 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> Kelvin Nilsen has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Remove comment that pertains only to generational mode
>>  - Rewrite comment describing rationale for Collector free set membership
>
> src/hotspot/share/gc/shenandoah/shenandoahFreeSet.inline.hpp line 1:
> 
>> 1: /*
> 
> I don't think any of the code in shenandoahFreeSet.inline.hpp is public/used by any code outside of shenandoahFreeSet.cpp, which means that all of it should go into shenandoahFreeSet.cpp. The methods can still be 'inline'. The convention for .inline.hpp is mostly used to allow sharing inlined code and resolving circular dependencies.

I made some of these services "public" so that googletest can exercise the APIs from test/hotspot/gtest/gc/shenandoah/shenandoahSimpleBitMap.cpp.  Please advise if there's a better way.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17561#discussion_r1532758788

From ysr at openjdk.org  Wed Mar 20 19:54:43 2024
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Wed, 20 Mar 2024 19:54:43 GMT
Subject: RFR: 8328235: GenShen: Robustify ShenandoahGCSession and fix
 missing use
In-Reply-To: <m8Tp_YOJb1nHgEOJCWhZLfMk_yw3fe2QOuvQIt5u3YA=.8cea7cf9-f80d-4d93-a857-f30420ed6281@github.com>
References: <ViHIdrG0sja7rFJOMLnOkso6t--zQrnoQSnsrkLz4B0=.859112c8-2064-4a51-912c-0ce5667af37d@github.com>
 <m8Tp_YOJb1nHgEOJCWhZLfMk_yw3fe2QOuvQIt5u3YA=.8cea7cf9-f80d-4d93-a857-f30420ed6281@github.com>
Message-ID: <egZBTI9Air6j-oAaWwTpArV7yFMTWk7vTrhPwWTK1M0=.18ea6f78-557b-4242-bc80-a55fafa18010@github.com>

On Wed, 20 Mar 2024 10:16:38 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

> A case of flickering of active_generation() was identified, and found to be benign. An assert now checks for this situation. The code has been made robust wrt the flickering.

Testing revealed an issue with this PR, in particular with the clearing of active_generation() via Scopes -- this needs closer examination, so I'll once again take this back to draft. Sorry for the, errr, flickering in this PR :-)

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

PR Comment: https://git.openjdk.org/shenandoah/pull/407#issuecomment-2010502031

From kdnilsen at openjdk.org  Wed Mar 20 19:56:30 2024
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Wed, 20 Mar 2024 19:56:30 GMT
Subject: RFR: 8324649: Shenandoah: refactor implementation of free set
 [v32]
In-Reply-To: <HgHiTh_t5gXIEQnpJ8EbuF3mVuuyGOOh0DFsikSmo9E=.906d3f45-9210-4c24-9817-720935389846@github.com>
References: <VAkn0SrKYZWmnflpM8ZwVAXjUF1LjA0_FCBmRJJ4VSc=.c2f979bd-2957-434e-95ca-7b11b1573900@github.com>
 <Mu9wTnVX6kIS89pKXTUOHQT2CB7P_m_kSWGQHOQU-ko=.77851b17-c53b-4b59-8a84-6d518a19d35b@github.com>
 <HgHiTh_t5gXIEQnpJ8EbuF3mVuuyGOOh0DFsikSmo9E=.906d3f45-9210-4c24-9817-720935389846@github.com>
Message-ID: <-g5tscBZPsDgVrjfZnM-UBRy0_6qodnRN5_srPWunXk=.82eda809-141c-4bfb-82aa-e722eecd0469@github.com>

On Wed, 13 Mar 2024 20:01:25 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> Kelvin Nilsen has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Remove comment that pertains only to generational mode
>>  - Rewrite comment describing rationale for Collector free set membership
>
> src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp line 46:
> 
>> 44: }
>> 45: 
>> 46: size_t ShenandoahSimpleBitMap::count_leading_ones(ssize_t start_idx) const {
> 
> Are you sure that you can't use the BitMap class in src/hotspot/share/utilities/bitMap.*? Or maybe only src/hotspot/share/utilities/count_leading_zeros.hpp or src/hotspot/share/utilities/count_trailing_zeros.hpp? That would emit CPU instructions that do the counting really fast, if possible. I.e. reverse all bits after loading, then find leading/trailing zeros, problem solved real fast. I would even argue to augment the BitMap class with count_* methods as needed, using the CPU-optimized routines.

I will see if I can exploit the services in src/hotspot/share/utilities to improve performance.

> src/hotspot/share/gc/shenandoah/shenandoahFreeSet.hpp line 41:
> 
>> 39: 
>> 40: 
>> 41: // ShenandoahSimpleBitMap resembles CHeapBitMap but adds missing support for find_next_consecutive_bits() and
> 
> Ah I see you have considered using bitMap.* ... but why not 'simply' add the required methods there, instead?

Was trying to avoid impacting beyond the boundaries of Shenandoah.  I can tackle this if we think it preferable.  But also trying to work toward "timely integration".

> src/hotspot/share/gc/shenandoah/shenandoahFreeSet.hpp line 48:
> 
>> 46:   const ssize_t _num_bits;
>> 47:   const size_t _num_words;
>> 48:   size_t* const _bitmap;
> 
> I'd question the choice of size_t as type for the bitmap elements. size_t is typically used as size of index of arrays. If you want word-sized type, use intx or uintx instead?

I will change to uintx and intx.  Thanks.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17561#discussion_r1532762788
PR Review Comment: https://git.openjdk.org/jdk/pull/17561#discussion_r1532764524
PR Review Comment: https://git.openjdk.org/jdk/pull/17561#discussion_r1532765287

From wkemper at openjdk.org  Wed Mar 20 21:14:38 2024
From: wkemper at openjdk.org (William Kemper)
Date: Wed, 20 Mar 2024 21:14:38 GMT
Subject: RFR: 8328626: GenShen: Combine old generation surplus/deficit fields
 into a single balance field
Message-ID: <aoGfU4G3UAbcCMY1yHupTPG1yAf9wQbJ6C1kZ6T7K6Q=.4324cfc3-d477-4e68-b73b-4f38b59b2277@github.com>

This is a follow up to https://github.com/openjdk/shenandoah/pull/406.

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

Commit messages:
 - Factor computation of generational reserves into its own method
 - Combine old region surplus and deficit into a single balance field

Changes: https://git.openjdk.org/shenandoah/pull/410/files
  Webrev: https://webrevs.openjdk.org/?repo=shenandoah&pr=410&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8328626
  Stats: 133 lines in 5 files changed: 45 ins; 48 del; 40 mod
  Patch: https://git.openjdk.org/shenandoah/pull/410.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah.git pull/410/head:pull/410

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

From ysr at openjdk.org  Wed Mar 20 23:42:40 2024
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Wed, 20 Mar 2024 23:42:40 GMT
Subject: RFR: 8327097: GenShen: Align PLAB sizes down rather than up [v6]
In-Reply-To: <f6x1UgGNOMAnvMGbsFeJ7k5VD6BGmDd6AmeCjqhTIHs=.22cdd3c5-112d-4360-bdea-13ec43edeb18@github.com>
References: <ubIf-lmCiowlGhyHfBvq-zudoKSzp6MWHaB9UZh5FuM=.27238aa1-a55b-4a19-9cac-e9c4de961613@github.com>
 <f6x1UgGNOMAnvMGbsFeJ7k5VD6BGmDd6AmeCjqhTIHs=.22cdd3c5-112d-4360-bdea-13ec43edeb18@github.com>
Message-ID: <vMzXnpkq505CMSPZRUhOCmMcEdKor4OhjbOfv6WwcZo=.4a5ddd00-2111-41ec-9f3f-577fe279f77d@github.com>

On Wed, 20 Mar 2024 19:07:52 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> When adjusting LAB sizes, round down rather than rounding up.  Otherwise, we may violate the ShenandoahHumongousThreshold bound.
>
> Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add comments to clarify behavior of retire_plab

A few minor suggestions, nits, consts, etc.
Looks good to go otherwise. Happy to take a quick look again if you'd like after any changes stemming from these comments are done.

Sorry for the delay in getting this turned around.

src/hotspot/share/gc/shenandoah/shenandoahArguments.cpp line 222:

> 220:   if (strcmp(ShenandoahGCMode, "generational") == 0) {
> 221:     ShenandoahGenerationalHeap* heap = new ShenandoahGenerationalHeap(new ShenandoahCollectorPolicy());
> 222:     CollectedHeap* result = heap;

Wonder if it might read cleaner if we reversed the if-condition and returned the ShenandoahHeap from inside the if, then did the more cumbersome GenShen thing after.

Also, did you need to save in CollectedHeap* result to return it?
Simpler may be to do a


      ShenandoahGenerationalHeap* const gen_heap = new ...; 
      ... set min and max to card-aligned values ...
      return gen_heap;

Does that cause a compiler error?

src/hotspot/share/gc/shenandoah/shenandoahGenerationalHeap.hpp line 46:

> 44:   inline size_t plab_min_size() { return _min_plab_size; }
> 45:   inline size_t plab_max_size() { return _max_plab_size; }
> 46: 

If we never expect to change min and max, I'd make them const, and set them in the constructor.

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

> 1101:   assert(mode()->is_generational(), "PLABs only relevant to generational GC");
> 1102:   ShenandoahGenerationalHeap* generational_heap = (ShenandoahGenerationalHeap*) this;
> 1103:   size_t plab_min_size = generational_heap->plab_min_size();

const

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

> 1107:   } else {
> 1108:     min_size = plab_min_size;
> 1109:   }

May be more succint:

const size_t min_size = align_up(MAX2(size, plab_min_size), CardTable::card_size_in_words());

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

> 1113:   // available evacuation budget between the many threads that are coordinating in the evacuation effort.
> 1114:   future_size = MIN2(future_size, generational_heap->plab_max_size());
> 1115:   assert (future_size % CardTable::card_size_in_words() == 0, "Should align by design");

You can use

assert(is_aligned(future_size, CardTable::card_size_in_words(), "Aligned by construction");

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

> 1115:   if (cur_size == 0) {
> 1116:     cur_size = plab_min_size;
> 1117:   }

More succinct:

const size_t cur_size = MAX2(plab_min_size, ShenandoahThreadLocalData::plab_size(thread));
assert(is_aligned(cur_size, CardTable::card_size_in_words()), "Sanity check, by construction");

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

> 1122:   assert(is_aligned(future_size, CardTable::card_size_in_words()),
> 1123:          "Align by design, future_size: " SIZE_FORMAT ", card_size: " SIZE_FORMAT ", max_size: " SIZE_FORMAT,
> 1124:          future_size, (size_t) CardTable::card_size_in_words(), generational_heap->plab_max_size());

More succinct:

const size_t future_size = MIN2(cur_size*2, generational_heap->plab_max_size());
...

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

> 1163: #endif // ASSERT
> 1164:     }
> 1165:     assert (actual_size % CardTable::card_size_in_words() == 0,

Can use `is_aligned(actual_size, CardTable::...)` inside assert, avoiding `%`.

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

> 1209:     unexpend_promoted(not_promoted);
> 1210:   }
> 1211:   size_t original_waste = plab->waste();

const

src/hotspot/share/gc/shenandoah/shenandoahHeapRegion.inline.hpp line 46:

> 44: 
> 45:   HeapWord* orig_top = top();
> 46:   size_t addr_as_int = (uintptr_t) orig_top;

addr_as_int isn't needed anymore, and can be deleted?

src/hotspot/share/gc/shenandoah/shenandoahHeapRegion.inline.hpp line 52:

> 50:   // from alignment_in_words to determine padding required to next alignment point.
> 51: 
> 52:   HeapWord* aligned_obj = (HeapWord*) align_up(orig_top, alignment_in_bytes);

I think this method's declaration `allocate_aligned(...)` in the `.hpp` uses `alignment_in_words` as the name of the second parm. Similarly the comment in the header. Those should be corrected too to say `alignment_in_bytes`.

src/hotspot/share/gc/shenandoah/shenandoahHeapRegion.inline.hpp line 54:

> 52:   HeapWord* aligned_obj = (HeapWord*) align_up(orig_top, alignment_in_bytes);
> 53:   size_t pad_words = aligned_obj - orig_top;
> 54:   if (pad_words > 0) {

Can probably just && and fold together the two if tests.

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

Marked as reviewed by ysr (Committer).

PR Review: https://git.openjdk.org/shenandoah/pull/401#pullrequestreview-1948127476
PR Review Comment: https://git.openjdk.org/shenandoah/pull/401#discussion_r1531613299
PR Review Comment: https://git.openjdk.org/shenandoah/pull/401#discussion_r1531614502
PR Review Comment: https://git.openjdk.org/shenandoah/pull/401#discussion_r1533002685
PR Review Comment: https://git.openjdk.org/shenandoah/pull/401#discussion_r1533003029
PR Review Comment: https://git.openjdk.org/shenandoah/pull/401#discussion_r1531625382
PR Review Comment: https://git.openjdk.org/shenandoah/pull/401#discussion_r1533005767
PR Review Comment: https://git.openjdk.org/shenandoah/pull/401#discussion_r1533010939
PR Review Comment: https://git.openjdk.org/shenandoah/pull/401#discussion_r1531626379
PR Review Comment: https://git.openjdk.org/shenandoah/pull/401#discussion_r1533012067
PR Review Comment: https://git.openjdk.org/shenandoah/pull/401#discussion_r1533018129
PR Review Comment: https://git.openjdk.org/shenandoah/pull/401#discussion_r1533046178
PR Review Comment: https://git.openjdk.org/shenandoah/pull/401#discussion_r1533040863

From ysr at openjdk.org  Wed Mar 20 23:42:41 2024
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Wed, 20 Mar 2024 23:42:41 GMT
Subject: RFR: 8327097: GenShen: Align PLAB sizes down rather than up [v6]
In-Reply-To: <vMzXnpkq505CMSPZRUhOCmMcEdKor4OhjbOfv6WwcZo=.4a5ddd00-2111-41ec-9f3f-577fe279f77d@github.com>
References: <ubIf-lmCiowlGhyHfBvq-zudoKSzp6MWHaB9UZh5FuM=.27238aa1-a55b-4a19-9cac-e9c4de961613@github.com>
 <f6x1UgGNOMAnvMGbsFeJ7k5VD6BGmDd6AmeCjqhTIHs=.22cdd3c5-112d-4360-bdea-13ec43edeb18@github.com>
 <vMzXnpkq505CMSPZRUhOCmMcEdKor4OhjbOfv6WwcZo=.4a5ddd00-2111-41ec-9f3f-577fe279f77d@github.com>
Message-ID: <1O0uvcK1cESA11YxpzyPhC8Devc8RWWhc17b4gyGjug=.25e1d095-0396-4bc6-84bc-4bdd340417fb@github.com>

On Wed, 20 Mar 2024 23:35:52 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

>> Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add comments to clarify behavior of retire_plab
>
> src/hotspot/share/gc/shenandoah/shenandoahHeapRegion.inline.hpp line 52:
> 
>> 50:   // from alignment_in_words to determine padding required to next alignment point.
>> 51: 
>> 52:   HeapWord* aligned_obj = (HeapWord*) align_up(orig_top, alignment_in_bytes);
> 
> I think this method's declaration `allocate_aligned(...)` in the `.hpp` uses `alignment_in_words` as the name of the second parm. Similarly the comment in the header. Those should be corrected too to say `alignment_in_bytes`.

We do know that this is alignment must be a mutiple of HeapWordSize (as demonstrated by the integer division you do further above). I'd just assert for the sake of peace of mind from an API perspective that this is always so by:

assert(is_aligned(alignment_in_bytes, HeapWordSize), "Expected heap word alignment");

> src/hotspot/share/gc/shenandoah/shenandoahHeapRegion.inline.hpp line 54:
> 
>> 52:   HeapWord* aligned_obj = (HeapWord*) align_up(orig_top, alignment_in_bytes);
>> 53:   size_t pad_words = aligned_obj - orig_top;
>> 54:   if (pad_words > 0) {
> 
> Can probably just && and fold together the two if tests.

if (pad_words > 0 && pad_words < ShenandoahHeap::min_fill_size()) {
   // shift allocation right by another unit of alignment to accommodate pad for filler
   pad_words += alignment_in_words;
   aligned_obj += alignment_in_words;
}

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

PR Review Comment: https://git.openjdk.org/shenandoah/pull/401#discussion_r1533047867
PR Review Comment: https://git.openjdk.org/shenandoah/pull/401#discussion_r1533042712

From wkemper at openjdk.org  Thu Mar 21 14:20:52 2024
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 21 Mar 2024 14:20:52 GMT
Subject: RFR: Merge openjdk/jdk21u-dev:master
Message-ID: <l1DlVb-ItCBIEjSnzt15qBAEdeg-Pa8I89ZuDBaBUO8=.b8e7d8cb-b5ab-41ad-abf9-39832a0d0be3@github.com>

Merges tag jdk-21.0.3+7

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

Commit messages:
 - 8327391: Add SipHash attribution file

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

Changes: https://git.openjdk.org/shenandoah-jdk21u/pull/27/files
  Stats: 150 lines in 1 file changed: 150 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/shenandoah-jdk21u/pull/27.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah-jdk21u.git pull/27/head:pull/27

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

From kdnilsen at openjdk.org  Thu Mar 21 19:00:41 2024
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Thu, 21 Mar 2024 19:00:41 GMT
Subject: RFR: 8324649: Shenandoah: refactor implementation of free set
 [v33]
In-Reply-To: <VAkn0SrKYZWmnflpM8ZwVAXjUF1LjA0_FCBmRJJ4VSc=.c2f979bd-2957-434e-95ca-7b11b1573900@github.com>
References: <VAkn0SrKYZWmnflpM8ZwVAXjUF1LjA0_FCBmRJJ4VSc=.c2f979bd-2957-434e-95ca-7b11b1573900@github.com>
Message-ID: <nE7mOOBjdxfCSi7Ut66yHMKqTfetFu28lXRUGYSYhoc=.757bbe6a-8a58-4192-b485-323d9cfd09d7@github.com>

> Several objectives:
> 1. Reduce humongous allocation failures by segregating regular regions from humongous regions
> 2. Do not retire regions just because an allocation failed within the region if the memory remaining within the region is large enough to represent a LAB
> 3. Track range of empty regions in addition to range of available regions in order to expedite humongous allocations
> 4. Treat collector reserves as available for Mutator allocations after evacuation completes
> 5. Improve encapsulation so as to enable an OldCollector reserve for future integration of generational Shenandoah
> 
> We have compared performance of existing FreeSet implementation with the proposed PR over a broad set of performance workloads and see that the impact is mostly neutral.
> 
> Comparing 105235.0 metrics from control, 220638.0 from experiment.
> Compare: 0.589s
>                           Most impacted benchmarks |                              Most impacted metrics
> -------------------------------------------------------------------------------------------------------
>                                  Shenandoah/jython |                                          cwr_total
> 
> 
>                                 Only in experiment |                                    Only in control
> -------------------------------------------------------------------------------------------------------
>                  crypto.signverify/trigger_failure |                        crypto.rsa/cmr_thread_roots
>                 extremem-large-31g/adjust_pointers |       scimark.sparse.small/concurrent_thread_roots
>             extremem-large-31g/calculate_addresses |              xml.transform/concurrent_thread_roots
>       crypto.signverify/class_unloading_rendezvous |                    mpegaudio/concurrent_weak_roots
>                                   serial/cmr_total |                        crypto.rsa/ctr_thread_roots
> 
> Shenandoah
> -------------------------------------------------------------------------------------------------------
> +5.64% jython/cwr_total p=0.00037
>   Control:      1.928ms (+/-272.40us)        170
>   Test:         2.037ms (+/-322.73us)        344

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

  Exploit count_<leading|trailing>_zeros instructions
  
  The ShenandoahSimpleBitMap can run more efficiently if we use hardware
  instructions to count leading and trailing zeros.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17561/files
  - new: https://git.openjdk.org/jdk/pull/17561/files/57d2e71f..eebb78a2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17561&range=32
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17561&range=31-32

  Stats: 164 lines in 3 files changed: 38 ins; 42 del; 84 mod
  Patch: https://git.openjdk.org/jdk/pull/17561.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17561/head:pull/17561

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

From kdnilsen at openjdk.org  Thu Mar 21 23:12:43 2024
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Thu, 21 Mar 2024 23:12:43 GMT
Subject: RFR: 8324649: Shenandoah: refactor implementation of free set
 [v34]
In-Reply-To: <VAkn0SrKYZWmnflpM8ZwVAXjUF1LjA0_FCBmRJJ4VSc=.c2f979bd-2957-434e-95ca-7b11b1573900@github.com>
References: <VAkn0SrKYZWmnflpM8ZwVAXjUF1LjA0_FCBmRJJ4VSc=.c2f979bd-2957-434e-95ca-7b11b1573900@github.com>
Message-ID: <5Wt6POtzeN4_SlwEnRrONaV10BeY1QYcKXzRUK-oSJI=.cb4aeb75-32f4-4801-b9a0-b2498b978369@github.com>

> Several objectives:
> 1. Reduce humongous allocation failures by segregating regular regions from humongous regions
> 2. Do not retire regions just because an allocation failed within the region if the memory remaining within the region is large enough to represent a LAB
> 3. Track range of empty regions in addition to range of available regions in order to expedite humongous allocations
> 4. Treat collector reserves as available for Mutator allocations after evacuation completes
> 5. Improve encapsulation so as to enable an OldCollector reserve for future integration of generational Shenandoah
> 
> We have compared performance of existing FreeSet implementation with the proposed PR over a broad set of performance workloads and see that the impact is mostly neutral.
> 
> Comparing 105235.0 metrics from control, 220638.0 from experiment.
> Compare: 0.589s
>                           Most impacted benchmarks |                              Most impacted metrics
> -------------------------------------------------------------------------------------------------------
>                                  Shenandoah/jython |                                          cwr_total
> 
> 
>                                 Only in experiment |                                    Only in control
> -------------------------------------------------------------------------------------------------------
>                  crypto.signverify/trigger_failure |                        crypto.rsa/cmr_thread_roots
>                 extremem-large-31g/adjust_pointers |       scimark.sparse.small/concurrent_thread_roots
>             extremem-large-31g/calculate_addresses |              xml.transform/concurrent_thread_roots
>       crypto.signverify/class_unloading_rendezvous |                    mpegaudio/concurrent_weak_roots
>                                   serial/cmr_total |                        crypto.rsa/ctr_thread_roots
> 
> Shenandoah
> -------------------------------------------------------------------------------------------------------
> +5.64% jython/cwr_total p=0.00037
>   Control:      1.928ms (+/-272.40us)        170
>   Test:         2.037ms (+/-322.73us)        344

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

  Give special handling to count-zeros when arg is 0

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17561/files
  - new: https://git.openjdk.org/jdk/pull/17561/files/eebb78a2..d65c2ea4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17561&range=33
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17561&range=32-33

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

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

From kdnilsen at openjdk.org  Thu Mar 21 23:51:45 2024
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Thu, 21 Mar 2024 23:51:45 GMT
Subject: RFR: 8327097: GenShen: Align PLAB sizes down rather than up [v7]
In-Reply-To: <ubIf-lmCiowlGhyHfBvq-zudoKSzp6MWHaB9UZh5FuM=.27238aa1-a55b-4a19-9cac-e9c4de961613@github.com>
References: <ubIf-lmCiowlGhyHfBvq-zudoKSzp6MWHaB9UZh5FuM=.27238aa1-a55b-4a19-9cac-e9c4de961613@github.com>
Message-ID: <-theQS5HYh24oh-oFsd1encM37cQhjSXkkIunYyB-LI=.fb2c37d0-441b-4f8f-891c-d638c33069ae@github.com>

> When adjusting LAB sizes, round down rather than rounding up.  Otherwise, we may violate the ShenandoahHumongousThreshold bound.

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

  Fix up a few other places where PLAB min size or current size gets set
  
  This may explain how unaligned sizes were being detected by existing
  assertions.

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

Changes:
  - all: https://git.openjdk.org/shenandoah/pull/401/files
  - new: https://git.openjdk.org/shenandoah/pull/401/files/66609d9b..77663512

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

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

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

From cslucas at openjdk.org  Fri Mar 22 00:35:28 2024
From: cslucas at openjdk.org (Cesar Soares Lucas)
Date: Fri, 22 Mar 2024 00:35:28 GMT
Subject: RFR: JDK-8241503: C2: Share MacroAssembler between mach nodes
 during code emission [v9]
In-Reply-To: <ExCrwPns55nw2P62UI3vzSVTmFCh3dzJq7u3Kugp9EA=.c20cd86c-2c16-4869-ba7f-76f2a53821d0@github.com>
References: <ExCrwPns55nw2P62UI3vzSVTmFCh3dzJq7u3Kugp9EA=.c20cd86c-2c16-4869-ba7f-76f2a53821d0@github.com>
Message-ID: <N4PSWexrDeTVdvIIQte4-zIxhGv-BzbsRebErl_BYr0=.55a43315-d11d-4c7c-8b35-4c31c42ac876@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`.
> 
> # Tier-1 Testing status
> 
> |          |   Win   |   Mac   |  Linux  |
> |----------|---------|---------|---------|
> | ARM64    |    ?     |    ?     |         |
> | ARM32    |    n/a     |     n/a    |         |
> | x86      |         |         |    ?     |
> | x64      |    ?     |    ?     |     ?    |
> | PPC64    |  n/a       |   n/a      |         |
> | S390x    |   n/a      |   n/a      |         |
> | RiscV    |    n/a     |    n/a     |    ?     |

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 10 commits:

 - Catching up with changes in master
 - Catching up with origin/master
 - Catch up with origin/master
 - Merge with origin/master
 - Fix build, copyright dates, m4 files.
 - 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=08
  Stats: 2152 lines in 60 files changed: 136 ins; 431 del; 1585 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 kdnilsen at openjdk.org  Fri Mar 22 04:04:36 2024
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Fri, 22 Mar 2024 04:04:36 GMT
Subject: RFR: 8324649: Shenandoah: refactor implementation of free set
 [v35]
In-Reply-To: <VAkn0SrKYZWmnflpM8ZwVAXjUF1LjA0_FCBmRJJ4VSc=.c2f979bd-2957-434e-95ca-7b11b1573900@github.com>
References: <VAkn0SrKYZWmnflpM8ZwVAXjUF1LjA0_FCBmRJJ4VSc=.c2f979bd-2957-434e-95ca-7b11b1573900@github.com>
Message-ID: <TPbLWVXv7XH-RsPZX1978mNwEae0Wr3TTgyOBFvoFZs=.4b9a824d-8dc6-4159-9825-372239de28c1@github.com>

> Several objectives:
> 1. Reduce humongous allocation failures by segregating regular regions from humongous regions
> 2. Do not retire regions just because an allocation failed within the region if the memory remaining within the region is large enough to represent a LAB
> 3. Track range of empty regions in addition to range of available regions in order to expedite humongous allocations
> 4. Treat collector reserves as available for Mutator allocations after evacuation completes
> 5. Improve encapsulation so as to enable an OldCollector reserve for future integration of generational Shenandoah
> 
> We have compared performance of existing FreeSet implementation with the proposed PR over a broad set of performance workloads and see that the impact is mostly neutral.
> 
> Comparing 105235.0 metrics from control, 220638.0 from experiment.
> Compare: 0.589s
>                           Most impacted benchmarks |                              Most impacted metrics
> -------------------------------------------------------------------------------------------------------
>                                  Shenandoah/jython |                                          cwr_total
> 
> 
>                                 Only in experiment |                                    Only in control
> -------------------------------------------------------------------------------------------------------
>                  crypto.signverify/trigger_failure |                        crypto.rsa/cmr_thread_roots
>                 extremem-large-31g/adjust_pointers |       scimark.sparse.small/concurrent_thread_roots
>             extremem-large-31g/calculate_addresses |              xml.transform/concurrent_thread_roots
>       crypto.signverify/class_unloading_rendezvous |                    mpegaudio/concurrent_weak_roots
>                                   serial/cmr_total |                        crypto.rsa/ctr_thread_roots
> 
> Shenandoah
> -------------------------------------------------------------------------------------------------------
> +5.64% jython/cwr_total p=0.00037
>   Control:      1.928ms (+/-272.40us)        170
>   Test:         2.037ms (+/-322.73us)        344

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

  Fix one bug and add disabled instrumentation for debugging

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17561/files
  - new: https://git.openjdk.org/jdk/pull/17561/files/d65c2ea4..38faeeab

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17561&range=34
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17561&range=33-34

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

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

From mdoerr at openjdk.org  Fri Mar 22 11:31:28 2024
From: mdoerr at openjdk.org (Martin Doerr)
Date: Fri, 22 Mar 2024 11:31:28 GMT
Subject: RFR: JDK-8241503: C2: Share MacroAssembler between mach nodes
 during code emission [v9]
In-Reply-To: <N4PSWexrDeTVdvIIQte4-zIxhGv-BzbsRebErl_BYr0=.55a43315-d11d-4c7c-8b35-4c31c42ac876@github.com>
References: <ExCrwPns55nw2P62UI3vzSVTmFCh3dzJq7u3Kugp9EA=.c20cd86c-2c16-4869-ba7f-76f2a53821d0@github.com>
 <N4PSWexrDeTVdvIIQte4-zIxhGv-BzbsRebErl_BYr0=.55a43315-d11d-4c7c-8b35-4c31c42ac876@github.com>
Message-ID: <7XyaAxApFNWbmO0yXfUF8lo4v-Xgyfg90RFrwE-lNOM=.083fce75-0f71-40ec-b208-30082a0e5b91@github.com>

On Fri, 22 Mar 2024 00:35:28 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`.
>> 
>> # Tier-1 Testing status
>> 
>> |          |   Win   |   Mac   |  Linux  |
>> |----------|---------|---------|---------|
>> | ARM64    |    ?     |    ?     |         |
>> | ARM32    |    n/a     |     n/a    |         |
>> | x86      |         |         |    ?     |
>> | x64      |    ?     |    ?     |     ?    |
>> | PPC64    |  n/a       |   n/a      |         |
>> | S390x    |   n/a      |   n/a      |         |
>> | RiscV    |    n/a     |    n/a     |    ?     |
>
> 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 10 commits:
> 
>  - Catching up with changes in master
>  - Catching up with origin/master
>  - Catch up with origin/master
>  - Merge with origin/master
>  - Fix build, copyright dates, m4 files.
>  - 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.

Thanks for the update! The PPC64 parts look good to me. Other platforms need be reviewed by other people (maintainers are listed here: https://wiki.openjdk.org/display/HotSpot/Ports).

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

Marked as reviewed by mdoerr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16484#pullrequestreview-1954565932

From wkemper at openjdk.org  Fri Mar 22 14:21:10 2024
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 22 Mar 2024 14:21:10 GMT
Subject: RFR: Merge openjdk/jdk:master
Message-ID: <7naay40eQj26BGLm-vHMFmJ5Kt7EcEV8dRx_VI-MEbU=.9d2c8c53-02cd-4b59-babc-3ad5072ffedf@github.com>

Merges tag jdk-23+15

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

Commit messages:
 - 8328035: Convert javax/swing/text/html/TableView/7030332/bug7030332.java applet test to main
 - 8328300: Convert PrintDialogsTest.java from Applet to main program
 - 8296244: Alternate implementation of user-based authorization Subject APIs that doesn?t depend on Security Manager APIs
 - 8319251: [REDO] Change LockingMode default from LM_LEGACY to LM_LIGHTWEIGHT
 - 8328379: Convert URLDragTest.html applet test to main
 - 8326521: JFR: CompilerPhase event test fails on windows 32 bit
 - 8328225: Convert ImageDecoratedDnD.html applet test to main
 - 8328185: Convert java/awt/image/MemoryLeakTest/MemoryLeakTest.java applet test to main
 - 7036144: GZIPInputStream readTrailer uses faulty available() test for end-of-stream
 - 8328386: Convert java/awt/FileDialog/FileNameOverrideTest test to main
 - ... and 460 more: https://git.openjdk.org/shenandoah/compare/8cb9b479...481473ef

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

Changes: https://git.openjdk.org/shenandoah/pull/411/files
  Stats: 416588 lines in 2959 files changed: 35144 ins; 90175 del; 291269 mod
  Patch: https://git.openjdk.org/shenandoah/pull/411.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah.git pull/411/head:pull/411

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

From kdnilsen at openjdk.org  Fri Mar 22 15:44:47 2024
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Fri, 22 Mar 2024 15:44:47 GMT
Subject: RFR: 8324649: Shenandoah: refactor implementation of free set
 [v36]
In-Reply-To: <VAkn0SrKYZWmnflpM8ZwVAXjUF1LjA0_FCBmRJJ4VSc=.c2f979bd-2957-434e-95ca-7b11b1573900@github.com>
References: <VAkn0SrKYZWmnflpM8ZwVAXjUF1LjA0_FCBmRJJ4VSc=.c2f979bd-2957-434e-95ca-7b11b1573900@github.com>
Message-ID: <sz1iMH3ymlBy2CtO5RQJGICCaLcjJ6dXwNB2v-Q-wZw=.5c37ca37-d3c9-454d-a613-a2b0b593d914@github.com>

> Several objectives:
> 1. Reduce humongous allocation failures by segregating regular regions from humongous regions
> 2. Do not retire regions just because an allocation failed within the region if the memory remaining within the region is large enough to represent a LAB
> 3. Track range of empty regions in addition to range of available regions in order to expedite humongous allocations
> 4. Treat collector reserves as available for Mutator allocations after evacuation completes
> 5. Improve encapsulation so as to enable an OldCollector reserve for future integration of generational Shenandoah
> 
> We have compared performance of existing FreeSet implementation with the proposed PR over a broad set of performance workloads and see that the impact is mostly neutral.
> 
> Comparing 105235.0 metrics from control, 220638.0 from experiment.
> Compare: 0.589s
>                           Most impacted benchmarks |                              Most impacted metrics
> -------------------------------------------------------------------------------------------------------
>                                  Shenandoah/jython |                                          cwr_total
> 
> 
>                                 Only in experiment |                                    Only in control
> -------------------------------------------------------------------------------------------------------
>                  crypto.signverify/trigger_failure |                        crypto.rsa/cmr_thread_roots
>                 extremem-large-31g/adjust_pointers |       scimark.sparse.small/concurrent_thread_roots
>             extremem-large-31g/calculate_addresses |              xml.transform/concurrent_thread_roots
>       crypto.signverify/class_unloading_rendezvous |                    mpegaudio/concurrent_weak_roots
>                                   serial/cmr_total |                        crypto.rsa/ctr_thread_roots
> 
> Shenandoah
> -------------------------------------------------------------------------------------------------------
> +5.64% jython/cwr_total p=0.00037
>   Control:      1.928ms (+/-272.40us)        170
>   Test:         2.037ms (+/-322.73us)        344

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

 - Add a few more conditions to ShenandoahSimpleBitMapTest
 - Fix typo in log message for 32-bit platforms

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17561/files
  - new: https://git.openjdk.org/jdk/pull/17561/files/38faeeab..b320a3a7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17561&range=35
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17561&range=34-35

  Stats: 39 lines in 2 files changed: 22 ins; 1 del; 16 mod
  Patch: https://git.openjdk.org/jdk/pull/17561.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17561/head:pull/17561

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

From wkemper at openjdk.org  Fri Mar 22 17:44:02 2024
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 22 Mar 2024 17:44:02 GMT
Subject: RFR: 8328626: GenShen: Combine old generation surplus/deficit
 fields into a single balance field [v2]
In-Reply-To: <aoGfU4G3UAbcCMY1yHupTPG1yAf9wQbJ6C1kZ6T7K6Q=.4324cfc3-d477-4e68-b73b-4f38b59b2277@github.com>
References: <aoGfU4G3UAbcCMY1yHupTPG1yAf9wQbJ6C1kZ6T7K6Q=.4324cfc3-d477-4e68-b73b-4f38b59b2277@github.com>
Message-ID: <RoEjBTu1PWGPYYaw2AHkRotvJHbIlz6dqQCxY3Ke8kg=.cb557aa6-826f-4a59-8456-c6f3becf8dce@github.com>

> This is a follow up to https://github.com/openjdk/shenandoah/pull/406.

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

 - Fix zero build
 - Fix comments

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

Changes:
  - all: https://git.openjdk.org/shenandoah/pull/410/files
  - new: https://git.openjdk.org/shenandoah/pull/410/files/2ed3d6d7..8ebe8b8c

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

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

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

From cslucas at openjdk.org  Fri Mar 22 17:46:27 2024
From: cslucas at openjdk.org (Cesar Soares Lucas)
Date: Fri, 22 Mar 2024 17:46:27 GMT
Subject: RFR: JDK-8241503: C2: Share MacroAssembler between mach nodes
 during code emission [v6]
In-Reply-To: <8ZkfLag-QKsU8stjY8amUxO_0-yTr8SlXOSh6nhQ1PM=.6efb1eef-b8a9-437a-9a1f-f5aa74009f0f@github.com>
References: <ExCrwPns55nw2P62UI3vzSVTmFCh3dzJq7u3Kugp9EA=.c20cd86c-2c16-4869-ba7f-76f2a53821d0@github.com>
 <B5hp17WOakZK2Hdv4Sr940K05ZBHWOMft8pRd0QdQ1k=.a44e1c19-92a6-4317-91a5-b3e928afb3f6@github.com>
 <8ZkfLag-QKsU8stjY8amUxO_0-yTr8SlXOSh6nhQ1PM=.6efb1eef-b8a9-437a-9a1f-f5aa74009f0f@github.com>
Message-ID: <UZRz1892bqeUyIUI6PqvxFxtEwd_TC28VQGuS_ot-qk=.fe609f63-3fc4-4316-a77a-7ba5acc03656@github.com>

On Wed, 20 Dec 2023 20:01:43 GMT, Vladimir Kozlov <kvn 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 seven commits:
>> 
>>  - Merge with origin/master
>>  - Fix build, copyright dates, m4 files.
>>  - 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/x86/assembler_x86.cpp line 4248:
> 
>> 4246: void Assembler::vpermb(XMMRegister dst, XMMRegister nds, XMMRegister src, int vector_len) {
>> 4247:   assert(VM_Version::supports_avx512_vbmi(), "");
>> 4248:   InstructionMark im(this);
> 
> May be add short comment why you need `InstructionMark` in these instructions but not in others.

I expanded the comment in declaration of InstructionMark class with more information. I'm pushing the changes in a few minutes.

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

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

From kdnilsen at openjdk.org  Fri Mar 22 17:46:36 2024
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Fri, 22 Mar 2024 17:46:36 GMT
Subject: RFR: 8327097: GenShen: Align PLAB sizes down rather than up [v7]
In-Reply-To: <vMzXnpkq505CMSPZRUhOCmMcEdKor4OhjbOfv6WwcZo=.4a5ddd00-2111-41ec-9f3f-577fe279f77d@github.com>
References: <ubIf-lmCiowlGhyHfBvq-zudoKSzp6MWHaB9UZh5FuM=.27238aa1-a55b-4a19-9cac-e9c4de961613@github.com>
 <f6x1UgGNOMAnvMGbsFeJ7k5VD6BGmDd6AmeCjqhTIHs=.22cdd3c5-112d-4360-bdea-13ec43edeb18@github.com>
 <vMzXnpkq505CMSPZRUhOCmMcEdKor4OhjbOfv6WwcZo=.4a5ddd00-2111-41ec-9f3f-577fe279f77d@github.com>
Message-ID: <FnOpgBAqZ4OOoQ14N8fWwbQ1cdmLKMPzeV1uRe8Vr6I=.183f5b57-ff95-4f2a-a7ba-8d8d01ea3d14@github.com>

On Wed, 20 Mar 2024 07:28:54 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

>> Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix up a few other places where PLAB min size or current size gets set
>>   
>>   This may explain how unaligned sizes were being detected by existing
>>   assertions.
>
> src/hotspot/share/gc/shenandoah/shenandoahArguments.cpp line 222:
> 
>> 220:   if (strcmp(ShenandoahGCMode, "generational") == 0) {
>> 221:     ShenandoahGenerationalHeap* heap = new ShenandoahGenerationalHeap(new ShenandoahCollectorPolicy());
>> 222:     CollectedHeap* result = heap;
> 
> Wonder if it might read cleaner if we reversed the if-condition and returned the ShenandoahHeap from inside the if, then did the more cumbersome GenShen thing after.
> 
> Also, did you need to save in CollectedHeap* result to return it?
> Simpler may be to do a
> 
> 
>       ShenandoahGenerationalHeap* const gen_heap = new ...; 
>       ... set min and max to card-aligned values ...
>       return gen_heap;
> 
> Does that cause a compiler error?

Thanks.  Making this change.

> src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp line 1165:
> 
>> 1163: #endif // ASSERT
>> 1164:     }
>> 1165:     assert (actual_size % CardTable::card_size_in_words() == 0,
> 
> Can use `is_aligned(actual_size, CardTable::...)` inside assert, avoiding `%`.

Done.  Thanks.

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

PR Review Comment: https://git.openjdk.org/shenandoah/pull/401#discussion_r1535966759
PR Review Comment: https://git.openjdk.org/shenandoah/pull/401#discussion_r1535969107

From kdnilsen at openjdk.org  Fri Mar 22 18:00:41 2024
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Fri, 22 Mar 2024 18:00:41 GMT
Subject: RFR: 8327097: GenShen: Align PLAB sizes down rather than up [v7]
In-Reply-To: <vMzXnpkq505CMSPZRUhOCmMcEdKor4OhjbOfv6WwcZo=.4a5ddd00-2111-41ec-9f3f-577fe279f77d@github.com>
References: <ubIf-lmCiowlGhyHfBvq-zudoKSzp6MWHaB9UZh5FuM=.27238aa1-a55b-4a19-9cac-e9c4de961613@github.com>
 <f6x1UgGNOMAnvMGbsFeJ7k5VD6BGmDd6AmeCjqhTIHs=.22cdd3c5-112d-4360-bdea-13ec43edeb18@github.com>
 <vMzXnpkq505CMSPZRUhOCmMcEdKor4OhjbOfv6WwcZo=.4a5ddd00-2111-41ec-9f3f-577fe279f77d@github.com>
Message-ID: <SjGZw9myLuSMcCIzDjQougV4LGZmIf7xSnd5PgEZgHI=.2e2782d4-b90c-4424-9b10-911be89741a0@github.com>

On Wed, 20 Mar 2024 07:29:55 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

>> Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix up a few other places where PLAB min size or current size gets set
>>   
>>   This may explain how unaligned sizes were being detected by existing
>>   assertions.
>
> src/hotspot/share/gc/shenandoah/shenandoahGenerationalHeap.hpp line 46:
> 
>> 44:   inline size_t plab_min_size() { return _min_plab_size; }
>> 45:   inline size_t plab_max_size() { return _max_plab_size; }
>> 46: 
> 
> If we never expect to change min and max, I'd make them const, and set them in the constructor.

Good suggestions.  Done.

> src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp line 1115:
> 
>> 1113:   // available evacuation budget between the many threads that are coordinating in the evacuation effort.
>> 1114:   future_size = MIN2(future_size, generational_heap->plab_max_size());
>> 1115:   assert (future_size % CardTable::card_size_in_words() == 0, "Should align by design");
> 
> You can use
> 
> assert(is_aligned(future_size, CardTable::card_size_in_words(), "Aligned by construction");

Thanks.  Done.

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

PR Review Comment: https://git.openjdk.org/shenandoah/pull/401#discussion_r1535986812
PR Review Comment: https://git.openjdk.org/shenandoah/pull/401#discussion_r1535988852

From kvn at openjdk.org  Fri Mar 22 18:01:35 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Fri, 22 Mar 2024 18:01:35 GMT
Subject: RFR: JDK-8241503: C2: Share MacroAssembler between mach nodes
 during code emission [v9]
In-Reply-To: <N4PSWexrDeTVdvIIQte4-zIxhGv-BzbsRebErl_BYr0=.55a43315-d11d-4c7c-8b35-4c31c42ac876@github.com>
References: <ExCrwPns55nw2P62UI3vzSVTmFCh3dzJq7u3Kugp9EA=.c20cd86c-2c16-4869-ba7f-76f2a53821d0@github.com>
 <N4PSWexrDeTVdvIIQte4-zIxhGv-BzbsRebErl_BYr0=.55a43315-d11d-4c7c-8b35-4c31c42ac876@github.com>
Message-ID: <UY-g1GWp_LnuDJY4mLo9q2dD6QhwGw3yAdOC9augFq0=.7e23c7af-7c17-4dc1-bf02-1488e7eb5cc1@github.com>

On Fri, 22 Mar 2024 00:35:28 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`.
>> 
>> # Tier-1 Testing status
>> 
>> |          |   Win   |   Mac   |  Linux  |
>> |----------|---------|---------|---------|
>> | ARM64    |    ?     |    ?     |         |
>> | ARM32    |    n/a     |     n/a    |         |
>> | x86      |         |         |    ?     |
>> | x64      |    ?     |    ?     |     ?    |
>> | PPC64    |  n/a       |   n/a      |         |
>> | S390x    |   n/a      |   n/a      |         |
>> | RiscV    |    n/a     |    n/a     |    ?     |
>
> 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 10 commits:
> 
>  - Catching up with changes in master
>  - Catching up with origin/master
>  - Catch up with origin/master
>  - Merge with origin/master
>  - Fix build, copyright dates, m4 files.
>  - 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.

GHA shows issue with Aarch64 builds on MacOS and Windows:

d:\a\jdk\jdk\build\windows-aarch64\hotspot\variant-server\gensrc\adfiles\ad_aarch64.cpp(24257): error C2653: 'CompiledStaticCall': is not a class or namespace name
d:\a\jdk\jdk\build\windows-aarch64\hotspot\variant-server\gensrc\adfiles\ad_aarch64.cpp(24257): error C3861: 'emit_to_interp_stub': identifier not found

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

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

From kdnilsen at openjdk.org  Fri Mar 22 18:03:47 2024
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Fri, 22 Mar 2024 18:03:47 GMT
Subject: RFR: 8327097: GenShen: Align PLAB sizes down rather than up [v6]
In-Reply-To: <vMzXnpkq505CMSPZRUhOCmMcEdKor4OhjbOfv6WwcZo=.4a5ddd00-2111-41ec-9f3f-577fe279f77d@github.com>
References: <ubIf-lmCiowlGhyHfBvq-zudoKSzp6MWHaB9UZh5FuM=.27238aa1-a55b-4a19-9cac-e9c4de961613@github.com>
 <f6x1UgGNOMAnvMGbsFeJ7k5VD6BGmDd6AmeCjqhTIHs=.22cdd3c5-112d-4360-bdea-13ec43edeb18@github.com>
 <vMzXnpkq505CMSPZRUhOCmMcEdKor4OhjbOfv6WwcZo=.4a5ddd00-2111-41ec-9f3f-577fe279f77d@github.com>
Message-ID: <zA1hhFJnQ4lgOTSVOzYXbXMCgDiwywXjRGkLVIWfsEM=.d05156df-c88c-48c0-aa3d-f43ed39a2f21@github.com>

On Wed, 20 Mar 2024 22:51:52 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

>> Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add comments to clarify behavior of retire_plab
>
> src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp line 1103:
> 
>> 1101:   assert(mode()->is_generational(), "PLABs only relevant to generational GC");
>> 1102:   ShenandoahGenerationalHeap* generational_heap = (ShenandoahGenerationalHeap*) this;
>> 1103:   size_t plab_min_size = generational_heap->plab_min_size();
> 
> const

Thanks.  Done.

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

PR Review Comment: https://git.openjdk.org/shenandoah/pull/401#discussion_r1535991319

From kdnilsen at openjdk.org  Fri Mar 22 18:09:34 2024
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Fri, 22 Mar 2024 18:09:34 GMT
Subject: RFR: 8327097: GenShen: Align PLAB sizes down rather than up [v6]
In-Reply-To: <vMzXnpkq505CMSPZRUhOCmMcEdKor4OhjbOfv6WwcZo=.4a5ddd00-2111-41ec-9f3f-577fe279f77d@github.com>
References: <ubIf-lmCiowlGhyHfBvq-zudoKSzp6MWHaB9UZh5FuM=.27238aa1-a55b-4a19-9cac-e9c4de961613@github.com>
 <f6x1UgGNOMAnvMGbsFeJ7k5VD6BGmDd6AmeCjqhTIHs=.22cdd3c5-112d-4360-bdea-13ec43edeb18@github.com>
 <vMzXnpkq505CMSPZRUhOCmMcEdKor4OhjbOfv6WwcZo=.4a5ddd00-2111-41ec-9f3f-577fe279f77d@github.com>
Message-ID: <1HMTnHputYhVKTb8I81VL8CXVCPBFCOnakHYflRYU-A=.aecbf3b0-9a23-48dc-8704-9bc59c4621af@github.com>

On Wed, 20 Mar 2024 22:57:30 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

>> Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add comments to clarify behavior of retire_plab
>
> src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp line 1124:
> 
>> 1122:   assert(is_aligned(future_size, CardTable::card_size_in_words()),
>> 1123:          "Align by design, future_size: " SIZE_FORMAT ", card_size: " SIZE_FORMAT ", max_size: " SIZE_FORMAT,
>> 1124:          future_size, (size_t) CardTable::card_size_in_words(), generational_heap->plab_max_size());
> 
> More succinct:
> 
> const size_t future_size = MIN2(cur_size*2, generational_heap->plab_max_size());
> ...

Thanks.  Done.

> src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp line 1211:
> 
>> 1209:     unexpend_promoted(not_promoted);
>> 1210:   }
>> 1211:   size_t original_waste = plab->waste();
> 
> const

Thanks.  Done.

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

PR Review Comment: https://git.openjdk.org/shenandoah/pull/401#discussion_r1535996298
PR Review Comment: https://git.openjdk.org/shenandoah/pull/401#discussion_r1535997096

From cslucas at openjdk.org  Fri Mar 22 18:19:39 2024
From: cslucas at openjdk.org (Cesar Soares Lucas)
Date: Fri, 22 Mar 2024 18:19:39 GMT
Subject: RFR: JDK-8241503: C2: Share MacroAssembler between mach nodes
 during code emission [v10]
In-Reply-To: <ExCrwPns55nw2P62UI3vzSVTmFCh3dzJq7u3Kugp9EA=.c20cd86c-2c16-4869-ba7f-76f2a53821d0@github.com>
References: <ExCrwPns55nw2P62UI3vzSVTmFCh3dzJq7u3Kugp9EA=.c20cd86c-2c16-4869-ba7f-76f2a53821d0@github.com>
Message-ID: <b0kJcywc9OD_TrAq6FJ9bvHE5WeiCD2hXXItkoseuIk=.e7d36d93-0f5f-4139-b0fd-ec2370f0cdef@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`.

Cesar Soares Lucas has updated the pull request incrementally with one additional commit since the last revision:

  Fix AArch64 build & improve comment about InstructionMark

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16484/files
  - new: https://git.openjdk.org/jdk/pull/16484/files/aa80c801..e763b089

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

  Stats: 4 lines in 3 files changed: 1 ins; 1 del; 2 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 cslucas at openjdk.org  Fri Mar 22 18:19:42 2024
From: cslucas at openjdk.org (Cesar Soares Lucas)
Date: Fri, 22 Mar 2024 18:19:42 GMT
Subject: RFR: JDK-8241503: C2: Share MacroAssembler between mach nodes
 during code emission [v9]
In-Reply-To: <UY-g1GWp_LnuDJY4mLo9q2dD6QhwGw3yAdOC9augFq0=.7e23c7af-7c17-4dc1-bf02-1488e7eb5cc1@github.com>
References: <ExCrwPns55nw2P62UI3vzSVTmFCh3dzJq7u3Kugp9EA=.c20cd86c-2c16-4869-ba7f-76f2a53821d0@github.com>
 <N4PSWexrDeTVdvIIQte4-zIxhGv-BzbsRebErl_BYr0=.55a43315-d11d-4c7c-8b35-4c31c42ac876@github.com>
 <UY-g1GWp_LnuDJY4mLo9q2dD6QhwGw3yAdOC9augFq0=.7e23c7af-7c17-4dc1-bf02-1488e7eb5cc1@github.com>
Message-ID: <dWa3OMCxj72XyyHuy-2sQ3usN_rhpYZl4AOdJH87f-s=.34164d26-b3f3-495e-b505-f7fe96170eea@github.com>

On Fri, 22 Mar 2024 17:58:36 GMT, Vladimir Kozlov <kvn 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 10 commits:
>> 
>>  - Catching up with changes in master
>>  - Catching up with origin/master
>>  - Catch up with origin/master
>>  - Merge with origin/master
>>  - Fix build, copyright dates, m4 files.
>>  - 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.
>
> GHA shows issue with Aarch64 builds on MacOS and Windows:
> 
> d:\a\jdk\jdk\build\windows-aarch64\hotspot\variant-server\gensrc\adfiles\ad_aarch64.cpp(24257): error C2653: 'CompiledStaticCall': is not a class or namespace name
> d:\a\jdk\jdk\build\windows-aarch64\hotspot\variant-server\gensrc\adfiles\ad_aarch64.cpp(24257): error C3861: 'emit_to_interp_stub': identifier not found

@vnkozlov - I was working on that. It was because of a typo. Now it's fixed.

Can I please get more reviews on this? Pinging port maintainer: /cc @theRealAph @nick-arm @bulasevich @snazarkin @offamitkumar @RealLucy

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

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

From kdnilsen at openjdk.org  Fri Mar 22 18:27:43 2024
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Fri, 22 Mar 2024 18:27:43 GMT
Subject: RFR: 8327097: GenShen: Align PLAB sizes down rather than up [v6]
In-Reply-To: <vMzXnpkq505CMSPZRUhOCmMcEdKor4OhjbOfv6WwcZo=.4a5ddd00-2111-41ec-9f3f-577fe279f77d@github.com>
References: <ubIf-lmCiowlGhyHfBvq-zudoKSzp6MWHaB9UZh5FuM=.27238aa1-a55b-4a19-9cac-e9c4de961613@github.com>
 <f6x1UgGNOMAnvMGbsFeJ7k5VD6BGmDd6AmeCjqhTIHs=.22cdd3c5-112d-4360-bdea-13ec43edeb18@github.com>
 <vMzXnpkq505CMSPZRUhOCmMcEdKor4OhjbOfv6WwcZo=.4a5ddd00-2111-41ec-9f3f-577fe279f77d@github.com>
Message-ID: <EE6zzohCDtHpryiyS1x-uIswCZFmqODO7XIRUTWtDaY=.b157b5d1-88c8-450c-962a-e30b97c26b74@github.com>

On Wed, 20 Mar 2024 23:06:37 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

>> Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add comments to clarify behavior of retire_plab
>
> src/hotspot/share/gc/shenandoah/shenandoahHeapRegion.inline.hpp line 46:
> 
>> 44: 
>> 45:   HeapWord* orig_top = top();
>> 46:   size_t addr_as_int = (uintptr_t) orig_top;
> 
> addr_as_int isn't needed anymore, and can be deleted?

Thanks.  Removed.

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

PR Review Comment: https://git.openjdk.org/shenandoah/pull/401#discussion_r1536015578

From kdnilsen at openjdk.org  Fri Mar 22 18:27:43 2024
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Fri, 22 Mar 2024 18:27:43 GMT
Subject: RFR: 8327097: GenShen: Align PLAB sizes down rather than up [v6]
In-Reply-To: <1O0uvcK1cESA11YxpzyPhC8Devc8RWWhc17b4gyGjug=.25e1d095-0396-4bc6-84bc-4bdd340417fb@github.com>
References: <ubIf-lmCiowlGhyHfBvq-zudoKSzp6MWHaB9UZh5FuM=.27238aa1-a55b-4a19-9cac-e9c4de961613@github.com>
 <f6x1UgGNOMAnvMGbsFeJ7k5VD6BGmDd6AmeCjqhTIHs=.22cdd3c5-112d-4360-bdea-13ec43edeb18@github.com>
 <vMzXnpkq505CMSPZRUhOCmMcEdKor4OhjbOfv6WwcZo=.4a5ddd00-2111-41ec-9f3f-577fe279f77d@github.com>
 <1O0uvcK1cESA11YxpzyPhC8Devc8RWWhc17b4gyGjug=.25e1d095-0396-4bc6-84bc-4bdd340417fb@github.com>
Message-ID: <FLvLakjW_aI1F6GYpu7KftreGjg94K32DI9SaCXvLvk=.b8c22324-ebe6-42ce-91cc-7e6418654674@github.com>

On Wed, 20 Mar 2024 23:30:42 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

>> src/hotspot/share/gc/shenandoah/shenandoahHeapRegion.inline.hpp line 54:
>> 
>>> 52:   HeapWord* aligned_obj = (HeapWord*) align_up(orig_top, alignment_in_bytes);
>>> 53:   size_t pad_words = aligned_obj - orig_top;
>>> 54:   if (pad_words > 0) {
>> 
>> Can probably just && and fold together the two if tests.
>
> if (pad_words > 0 && pad_words < ShenandoahHeap::min_fill_size()) {
>    // shift allocation right by another unit of alignment to accommodate pad for filler
>    pad_words += alignment_in_words;
>    aligned_obj += alignment_in_words;
> }

Thanks.  Done.

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

PR Review Comment: https://git.openjdk.org/shenandoah/pull/401#discussion_r1536016414

From kdnilsen at openjdk.org  Fri Mar 22 18:35:47 2024
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Fri, 22 Mar 2024 18:35:47 GMT
Subject: RFR: 8327097: GenShen: Align PLAB sizes down rather than up [v6]
In-Reply-To: <1O0uvcK1cESA11YxpzyPhC8Devc8RWWhc17b4gyGjug=.25e1d095-0396-4bc6-84bc-4bdd340417fb@github.com>
References: <ubIf-lmCiowlGhyHfBvq-zudoKSzp6MWHaB9UZh5FuM=.27238aa1-a55b-4a19-9cac-e9c4de961613@github.com>
 <f6x1UgGNOMAnvMGbsFeJ7k5VD6BGmDd6AmeCjqhTIHs=.22cdd3c5-112d-4360-bdea-13ec43edeb18@github.com>
 <vMzXnpkq505CMSPZRUhOCmMcEdKor4OhjbOfv6WwcZo=.4a5ddd00-2111-41ec-9f3f-577fe279f77d@github.com>
 <1O0uvcK1cESA11YxpzyPhC8Devc8RWWhc17b4gyGjug=.25e1d095-0396-4bc6-84bc-4bdd340417fb@github.com>
Message-ID: <z-WqzLHtadWz4yWnvZuU94CAKL2Zn5fdcARCiN7fHKE=.f59a411d-1148-42aa-91fa-62b4cfd2ba6b@github.com>

On Wed, 20 Mar 2024 23:38:30 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

>> src/hotspot/share/gc/shenandoah/shenandoahHeapRegion.inline.hpp line 52:
>> 
>>> 50:   // from alignment_in_words to determine padding required to next alignment point.
>>> 51: 
>>> 52:   HeapWord* aligned_obj = (HeapWord*) align_up(orig_top, alignment_in_bytes);
>> 
>> I think this method's declaration `allocate_aligned(...)` in the `.hpp` uses `alignment_in_words` as the name of the second parm. Similarly the comment in the header. Those should be corrected too to say `alignment_in_bytes`.
>
> We do know that this is alignment must be a mutiple of HeapWordSize (as demonstrated by the integer division you do further above). I'd just assert for the sake of peace of mind from an API perspective that this is always so by:
> 
> assert(is_aligned(alignment_in_bytes, HeapWordSize), "Expected heap word alignment");

Good catch.  Correcting the name in the header and in comment.  Adding the suggested assert.

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

PR Review Comment: https://git.openjdk.org/shenandoah/pull/401#discussion_r1536025440

From kdnilsen at openjdk.org  Fri Mar 22 18:42:01 2024
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Fri, 22 Mar 2024 18:42:01 GMT
Subject: RFR: 8327097: GenShen: Align PLAB sizes down rather than up [v8]
In-Reply-To: <ubIf-lmCiowlGhyHfBvq-zudoKSzp6MWHaB9UZh5FuM=.27238aa1-a55b-4a19-9cac-e9c4de961613@github.com>
References: <ubIf-lmCiowlGhyHfBvq-zudoKSzp6MWHaB9UZh5FuM=.27238aa1-a55b-4a19-9cac-e9c4de961613@github.com>
Message-ID: <vN9gVFMhOR90yGGTxfARRr55IHS-Mw3IqR2ksl0rN3Y=.28af48ce-a07b-45e7-8836-90be0a8df5f0@github.com>

> When adjusting LAB sizes, round down rather than rounding up.  Otherwise, we may violate the ShenandoahHumongousThreshold bound.

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

  Respond to reviewer feedback

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

Changes:
  - all: https://git.openjdk.org/shenandoah/pull/401/files
  - new: https://git.openjdk.org/shenandoah/pull/401/files/77663512..1e28350f

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

  Stats: 48 lines in 6 files changed: 7 ins; 16 del; 25 mod
  Patch: https://git.openjdk.org/shenandoah/pull/401.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah.git pull/401/head:pull/401

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

From kdnilsen at openjdk.org  Fri Mar 22 18:54:45 2024
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Fri, 22 Mar 2024 18:54:45 GMT
Subject: RFR: 8327097: GenShen: Align PLAB sizes down rather than up [v9]
In-Reply-To: <ubIf-lmCiowlGhyHfBvq-zudoKSzp6MWHaB9UZh5FuM=.27238aa1-a55b-4a19-9cac-e9c4de961613@github.com>
References: <ubIf-lmCiowlGhyHfBvq-zudoKSzp6MWHaB9UZh5FuM=.27238aa1-a55b-4a19-9cac-e9c4de961613@github.com>
Message-ID: <yGj73YjwrsmM-rUk2UemQUHU9fSf4uYxNiqzewL41W0=.1c31fa5f-587f-43a8-bd86-b02e5c5fc7b9@github.com>

> When adjusting LAB sizes, round down rather than rounding up.  Otherwise, we may violate the ShenandoahHumongousThreshold bound.

Kelvin Nilsen has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 28 commits:

 - Merge branch 'master' of https://git.openjdk.org/shenandoah into enforce-humongous-threshold-on-tlab
 - Respond to reviewer feedback
 - Fix up a few other places where PLAB min size or current size gets set
   
   This may explain how unaligned sizes were being detected by existing
   assertions.
 - Add comments to clarify behavior of retire_plab
 - Do not align_up size of object allocated in plab slow
   
   Align the plab size, but not the size of the object to be allocated within the plab.
   If we increase the size of the allocated object, this creates confusion in that the
   object's size reported by its header does not span all of the bytes allocated for the
   object, so the memory is not parsable during remembered set scanning.
 - Force size to align up
   
   A newly allocated PLAB needs, at minimum, to be as large as the object
   that is goign to be allocated from within it.
 - Disable TestHumongousThreshold test on generic-all for now
   
   This has experienced timeout failures on multiple platforms.
 - Cleanup code in response to reviewer feedback
 - Add comment to explain requirement for PLAB alignment
 - Assure PLAB alignment by construction rather than fixup
 - ... and 18 more: https://git.openjdk.org/shenandoah/compare/71fc4c81...b0cba3e8

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

Changes: https://git.openjdk.org/shenandoah/pull/401/files
  Webrev: https://webrevs.openjdk.org/?repo=shenandoah&pr=401&range=08
  Stats: 122 lines in 9 files changed: 46 ins; 32 del; 44 mod
  Patch: https://git.openjdk.org/shenandoah/pull/401.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah.git pull/401/head:pull/401

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

From wkemper at openjdk.org  Fri Mar 22 20:57:35 2024
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 22 Mar 2024 20:57:35 GMT
Subject: RFR: Merge openjdk/jdk:master [v2]
In-Reply-To: <HgFAcSGUcLkt_mP0HAT7r_Tkhgs2fwoxUVq-SYnEq0g=.b0f4b0b4-154f-46bb-b238-d917cd58ee2f@github.com>
References: <HgFAcSGUcLkt_mP0HAT7r_Tkhgs2fwoxUVq-SYnEq0g=.b0f4b0b4-154f-46bb-b238-d917cd58ee2f@github.com>
Message-ID: <rSeGOKyWwlEAffx0uLHNQWaGXuLXCI2nhX9Aq2kG27E=.0e0e4d95-3f9e-4bcf-8b39-06720fa5b32c@github.com>

> Merges tag jdk-23+14

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

 - Merge branch 'shenandoah-master' into merge-jdk-23+14
 - 8325885: GenShen: harmonize with JDK-8325671
   
   Reviewed-by: kdnilsen
 - 8325808: GenShen: Move generational mode code out of shFullGC.cpp
   
   Reviewed-by: ysr, kdnilsen
 - 8326626: GenShen: Remove dead code associated with non-elastic TLABS
   
   Reviewed-by: wkemper, shade
 - 8324067: GenShen: Isolate regulator thread to generational mode
   
   Reviewed-by: kdnilsen, ysr
 - 8325670: GenShen: Allow old to expand at end of each GC
   
   Reviewed-by: ysr
 - Merge
 - Merge
 - Merge
 - Merge
 - ... and 380 more: https://git.openjdk.org/shenandoah/compare/6f2676dc...71b112c3

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

Changes: https://git.openjdk.org/shenandoah/pull/408/files
  Webrev: https://webrevs.openjdk.org/?repo=shenandoah&pr=408&range=01
  Stats: 22417 lines in 224 files changed: 20567 ins; 976 del; 874 mod
  Patch: https://git.openjdk.org/shenandoah/pull/408.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah.git pull/408/head:pull/408

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

From wkemper at openjdk.org  Fri Mar 22 20:57:37 2024
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 22 Mar 2024 20:57:37 GMT
Subject: Integrated: Merge openjdk/jdk:master
In-Reply-To: <HgFAcSGUcLkt_mP0HAT7r_Tkhgs2fwoxUVq-SYnEq0g=.b0f4b0b4-154f-46bb-b238-d917cd58ee2f@github.com>
References: <HgFAcSGUcLkt_mP0HAT7r_Tkhgs2fwoxUVq-SYnEq0g=.b0f4b0b4-154f-46bb-b238-d917cd58ee2f@github.com>
Message-ID: <YNiJdkf75U84x7Sk2uY8qnpotYhjCuTGdT13nytsgac=.61d4ffa1-80d9-4a5a-8d4a-1b686a006808@github.com>

On Fri, 15 Mar 2024 14:10:15 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Merges tag jdk-23+14

This pull request has now been integrated.

Changeset: 2e788b98
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.org/shenandoah/commit/2e788b98e40d1ccc523eb5ce27584ac640872523
Stats:     118798 lines in 2512 files changed: 27172 ins; 82679 del; 8947 mod

Merge

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

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

From kvn at openjdk.org  Fri Mar 22 21:34:35 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Fri, 22 Mar 2024 21:34:35 GMT
Subject: RFR: JDK-8241503: C2: Share MacroAssembler between mach nodes
 during code emission [v10]
In-Reply-To: <b0kJcywc9OD_TrAq6FJ9bvHE5WeiCD2hXXItkoseuIk=.e7d36d93-0f5f-4139-b0fd-ec2370f0cdef@github.com>
References: <ExCrwPns55nw2P62UI3vzSVTmFCh3dzJq7u3Kugp9EA=.c20cd86c-2c16-4869-ba7f-76f2a53821d0@github.com>
 <b0kJcywc9OD_TrAq6FJ9bvHE5WeiCD2hXXItkoseuIk=.e7d36d93-0f5f-4139-b0fd-ec2370f0cdef@github.com>
Message-ID: <xZyq205TJHpeWpuLDya-wewgUPrI7JA1dZ8e2ONkZHI=.e500e673-b572-4a2a-a8c6-d7c3ff632d63@github.com>

On Fri, 22 Mar 2024 18:19:39 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`.
>
> Cesar Soares Lucas has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix AArch64 build & improve comment about InstructionMark

Good. `StringRepeat.java` GHA failure on linux-x86 is due to `JDK-8328524`.
I will submit our testing.

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

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

From kdnilsen at openjdk.org  Fri Mar 22 21:56:00 2024
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Fri, 22 Mar 2024 21:56:00 GMT
Subject: RFR: 8327097: GenShen: Align PLAB sizes down rather than up [v10]
In-Reply-To: <ubIf-lmCiowlGhyHfBvq-zudoKSzp6MWHaB9UZh5FuM=.27238aa1-a55b-4a19-9cac-e9c4de961613@github.com>
References: <ubIf-lmCiowlGhyHfBvq-zudoKSzp6MWHaB9UZh5FuM=.27238aa1-a55b-4a19-9cac-e9c4de961613@github.com>
Message-ID: <zTmoCfP8MXUKSu7HU9e3yUOuOs-kYgq5XJZGcASq9iY=.af6b6264-6956-4b2e-aa9e-7552d48c4210@github.com>

> When adjusting LAB sizes, round down rather than rounding up.  Otherwise, we may violate the ShenandoahHumongousThreshold bound.

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

  Fix up initialization of min_plab_size and max_plab_size

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

Changes:
  - all: https://git.openjdk.org/shenandoah/pull/401/files
  - new: https://git.openjdk.org/shenandoah/pull/401/files/b0cba3e8..2a4c62c2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=shenandoah&pr=401&range=09
 - incr: https://webrevs.openjdk.org/?repo=shenandoah&pr=401&range=08-09

  Stats: 27 lines in 3 files changed: 16 ins; 5 del; 6 mod
  Patch: https://git.openjdk.org/shenandoah/pull/401.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah.git pull/401/head:pull/401

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

From lucy at openjdk.org  Fri Mar 22 22:18:28 2024
From: lucy at openjdk.org (Lutz Schmidt)
Date: Fri, 22 Mar 2024 22:18:28 GMT
Subject: RFR: JDK-8241503: C2: Share MacroAssembler between mach nodes
 during code emission
In-Reply-To: <Dz7JboYxdUGDNp9RB4BZ-WF0W1b0NY4kK67zNWeWoY0=.ecd40213-e618-4e29-8249-7ff0bd4f52fb@github.com>
References: <ExCrwPns55nw2P62UI3vzSVTmFCh3dzJq7u3Kugp9EA=.c20cd86c-2c16-4869-ba7f-76f2a53821d0@github.com>
 <yMm8dccKyhmu3glz-hLgP8V81EYvwFASjEUItwKGlHI=.692202d3-87e0-4c0e-9daf-1b4df9af36b9@github.com>
 <Dz7JboYxdUGDNp9RB4BZ-WF0W1b0NY4kK67zNWeWoY0=.ecd40213-e618-4e29-8249-7ff0bd4f52fb@github.com>
Message-ID: <5xA2kMNs7192Stj4n4ZJh4WfnT2gAoVpHbNhw6pdszM=.54bd1982-f4e0-4935-b7b8-2b0dab2a4a42@github.com>

On Sat, 16 Dec 2023 05:03:20 GMT, Amit Kumar <amitkumar at openjdk.org> wrote:

>> `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)
>
>>@offamitkumar, @TheRealMDoerr - can you please re-run the tests on the platforms convenient for you?
> 
> I run build for fastdebug & release VMs and tier1 test for fastdebug VM. Everything seems good.

Sorry, became aware of this only now. I will try to set aside some spare time. @offamitkumar can you please run some tests on the PR?

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

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

From kdnilsen at openjdk.org  Fri Mar 22 22:47:41 2024
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Fri, 22 Mar 2024 22:47:41 GMT
Subject: RFR: 8328626: GenShen: Combine old generation surplus/deficit
 fields into a single balance field [v2]
In-Reply-To: <RoEjBTu1PWGPYYaw2AHkRotvJHbIlz6dqQCxY3Ke8kg=.cb557aa6-826f-4a59-8456-c6f3becf8dce@github.com>
References: <aoGfU4G3UAbcCMY1yHupTPG1yAf9wQbJ6C1kZ6T7K6Q=.4324cfc3-d477-4e68-b73b-4f38b59b2277@github.com>
 <RoEjBTu1PWGPYYaw2AHkRotvJHbIlz6dqQCxY3Ke8kg=.cb557aa6-826f-4a59-8456-c6f3becf8dce@github.com>
Message-ID: <Nvp1g6W08D5HLZmbfNVDtu1AGzyS-xKHSWWPAwgrJAY=.1f39480b-7111-4344-baa6-656f513d7aa9@github.com>

On Fri, 22 Mar 2024 17:44:02 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> This is a follow up to https://github.com/openjdk/shenandoah/pull/406.
>
> William Kemper has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Fix zero build
>  - Fix comments

Marked as reviewed by kdnilsen (Committer).

src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp line 1185:

> 1183: void ShenandoahFreeSet::compute_young_and_old_reserves(size_t young_cset_regions, size_t old_cset_regions,
> 1184:                                                        bool have_evacuation_reserves, size_t* young_reserve_result,
> 1185:                                                        size_t* old_reserve_result) const {

Might read more "naturally" if args declared as:

size_t& young_reserve_result, size_t& old_reserve_result

src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp line 1220:

> 1218:   // All allocations taken from the old collector set are performed by GC, generally using PLABs for both
> 1219:   // promotions and evacuations.  The partition between which old memory is reserved for evacuation and
> 1220:   // which is reserved for promotion is enforced using thread-local variables that prescribe intentons for

typo: intentions

src/hotspot/share/gc/shenandoah/shenandoahGenerationalHeap.cpp line 128:

> 126: 
> 127:   if (old_region_balance > 0) {
> 128:     const auto old_region_surplus = checked_cast<size_t>(old_region_balance);

Just curious: what happens with a checked_cast<size_t> if old_region_balance < 0.  (I see that's impossible here, but what is the point of declaring checked_cast?)

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

PR Review: https://git.openjdk.org/shenandoah/pull/410#pullrequestreview-1955894108
PR Review Comment: https://git.openjdk.org/shenandoah/pull/410#discussion_r1536285718
PR Review Comment: https://git.openjdk.org/shenandoah/pull/410#discussion_r1536284815
PR Review Comment: https://git.openjdk.org/shenandoah/pull/410#discussion_r1536286804

From kdnilsen at openjdk.org  Fri Mar 22 22:51:58 2024
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Fri, 22 Mar 2024 22:51:58 GMT
Subject: RFR: 8327097: GenShen: Align PLAB sizes down rather than up [v11]
In-Reply-To: <ubIf-lmCiowlGhyHfBvq-zudoKSzp6MWHaB9UZh5FuM=.27238aa1-a55b-4a19-9cac-e9c4de961613@github.com>
References: <ubIf-lmCiowlGhyHfBvq-zudoKSzp6MWHaB9UZh5FuM=.27238aa1-a55b-4a19-9cac-e9c4de961613@github.com>
Message-ID: <7k-Wl3kDdKN41TImSF5e5ztKTwzTIPub8X5pyu3zVDA=.65c0abd6-9641-412a-8bae-b169737639b8@github.com>

> When adjusting LAB sizes, round down rather than rounding up.  Otherwise, we may violate the ShenandoahHumongousThreshold bound.

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

  Add include to resolve undeclared enum

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

Changes:
  - all: https://git.openjdk.org/shenandoah/pull/401/files
  - new: https://git.openjdk.org/shenandoah/pull/401/files/2a4c62c2..2cb710d0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=shenandoah&pr=401&range=10
 - incr: https://webrevs.openjdk.org/?repo=shenandoah&pr=401&range=09-10

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

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

From ysr at openjdk.org  Sat Mar 23 02:32:41 2024
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Sat, 23 Mar 2024 02:32:41 GMT
Subject: RFR: 8328626: GenShen: Combine old generation surplus/deficit
 fields into a single balance field [v2]
In-Reply-To: <RoEjBTu1PWGPYYaw2AHkRotvJHbIlz6dqQCxY3Ke8kg=.cb557aa6-826f-4a59-8456-c6f3becf8dce@github.com>
References: <aoGfU4G3UAbcCMY1yHupTPG1yAf9wQbJ6C1kZ6T7K6Q=.4324cfc3-d477-4e68-b73b-4f38b59b2277@github.com>
 <RoEjBTu1PWGPYYaw2AHkRotvJHbIlz6dqQCxY3Ke8kg=.cb557aa6-826f-4a59-8456-c6f3becf8dce@github.com>
Message-ID: <gMYMYnxIS_plH2qNB9zQGXNTj8_D0jsG0mLJ_ADFbF4=.bb5be943-d08e-414a-9883-7c428de3ca07@github.com>

On Fri, 22 Mar 2024 17:44:02 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> This is a follow up to https://github.com/openjdk/shenandoah/pull/406.
>
> William Kemper has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Fix zero build
>  - Fix comments

A few suggestions that might lead to further simplifications, it would seem. Let me know if that is not the case for some reason.

The rest of the changes look good to me, so I am approving the changes, with the suggested changes as something to look into.

If those suggested changes should work out, I'll be happy to do a rereview.

Thanks for the cleanup & refactoring of the code; it feels more compact, and easier to understand and to maintain.

src/hotspot/share/gc/shenandoah/shenandoahGenerationalHeap.cpp line 136:

> 134: 
> 135:   if (old_region_balance < 0) {
> 136:     const auto old_region_deficit = checked_cast<size_t>(-old_region_balance);

Like I remarked elsewhere, the code in the if > 0 and if < 0 branches (or if you will, the if and else branches) are largely isomorphic, and can probably be folded together by calling a generic `transfer_from_old(ssize_t num_regions)` on ShenandoahGenerationSizer. The latter new method would be a folding together of the old methods `transfer_to_young()` and `transfer_to_old()`, and would return the `TransferResult` that this method `balance_generations` returns to its caller.

src/hotspot/share/gc/shenandoah/shenandoahGenerationalHeap.cpp line 242:

> 240:     // curtailed if the budget is restricted.
> 241:     old_region_deficit = MIN2(old_region_deficit, max_old_region_xfer);
> 242:     old_generation()->set_region_balance(0 - checked_cast<ssize_t>(old_region_deficit));

The code in the if and the else branches is highly isomorphic. I have the feeling you may be able to fold them together, but I am not sure how clean it will be. Also if you start with `ssize_t` for some of the operands that feed into the surplus calculation (or balance if you will, but we can call it surplus wit the understanding that a negative surplus is a deficit), then you may be able to avoid some of the later casts and the signing of unsigned quantities, including the `(cast)x`, `-(cast)x` or `0-(cast)x`constructs above.

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

Marked as reviewed by ysr (Committer).

PR Review: https://git.openjdk.org/shenandoah/pull/410#pullrequestreview-1956280101
PR Review Comment: https://git.openjdk.org/shenandoah/pull/410#discussion_r1536542143
PR Review Comment: https://git.openjdk.org/shenandoah/pull/410#discussion_r1536540579

From kdnilsen at openjdk.org  Sat Mar 23 03:51:08 2024
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Sat, 23 Mar 2024 03:51:08 GMT
Subject: RFR: 8327097: GenShen: Align PLAB sizes down rather than up [v12]
In-Reply-To: <ubIf-lmCiowlGhyHfBvq-zudoKSzp6MWHaB9UZh5FuM=.27238aa1-a55b-4a19-9cac-e9c4de961613@github.com>
References: <ubIf-lmCiowlGhyHfBvq-zudoKSzp6MWHaB9UZh5FuM=.27238aa1-a55b-4a19-9cac-e9c4de961613@github.com>
Message-ID: <_T1XSpUB52PI1Yw21fsO01Zob50GqyAkTOrOIxs0TYA=.88bc400b-d177-4b77-9aa6-7c96ffe54f0e@github.com>

> When adjusting LAB sizes, round down rather than rounding up.  Otherwise, we may violate the ShenandoahHumongousThreshold bound.

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

  Add detail to log message to help with debugging

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

Changes:
  - all: https://git.openjdk.org/shenandoah/pull/401/files
  - new: https://git.openjdk.org/shenandoah/pull/401/files/2cb710d0..ecd6615f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=shenandoah&pr=401&range=11
 - incr: https://webrevs.openjdk.org/?repo=shenandoah&pr=401&range=10-11

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

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

From kvn at openjdk.org  Sat Mar 23 16:15:32 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Sat, 23 Mar 2024 16:15:32 GMT
Subject: RFR: JDK-8241503: C2: Share MacroAssembler between mach nodes
 during code emission [v10]
In-Reply-To: <b0kJcywc9OD_TrAq6FJ9bvHE5WeiCD2hXXItkoseuIk=.e7d36d93-0f5f-4139-b0fd-ec2370f0cdef@github.com>
References: <ExCrwPns55nw2P62UI3vzSVTmFCh3dzJq7u3Kugp9EA=.c20cd86c-2c16-4869-ba7f-76f2a53821d0@github.com>
 <b0kJcywc9OD_TrAq6FJ9bvHE5WeiCD2hXXItkoseuIk=.e7d36d93-0f5f-4139-b0fd-ec2370f0cdef@github.com>
Message-ID: <EwTB67xQmmf9l9afFHSTzVVEAbj4Qa3h5FuBRZiJfmg=.3664959d-1d30-4e4f-b39b-3c0354a97095@github.com>

On Fri, 22 Mar 2024 18:19:39 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`.
>
> Cesar Soares Lucas has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix AArch64 build & improve comment about InstructionMark

My tier1-3,xcomp,stress testing passed. We test on x64 and aarch64 only.

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

Marked as reviewed by kvn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16484#pullrequestreview-1956401778

From fyang at openjdk.org  Mon Mar 25 02:09:25 2024
From: fyang at openjdk.org (Fei Yang)
Date: Mon, 25 Mar 2024 02:09:25 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: <fGYjlYSnK1m3t2zsfo6vZgaMFEKN192J0yU1Ts7xDGg=.0424ca7f-0edd-44f1-9c85-85665435249a@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.

Thanks for the update. The RISC-V part looks fine to me. I did release release build and ran tier1-3 tests on linux-riscv64 platform.

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

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

From wkemper at openjdk.org  Mon Mar 25 16:15:44 2024
From: wkemper at openjdk.org (William Kemper)
Date: Mon, 25 Mar 2024 16:15:44 GMT
Subject: RFR: 8328626: GenShen: Combine old generation surplus/deficit
 fields into a single balance field [v2]
In-Reply-To: <Nvp1g6W08D5HLZmbfNVDtu1AGzyS-xKHSWWPAwgrJAY=.1f39480b-7111-4344-baa6-656f513d7aa9@github.com>
References: <aoGfU4G3UAbcCMY1yHupTPG1yAf9wQbJ6C1kZ6T7K6Q=.4324cfc3-d477-4e68-b73b-4f38b59b2277@github.com>
 <RoEjBTu1PWGPYYaw2AHkRotvJHbIlz6dqQCxY3Ke8kg=.cb557aa6-826f-4a59-8456-c6f3becf8dce@github.com>
 <Nvp1g6W08D5HLZmbfNVDtu1AGzyS-xKHSWWPAwgrJAY=.1f39480b-7111-4344-baa6-656f513d7aa9@github.com>
Message-ID: <y_tffPYT1uoKfgM3g_F_AkrFwMkiiUjOTn4NhEuTluQ=.1cc973f5-eb23-4e46-aab9-1f0e7231bd2e@github.com>

On Fri, 22 Mar 2024 22:42:45 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> William Kemper has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Fix zero build
>>  - Fix comments
>
> src/hotspot/share/gc/shenandoah/shenandoahGenerationalHeap.cpp line 128:
> 
>> 126: 
>> 127:   if (old_region_balance > 0) {
>> 128:     const auto old_region_surplus = checked_cast<size_t>(old_region_balance);
> 
> Just curious: what happens with a checked_cast<size_t> if old_region_balance < 0.  (I see that's impossible here, but what is the point of declaring checked_cast?)

`checked_cast` asserts that the cast did not change the value, defined here: https://github.com/openjdk/shenandoah/blob/master/src/hotspot/share/utilities/checkedCast.hpp#L39. If `old_region_balance` were less than zero, it would assert out. It will also assert out if `old_region_balance` were greater than `SSIZE_MAX`. Which is unlikely, but there is no harm in checking.

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

PR Review Comment: https://git.openjdk.org/shenandoah/pull/410#discussion_r1537855598

From wkemper at openjdk.org  Mon Mar 25 16:20:35 2024
From: wkemper at openjdk.org (William Kemper)
Date: Mon, 25 Mar 2024 16:20:35 GMT
Subject: RFR: 8328626: GenShen: Combine old generation surplus/deficit
 fields into a single balance field [v2]
In-Reply-To: <Nvp1g6W08D5HLZmbfNVDtu1AGzyS-xKHSWWPAwgrJAY=.1f39480b-7111-4344-baa6-656f513d7aa9@github.com>
References: <aoGfU4G3UAbcCMY1yHupTPG1yAf9wQbJ6C1kZ6T7K6Q=.4324cfc3-d477-4e68-b73b-4f38b59b2277@github.com>
 <RoEjBTu1PWGPYYaw2AHkRotvJHbIlz6dqQCxY3Ke8kg=.cb557aa6-826f-4a59-8456-c6f3becf8dce@github.com>
 <Nvp1g6W08D5HLZmbfNVDtu1AGzyS-xKHSWWPAwgrJAY=.1f39480b-7111-4344-baa6-656f513d7aa9@github.com>
Message-ID: <-tvFiDzz5eX5-FBO0Kb2ZeNiLvufB9uKqiLxy2aguAw=.9d9fe7ad-0f36-49d3-95f1-fc5ccf961fe7@github.com>

On Fri, 22 Mar 2024 22:40:22 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> William Kemper has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Fix zero build
>>  - Fix comments
>
> src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp line 1185:
> 
>> 1183: void ShenandoahFreeSet::compute_young_and_old_reserves(size_t young_cset_regions, size_t old_cset_regions,
>> 1184:                                                        bool have_evacuation_reserves, size_t* young_reserve_result,
>> 1185:                                                        size_t* old_reserve_result) const {
> 
> Might read more "naturally" if args declared as:
> 
> size_t& young_reserve_result, size_t& old_reserve_result

Hmm, I usually see 'result' parameters like this passed as pointers in the JDK. It makes it clearer at the call site. Or did you mean to format them on the same line?

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

PR Review Comment: https://git.openjdk.org/shenandoah/pull/410#discussion_r1537861719

From wkemper at openjdk.org  Mon Mar 25 16:27:36 2024
From: wkemper at openjdk.org (William Kemper)
Date: Mon, 25 Mar 2024 16:27:36 GMT
Subject: RFR: 8328626: GenShen: Combine old generation surplus/deficit
 fields into a single balance field [v2]
In-Reply-To: <-tvFiDzz5eX5-FBO0Kb2ZeNiLvufB9uKqiLxy2aguAw=.9d9fe7ad-0f36-49d3-95f1-fc5ccf961fe7@github.com>
References: <aoGfU4G3UAbcCMY1yHupTPG1yAf9wQbJ6C1kZ6T7K6Q=.4324cfc3-d477-4e68-b73b-4f38b59b2277@github.com>
 <RoEjBTu1PWGPYYaw2AHkRotvJHbIlz6dqQCxY3Ke8kg=.cb557aa6-826f-4a59-8456-c6f3becf8dce@github.com>
 <Nvp1g6W08D5HLZmbfNVDtu1AGzyS-xKHSWWPAwgrJAY=.1f39480b-7111-4344-baa6-656f513d7aa9@github.com>
 <-tvFiDzz5eX5-FBO0Kb2ZeNiLvufB9uKqiLxy2aguAw=.9d9fe7ad-0f36-49d3-95f1-fc5ccf961fe7@github.com>
Message-ID: <Qt1_pm6IeMUTA2A8qYWhcm4cHiBddu-NcmqypoCoEW4=.f1ddc5b4-1b63-431f-acfa-b73094aaeb36@github.com>

On Mon, 25 Mar 2024 16:17:58 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp line 1185:
>> 
>>> 1183: void ShenandoahFreeSet::compute_young_and_old_reserves(size_t young_cset_regions, size_t old_cset_regions,
>>> 1184:                                                        bool have_evacuation_reserves, size_t* young_reserve_result,
>>> 1185:                                                        size_t* old_reserve_result) const {
>> 
>> Might read more "naturally" if args declared as:
>> 
>> size_t& young_reserve_result, size_t& old_reserve_result
>
> Hmm, I usually see 'result' parameters like this passed as pointers in the JDK. It makes it clearer at the call site. Or did you mean to format them on the same line?

Never mind, I see this class uses references for such parameters. I'll change it for sake of consistency.

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

PR Review Comment: https://git.openjdk.org/shenandoah/pull/410#discussion_r1537871699

From wkemper at openjdk.org  Mon Mar 25 17:16:52 2024
From: wkemper at openjdk.org (William Kemper)
Date: Mon, 25 Mar 2024 17:16:52 GMT
Subject: RFR: 8328626: GenShen: Combine old generation surplus/deficit
 fields into a single balance field [v2]
In-Reply-To: <gMYMYnxIS_plH2qNB9zQGXNTj8_D0jsG0mLJ_ADFbF4=.bb5be943-d08e-414a-9883-7c428de3ca07@github.com>
References: <aoGfU4G3UAbcCMY1yHupTPG1yAf9wQbJ6C1kZ6T7K6Q=.4324cfc3-d477-4e68-b73b-4f38b59b2277@github.com>
 <RoEjBTu1PWGPYYaw2AHkRotvJHbIlz6dqQCxY3Ke8kg=.cb557aa6-826f-4a59-8456-c6f3becf8dce@github.com>
 <gMYMYnxIS_plH2qNB9zQGXNTj8_D0jsG0mLJ_ADFbF4=.bb5be943-d08e-414a-9883-7c428de3ca07@github.com>
Message-ID: <7wFaviRAFSQ61o_FdFC_g-dpSiEDPk-eQczPgTKArDc=.99d39430-9222-4317-870b-496b196499e9@github.com>

On Sat, 23 Mar 2024 02:10:59 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

>> William Kemper has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Fix zero build
>>  - Fix comments
>
> src/hotspot/share/gc/shenandoah/shenandoahGenerationalHeap.cpp line 242:
> 
>> 240:     // curtailed if the budget is restricted.
>> 241:     old_region_deficit = MIN2(old_region_deficit, max_old_region_xfer);
>> 242:     old_generation()->set_region_balance(0 - checked_cast<ssize_t>(old_region_deficit));
> 
> The code in the if and the else branches is highly isomorphic. I have the feeling you may be able to fold them together, but I am not sure how clean it will be. Also if you start with `ssize_t` for some of the operands that feed into the surplus calculation (or balance if you will, but we can call it surplus wit the understanding that a negative surplus is a deficit), then you may be able to avoid some of the later casts and the signing of unsigned quantities, including the `(cast)x`, `-(cast)x` or `0-(cast)x`constructs above.

I agree the code in the branches is similar, but the APIs we have for managing capacity for a generation will ultimately make us chose old or young for the source or destination of the transfer based on whether `old_region_balance` is positive or negative.

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

PR Review Comment: https://git.openjdk.org/shenandoah/pull/410#discussion_r1537941830

From wkemper at openjdk.org  Mon Mar 25 17:19:45 2024
From: wkemper at openjdk.org (William Kemper)
Date: Mon, 25 Mar 2024 17:19:45 GMT
Subject: RFR: 8328626: GenShen: Combine old generation surplus/deficit
 fields into a single balance field [v2]
In-Reply-To: <gMYMYnxIS_plH2qNB9zQGXNTj8_D0jsG0mLJ_ADFbF4=.bb5be943-d08e-414a-9883-7c428de3ca07@github.com>
References: <aoGfU4G3UAbcCMY1yHupTPG1yAf9wQbJ6C1kZ6T7K6Q=.4324cfc3-d477-4e68-b73b-4f38b59b2277@github.com>
 <RoEjBTu1PWGPYYaw2AHkRotvJHbIlz6dqQCxY3Ke8kg=.cb557aa6-826f-4a59-8456-c6f3becf8dce@github.com>
 <gMYMYnxIS_plH2qNB9zQGXNTj8_D0jsG0mLJ_ADFbF4=.bb5be943-d08e-414a-9883-7c428de3ca07@github.com>
Message-ID: <FD50CgxsgJi3gYDXvh4wUmXCz4y-MerYRclvzn4bs8E=.a4d020ef-eb14-4bcb-aae1-06581213e5d3@github.com>

On Sat, 23 Mar 2024 02:23:05 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

>> William Kemper has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Fix zero build
>>  - Fix comments
>
> src/hotspot/share/gc/shenandoah/shenandoahGenerationalHeap.cpp line 136:
> 
>> 134: 
>> 135:   if (old_region_balance < 0) {
>> 136:     const auto old_region_deficit = checked_cast<size_t>(-old_region_balance);
> 
> Like I remarked elsewhere, the code in the if > 0 and if < 0 branches (or if you will, the if and else branches) are largely isomorphic, and can probably be folded together by calling a generic `transfer_from_old(ssize_t num_regions)` on ShenandoahGenerationSizer. The latter new method would be a folding together of the old methods `transfer_to_young()` and `transfer_to_old()`, and would return the `TransferResult` that this method `balance_generations` returns to its caller.

By way of consolation, I was able to consolidate some related code in `ShenandoahGenerationSizer` and move additional generational specific code out of `ShenandoahHeap`.

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

PR Review Comment: https://git.openjdk.org/shenandoah/pull/410#discussion_r1537946356

From wkemper at openjdk.org  Mon Mar 25 18:03:06 2024
From: wkemper at openjdk.org (William Kemper)
Date: Mon, 25 Mar 2024 18:03:06 GMT
Subject: RFR: Merge openjdk/jdk:master [v2]
In-Reply-To: <7naay40eQj26BGLm-vHMFmJ5Kt7EcEV8dRx_VI-MEbU=.9d2c8c53-02cd-4b59-babc-3ad5072ffedf@github.com>
References: <7naay40eQj26BGLm-vHMFmJ5Kt7EcEV8dRx_VI-MEbU=.9d2c8c53-02cd-4b59-babc-3ad5072ffedf@github.com>
Message-ID: <J6Pm7RNVAXJq0ZORMzIS1fCYDcRKInBh1k8heHH5fwY=.3f37914b-56dd-4da3-afc2-09d1ee3de165@github.com>

> Merges tag jdk-23+15

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

 - Do not forward objects that don't move during a generational full GC
 - Merge branch 'shenandoah/master' into merge-jdk-23+15
 - 8328035: Convert javax/swing/text/html/TableView/7030332/bug7030332.java applet test to main
   
   Reviewed-by: abhiscxk, prr
 - 8328300: Convert PrintDialogsTest.java from Applet to main program
   
   Reviewed-by: psadhukhan, dnguyen
 - 8296244: Alternate implementation of user-based authorization Subject APIs that doesn?t depend on Security Manager APIs
   
   Reviewed-by: mullan
 - 8319251: [REDO] Change LockingMode default from LM_LEGACY to LM_LIGHTWEIGHT
   
   Reviewed-by: rkennke, dholmes
 - 8328379: Convert URLDragTest.html applet test to main
   
   Reviewed-by: abhiscxk, psadhukhan
 - 8326521: JFR: CompilerPhase event test fails on windows 32 bit
   
   Reviewed-by: egahlin
 - 8328225: Convert ImageDecoratedDnD.html applet test to main
   
   Reviewed-by: dnguyen, aivanov
 - 8328185: Convert java/awt/image/MemoryLeakTest/MemoryLeakTest.java applet test to main
   
   Reviewed-by: azvegint, honkar
 - ... and 105 more: https://git.openjdk.org/shenandoah/compare/2e788b98...b8d185ec

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

Changes: https://git.openjdk.org/shenandoah/pull/411/files
  Webrev: Webrev is not available because diff is too large
  Stats: 297143 lines in 518 files changed: 7612 ins; 7225 del; 282306 mod
  Patch: https://git.openjdk.org/shenandoah/pull/411.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah.git pull/411/head:pull/411

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

From wkemper at openjdk.org  Mon Mar 25 18:20:59 2024
From: wkemper at openjdk.org (William Kemper)
Date: Mon, 25 Mar 2024 18:20:59 GMT
Subject: RFR: 8328626: GenShen: Combine old generation surplus/deficit
 fields into a single balance field [v3]
In-Reply-To: <aoGfU4G3UAbcCMY1yHupTPG1yAf9wQbJ6C1kZ6T7K6Q=.4324cfc3-d477-4e68-b73b-4f38b59b2277@github.com>
References: <aoGfU4G3UAbcCMY1yHupTPG1yAf9wQbJ6C1kZ6T7K6Q=.4324cfc3-d477-4e68-b73b-4f38b59b2277@github.com>
Message-ID: <U3eImiPqC9Kosr33mD-b4sb6aZhi3ccWcf-43Yi5n8k=.9dcc84b7-0860-4936-a403-ebb7de00f4c8@github.com>

> This is a follow up to https://github.com/openjdk/shenandoah/pull/406.

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

 - Consolidate region transfer logic, move generational specific code out of ShenandoahHeap
 - Use pass by reference for consistency with other methods

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

Changes:
  - all: https://git.openjdk.org/shenandoah/pull/410/files
  - new: https://git.openjdk.org/shenandoah/pull/410/files/8ebe8b8c..d75de101

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

  Stats: 156 lines in 7 files changed: 52 ins; 75 del; 29 mod
  Patch: https://git.openjdk.org/shenandoah/pull/410.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah.git pull/410/head:pull/410

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

From ysr at openjdk.org  Mon Mar 25 20:01:41 2024
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Mon, 25 Mar 2024 20:01:41 GMT
Subject: RFR: 8328626: GenShen: Combine old generation surplus/deficit
 fields into a single balance field [v3]
In-Reply-To: <U3eImiPqC9Kosr33mD-b4sb6aZhi3ccWcf-43Yi5n8k=.9dcc84b7-0860-4936-a403-ebb7de00f4c8@github.com>
References: <aoGfU4G3UAbcCMY1yHupTPG1yAf9wQbJ6C1kZ6T7K6Q=.4324cfc3-d477-4e68-b73b-4f38b59b2277@github.com>
 <U3eImiPqC9Kosr33mD-b4sb6aZhi3ccWcf-43Yi5n8k=.9dcc84b7-0860-4936-a403-ebb7de00f4c8@github.com>
Message-ID: <gAYfw7R6hsaElUBAr6XY3k0zZhuBsZqvQP6N01jkpPE=.290e508f-848b-4519-a0bf-a9c3acb0faa6@github.com>

On Mon, 25 Mar 2024 18:20:59 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> This is a follow up to https://github.com/openjdk/shenandoah/pull/406.
>
> William Kemper has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Consolidate region transfer logic, move generational specific code out of ShenandoahHeap
>  - Use pass by reference for consistency with other methods

LGTM; thanks!

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

> 126:   void recalculate_min_max_young_length(size_t heap_region_count);
> 127: 
> 128:   bool transfer_regions(ShenandoahGeneration* src, ShenandoahGeneration* dst, size_t regions) const;

Transfer regions has a bit of nuance, in that it fails without affecting the transfer if the transfer won't succeed without violating source or destination size bounds. I'd explain when it returns true and when false in a documentation line here.

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

Marked as reviewed by ysr (Committer).

PR Review: https://git.openjdk.org/shenandoah/pull/410#pullrequestreview-1958652838
PR Review Comment: https://git.openjdk.org/shenandoah/pull/410#discussion_r1538154047

From ysr at openjdk.org  Mon Mar 25 20:01:41 2024
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Mon, 25 Mar 2024 20:01:41 GMT
Subject: RFR: 8328626: GenShen: Combine old generation surplus/deficit
 fields into a single balance field [v2]
In-Reply-To: <7wFaviRAFSQ61o_FdFC_g-dpSiEDPk-eQczPgTKArDc=.99d39430-9222-4317-870b-496b196499e9@github.com>
References: <aoGfU4G3UAbcCMY1yHupTPG1yAf9wQbJ6C1kZ6T7K6Q=.4324cfc3-d477-4e68-b73b-4f38b59b2277@github.com>
 <RoEjBTu1PWGPYYaw2AHkRotvJHbIlz6dqQCxY3Ke8kg=.cb557aa6-826f-4a59-8456-c6f3becf8dce@github.com>
 <gMYMYnxIS_plH2qNB9zQGXNTj8_D0jsG0mLJ_ADFbF4=.bb5be943-d08e-414a-9883-7c428de3ca07@github.com>
 <7wFaviRAFSQ61o_FdFC_g-dpSiEDPk-eQczPgTKArDc=.99d39430-9222-4317-870b-496b196499e9@github.com>
Message-ID: <ksB0nNOll7YzI5FWyBYzrTKI912NCNnTivxGtSMP7TI=.93183bcc-e833-4206-bc47-248917a27f7f@github.com>

On Mon, 25 Mar 2024 17:13:35 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> src/hotspot/share/gc/shenandoah/shenandoahGenerationalHeap.cpp line 242:
>> 
>>> 240:     // curtailed if the budget is restricted.
>>> 241:     old_region_deficit = MIN2(old_region_deficit, max_old_region_xfer);
>>> 242:     old_generation()->set_region_balance(0 - checked_cast<ssize_t>(old_region_deficit));
>> 
>> The code in the if and the else branches is highly isomorphic. I have the feeling you may be able to fold them together, but I am not sure how clean it will be. Also if you start with `ssize_t` for some of the operands that feed into the surplus calculation (or balance if you will, but we can call it surplus wit the understanding that a negative surplus is a deficit), then you may be able to avoid some of the later casts and the signing of unsigned quantities, including the `(cast)x`, `-(cast)x` or `0-(cast)x`constructs above.
>
> I agree the code in the branches is similar, but the APIs we have for managing capacity for a generation will ultimately make us chose old or young for the source or destination of the transfer based on whether `old_region_balance` is positive or negative.

Yes, I was thinking that the generation sizer could do that based on the sign of the balance.
But I realize that might not necessarily simplify the code, as you seem to have discovered. OK, thanks for checking.

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

PR Review Comment: https://git.openjdk.org/shenandoah/pull/410#discussion_r1538161758

From wkemper at openjdk.org  Mon Mar 25 20:53:10 2024
From: wkemper at openjdk.org (William Kemper)
Date: Mon, 25 Mar 2024 20:53:10 GMT
Subject: RFR: 8328626: GenShen: Combine old generation surplus/deficit
 fields into a single balance field [v4]
In-Reply-To: <aoGfU4G3UAbcCMY1yHupTPG1yAf9wQbJ6C1kZ6T7K6Q=.4324cfc3-d477-4e68-b73b-4f38b59b2277@github.com>
References: <aoGfU4G3UAbcCMY1yHupTPG1yAf9wQbJ6C1kZ6T7K6Q=.4324cfc3-d477-4e68-b73b-4f38b59b2277@github.com>
Message-ID: <dU0sLN8seAp9PNOgG-urH-3dvOT2YXRxBuZP1fhsZ0E=.a9d984ac-40bb-411d-8960-b935bea8a88f@github.com>

> This is a follow up to https://github.com/openjdk/shenandoah/pull/406.

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

  Update comments

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

Changes:
  - all: https://git.openjdk.org/shenandoah/pull/410/files
  - new: https://git.openjdk.org/shenandoah/pull/410/files/d75de101..e25db762

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

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

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

From wkemper at openjdk.org  Mon Mar 25 21:17:02 2024
From: wkemper at openjdk.org (William Kemper)
Date: Mon, 25 Mar 2024 21:17:02 GMT
Subject: RFR: 8328626: GenShen: Combine old generation surplus/deficit
 fields into a single balance field [v5]
In-Reply-To: <aoGfU4G3UAbcCMY1yHupTPG1yAf9wQbJ6C1kZ6T7K6Q=.4324cfc3-d477-4e68-b73b-4f38b59b2277@github.com>
References: <aoGfU4G3UAbcCMY1yHupTPG1yAf9wQbJ6C1kZ6T7K6Q=.4324cfc3-d477-4e68-b73b-4f38b59b2277@github.com>
Message-ID: <f6LX1K5FPZY3QBLTBltZ7nCfDLsxN_eMYjoHtcdd99I=.2b81dadc-ebb9-4ab3-bb85-c429b3666865@github.com>

> This is a follow up to https://github.com/openjdk/shenandoah/pull/406.

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. The pull request contains eight additional commits since the last revision:

 - Merge remote-tracking branch 'shenandoah/master' into combine-surplus-deficit
 - Update comments
 - Consolidate region transfer logic, move generational specific code out of ShenandoahHeap
 - Use pass by reference for consistency with other methods
 - Fix zero build
 - Fix comments
 - Factor computation of generational reserves into its own method
 - Combine old region surplus and deficit into a single balance field

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

Changes:
  - all: https://git.openjdk.org/shenandoah/pull/410/files
  - new: https://git.openjdk.org/shenandoah/pull/410/files/e25db762..31285e29

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

  Stats: 118798 lines in 2512 files changed: 27172 ins; 82679 del; 8947 mod
  Patch: https://git.openjdk.org/shenandoah/pull/410.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah.git pull/410/head:pull/410

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

From wkemper at openjdk.org  Mon Mar 25 21:19:20 2024
From: wkemper at openjdk.org (William Kemper)
Date: Mon, 25 Mar 2024 21:19:20 GMT
Subject: RFR: Merge openjdk/jdk21u-dev:master [v2]
In-Reply-To: <l1DlVb-ItCBIEjSnzt15qBAEdeg-Pa8I89ZuDBaBUO8=.b8e7d8cb-b5ab-41ad-abf9-39832a0d0be3@github.com>
References: <l1DlVb-ItCBIEjSnzt15qBAEdeg-Pa8I89ZuDBaBUO8=.b8e7d8cb-b5ab-41ad-abf9-39832a0d0be3@github.com>
Message-ID: <RBf0hg19x26L6OcNMiXO6PRa9RMcJ3tjG_9FXN6J7co=.ed5c16e5-cc9c-4886-9b94-bcbfb7d0e620@github.com>

> Merges tag jdk-21.0.3+7

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

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

Changes:
  - all: https://git.openjdk.org/shenandoah-jdk21u/pull/27/files
  - new: https://git.openjdk.org/shenandoah-jdk21u/pull/27/files/07fc6246..07fc6246

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

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

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

From wkemper at openjdk.org  Mon Mar 25 21:19:20 2024
From: wkemper at openjdk.org (William Kemper)
Date: Mon, 25 Mar 2024 21:19:20 GMT
Subject: RFR: Merge openjdk/jdk21u-dev:master
In-Reply-To: <l1DlVb-ItCBIEjSnzt15qBAEdeg-Pa8I89ZuDBaBUO8=.b8e7d8cb-b5ab-41ad-abf9-39832a0d0be3@github.com>
References: <l1DlVb-ItCBIEjSnzt15qBAEdeg-Pa8I89ZuDBaBUO8=.b8e7d8cb-b5ab-41ad-abf9-39832a0d0be3@github.com>
Message-ID: <Gj5EzJbEorJWqxKCxkBwMbouc5bH2wx8aMfuZEdcE5E=.61437a78-1122-4fcb-9bda-950e252b28c8@github.com>

On Thu, 21 Mar 2024 14:15:37 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Merges tag jdk-21.0.3+7

Test failures look unrelated.

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

PR Comment: https://git.openjdk.org/shenandoah-jdk21u/pull/27#issuecomment-2018930490

From wkemper at openjdk.org  Mon Mar 25 21:19:21 2024
From: wkemper at openjdk.org (William Kemper)
Date: Mon, 25 Mar 2024 21:19:21 GMT
Subject: Integrated: Merge openjdk/jdk21u-dev:master
In-Reply-To: <l1DlVb-ItCBIEjSnzt15qBAEdeg-Pa8I89ZuDBaBUO8=.b8e7d8cb-b5ab-41ad-abf9-39832a0d0be3@github.com>
References: <l1DlVb-ItCBIEjSnzt15qBAEdeg-Pa8I89ZuDBaBUO8=.b8e7d8cb-b5ab-41ad-abf9-39832a0d0be3@github.com>
Message-ID: <77MRUmKqPBo3HoZmTBFRoEBPK1mkVReX1bEzWpSVKAA=.4a8df2bc-2739-4956-ba99-abe421f2f8e5@github.com>

On Thu, 21 Mar 2024 14:15:37 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Merges tag jdk-21.0.3+7

This pull request has now been integrated.

Changeset: 2531dfa3
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.org/shenandoah-jdk21u/commit/2531dfa33610e40932d76fc6d3097ea7c2e8abcf
Stats:     150 lines in 1 file changed: 150 ins; 0 del; 0 mod

Merge

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

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

From wkemper at openjdk.org  Mon Mar 25 21:20:47 2024
From: wkemper at openjdk.org (William Kemper)
Date: Mon, 25 Mar 2024 21:20:47 GMT
Subject: RFR: Merge openjdk/jdk:master [v2]
In-Reply-To: <J6Pm7RNVAXJq0ZORMzIS1fCYDcRKInBh1k8heHH5fwY=.3f37914b-56dd-4da3-afc2-09d1ee3de165@github.com>
References: <7naay40eQj26BGLm-vHMFmJ5Kt7EcEV8dRx_VI-MEbU=.9d2c8c53-02cd-4b59-babc-3ad5072ffedf@github.com>
 <J6Pm7RNVAXJq0ZORMzIS1fCYDcRKInBh1k8heHH5fwY=.3f37914b-56dd-4da3-afc2-09d1ee3de165@github.com>
Message-ID: <d7Wu54mkw6pie8iOyOIinZuqrUcV-ugB_9rANSDxz5s=.b4ee983b-7339-4474-b52c-4603d2722593@github.com>

On Mon, 25 Mar 2024 18:03:06 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> Merges tag jdk-23+15
>
> William Kemper has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 115 commits:
> 
>  - Do not forward objects that don't move during a generational full GC
>  - Merge branch 'shenandoah/master' into merge-jdk-23+15
>  - 8328035: Convert javax/swing/text/html/TableView/7030332/bug7030332.java applet test to main
>    
>    Reviewed-by: abhiscxk, prr
>  - 8328300: Convert PrintDialogsTest.java from Applet to main program
>    
>    Reviewed-by: psadhukhan, dnguyen
>  - 8296244: Alternate implementation of user-based authorization Subject APIs that doesn?t depend on Security Manager APIs
>    
>    Reviewed-by: mullan
>  - 8319251: [REDO] Change LockingMode default from LM_LEGACY to LM_LIGHTWEIGHT
>    
>    Reviewed-by: rkennke, dholmes
>  - 8328379: Convert URLDragTest.html applet test to main
>    
>    Reviewed-by: abhiscxk, psadhukhan
>  - 8326521: JFR: CompilerPhase event test fails on windows 32 bit
>    
>    Reviewed-by: egahlin
>  - 8328225: Convert ImageDecoratedDnD.html applet test to main
>    
>    Reviewed-by: dnguyen, aivanov
>  - 8328185: Convert java/awt/image/MemoryLeakTest/MemoryLeakTest.java applet test to main
>    
>    Reviewed-by: azvegint, honkar
>  - ... and 105 more: https://git.openjdk.org/shenandoah/compare/2e788b98...b8d185ec

Zero build failure is a known issue (fixed in pending PRs).

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

PR Comment: https://git.openjdk.org/shenandoah/pull/411#issuecomment-2018933368

From wkemper at openjdk.org  Mon Mar 25 21:20:48 2024
From: wkemper at openjdk.org (William Kemper)
Date: Mon, 25 Mar 2024 21:20:48 GMT
Subject: Integrated: Merge openjdk/jdk:master
In-Reply-To: <7naay40eQj26BGLm-vHMFmJ5Kt7EcEV8dRx_VI-MEbU=.9d2c8c53-02cd-4b59-babc-3ad5072ffedf@github.com>
References: <7naay40eQj26BGLm-vHMFmJ5Kt7EcEV8dRx_VI-MEbU=.9d2c8c53-02cd-4b59-babc-3ad5072ffedf@github.com>
Message-ID: <lR5KtddkSY22sRwChRkivmfuTtvALAhBkd7QPAIrZiA=.7a9ed7d1-518a-46f2-ab7d-f037623eb33b@github.com>

On Fri, 22 Mar 2024 14:10:28 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Merges tag jdk-23+15

This pull request has now been integrated.

Changeset: 0c5ee5c2
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.org/shenandoah/commit/0c5ee5c2268371925f4a620d053d151434bcd145
Stats:     297143 lines in 518 files changed: 7612 ins; 7225 del; 282306 mod

Merge

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

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

From amitkumar at openjdk.org  Tue Mar 26 02:45:28 2024
From: amitkumar at openjdk.org (Amit Kumar)
Date: Tue, 26 Mar 2024 02:45:28 GMT
Subject: RFR: JDK-8241503: C2: Share MacroAssembler between mach nodes
 during code emission [v10]
In-Reply-To: <b0kJcywc9OD_TrAq6FJ9bvHE5WeiCD2hXXItkoseuIk=.e7d36d93-0f5f-4139-b0fd-ec2370f0cdef@github.com>
References: <ExCrwPns55nw2P62UI3vzSVTmFCh3dzJq7u3Kugp9EA=.c20cd86c-2c16-4869-ba7f-76f2a53821d0@github.com>
 <b0kJcywc9OD_TrAq6FJ9bvHE5WeiCD2hXXItkoseuIk=.e7d36d93-0f5f-4139-b0fd-ec2370f0cdef@github.com>
Message-ID: <BppvmN8Phof9l-yXC5GgZGRWC580nxDKqo26eltXUfU=.07e92021-57f0-4f14-9d9c-9ef6e97a3c89@github.com>

On Fri, 22 Mar 2024 18:19:39 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`.
>
> Cesar Soares Lucas has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix AArch64 build & improve comment about InstructionMark

I have done testing on s390 (z15) with: `{fastdebug, slowdebug, release} X {tier1}` and haven't seen new failure appearing due to this change. 

Rest of review leave to @RealLucy :-)

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

Marked as reviewed by amitkumar (Committer).

PR Review: https://git.openjdk.org/jdk/pull/16484#pullrequestreview-1959188734

From kdnilsen at openjdk.org  Tue Mar 26 14:56:55 2024
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Tue, 26 Mar 2024 14:56:55 GMT
Subject: RFR: 8324649: Shenandoah: refactor implementation of free set
 [v37]
In-Reply-To: <VAkn0SrKYZWmnflpM8ZwVAXjUF1LjA0_FCBmRJJ4VSc=.c2f979bd-2957-434e-95ca-7b11b1573900@github.com>
References: <VAkn0SrKYZWmnflpM8ZwVAXjUF1LjA0_FCBmRJJ4VSc=.c2f979bd-2957-434e-95ca-7b11b1573900@github.com>
Message-ID: <Wh5Dd_49tz_7dwRKQ4vAYdyUEGln_W2QUGYiqaEKmJg=.e15a0534-da9a-4406-bb63-0bcf5873eb18@github.com>

> Several objectives:
> 1. Reduce humongous allocation failures by segregating regular regions from humongous regions
> 2. Do not retire regions just because an allocation failed within the region if the memory remaining within the region is large enough to represent a LAB
> 3. Track range of empty regions in addition to range of available regions in order to expedite humongous allocations
> 4. Treat collector reserves as available for Mutator allocations after evacuation completes
> 5. Improve encapsulation so as to enable an OldCollector reserve for future integration of generational Shenandoah
> 
> We have compared performance of existing FreeSet implementation with the proposed PR over a broad set of performance workloads and see that the impact is mostly neutral.
> 
> Comparing 105235.0 metrics from control, 220638.0 from experiment.
> Compare: 0.589s
>                           Most impacted benchmarks |                              Most impacted metrics
> -------------------------------------------------------------------------------------------------------
>                                  Shenandoah/jython |                                          cwr_total
> 
> 
>                                 Only in experiment |                                    Only in control
> -------------------------------------------------------------------------------------------------------
>                  crypto.signverify/trigger_failure |                        crypto.rsa/cmr_thread_roots
>                 extremem-large-31g/adjust_pointers |       scimark.sparse.small/concurrent_thread_roots
>             extremem-large-31g/calculate_addresses |              xml.transform/concurrent_thread_roots
>       crypto.signverify/class_unloading_rendezvous |                    mpegaudio/concurrent_weak_roots
>                                   serial/cmr_total |                        crypto.rsa/ctr_thread_roots
> 
> Shenandoah
> -------------------------------------------------------------------------------------------------------
> +5.64% jython/cwr_total p=0.00037
>   Control:      1.928ms (+/-272.40us)        170
>   Test:         2.037ms (+/-322.73us)        344

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

  Fix for certain compilers

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17561/files
  - new: https://git.openjdk.org/jdk/pull/17561/files/b320a3a7..04d76e8b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17561&range=36
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17561&range=35-36

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

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

From bulasevich at openjdk.org  Tue Mar 26 15:00:27 2024
From: bulasevich at openjdk.org (Boris Ulasevich)
Date: Tue, 26 Mar 2024 15:00:27 GMT
Subject: RFR: JDK-8241503: C2: Share MacroAssembler between mach nodes
 during code emission [v10]
In-Reply-To: <b0kJcywc9OD_TrAq6FJ9bvHE5WeiCD2hXXItkoseuIk=.e7d36d93-0f5f-4139-b0fd-ec2370f0cdef@github.com>
References: <ExCrwPns55nw2P62UI3vzSVTmFCh3dzJq7u3Kugp9EA=.c20cd86c-2c16-4869-ba7f-76f2a53821d0@github.com>
 <b0kJcywc9OD_TrAq6FJ9bvHE5WeiCD2hXXItkoseuIk=.e7d36d93-0f5f-4139-b0fd-ec2370f0cdef@github.com>
Message-ID: <zAsKIMwEkCiOUOR4mYsNnRRna4RCwNEqMRS0resyMp4=.4a33417c-38c9-490b-89be-c78796cc692f@github.com>

On Fri, 22 Mar 2024 18:19:39 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`.
>
> Cesar Soares Lucas has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix AArch64 build & improve comment about InstructionMark

Hi! Your change has conflict with current jdk master. Please rebase.

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

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

From kdnilsen at openjdk.org  Tue Mar 26 15:37:02 2024
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Tue, 26 Mar 2024 15:37:02 GMT
Subject: RFR: 8327097: GenShen: Align PLAB sizes down rather than up [v13]
In-Reply-To: <ubIf-lmCiowlGhyHfBvq-zudoKSzp6MWHaB9UZh5FuM=.27238aa1-a55b-4a19-9cac-e9c4de961613@github.com>
References: <ubIf-lmCiowlGhyHfBvq-zudoKSzp6MWHaB9UZh5FuM=.27238aa1-a55b-4a19-9cac-e9c4de961613@github.com>
Message-ID: <qB1k4Kz2inrPmJNmPp3isMaGQQvO2s1m30r-QsbE3wM=.e95bdb83-0c01-4097-b701-22e42f08bf67@github.com>

> When adjusting LAB sizes, round down rather than rounding up.  Otherwise, we may violate the ShenandoahHumongousThreshold bound.

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

 - Add a missing include to fix zero build
 - Add TODO comment for future refactoring of _plab initialization
 - Bug fixes to address regressions encountered during integration testing
 - Tighten up assert to assist with debugging

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

Changes:
  - all: https://git.openjdk.org/shenandoah/pull/401/files
  - new: https://git.openjdk.org/shenandoah/pull/401/files/ecd6615f..71d9dced

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=shenandoah&pr=401&range=12
 - incr: https://webrevs.openjdk.org/?repo=shenandoah&pr=401&range=11-12

  Stats: 27 lines in 7 files changed: 13 ins; 3 del; 11 mod
  Patch: https://git.openjdk.org/shenandoah/pull/401.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah.git pull/401/head:pull/401

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

From kdnilsen at openjdk.org  Tue Mar 26 15:37:02 2024
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Tue, 26 Mar 2024 15:37:02 GMT
Subject: RFR: 8327097: GenShen: Align PLAB sizes down rather than up [v12]
In-Reply-To: <_T1XSpUB52PI1Yw21fsO01Zob50GqyAkTOrOIxs0TYA=.88bc400b-d177-4b77-9aa6-7c96ffe54f0e@github.com>
References: <ubIf-lmCiowlGhyHfBvq-zudoKSzp6MWHaB9UZh5FuM=.27238aa1-a55b-4a19-9cac-e9c4de961613@github.com>
 <_T1XSpUB52PI1Yw21fsO01Zob50GqyAkTOrOIxs0TYA=.88bc400b-d177-4b77-9aa6-7c96ffe54f0e@github.com>
Message-ID: <59K4Tc3zDY-ewpNnQQ22o0BDGaiT8jgq42rERA56s-Q=.7fa0e927-c953-465e-9104-6ad3ae1589f5@github.com>

On Sat, 23 Mar 2024 03:51:08 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> When adjusting LAB sizes, round down rather than rounding up.  Otherwise, we may violate the ShenandoahHumongousThreshold bound.
>
> Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add detail to log message to help with debugging

Efforts to resolve reviewer comments introduced some regressions.  Converting to draft while I debug these.

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

PR Comment: https://git.openjdk.org/shenandoah/pull/401#issuecomment-2016516696

From kdnilsen at openjdk.org  Tue Mar 26 16:01:04 2024
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Tue, 26 Mar 2024 16:01:04 GMT
Subject: RFR: 8324649: Shenandoah: refactor implementation of free set
 [v38]
In-Reply-To: <VAkn0SrKYZWmnflpM8ZwVAXjUF1LjA0_FCBmRJJ4VSc=.c2f979bd-2957-434e-95ca-7b11b1573900@github.com>
References: <VAkn0SrKYZWmnflpM8ZwVAXjUF1LjA0_FCBmRJJ4VSc=.c2f979bd-2957-434e-95ca-7b11b1573900@github.com>
Message-ID: <gV1jCqm2734Y1iPvnR7l85mor-ByjrqBcT2VMPDNnno=.03f625ff-2b64-4bb0-b9fe-d645c3fd319b@github.com>

> Several objectives:
> 1. Reduce humongous allocation failures by segregating regular regions from humongous regions
> 2. Do not retire regions just because an allocation failed within the region if the memory remaining within the region is large enough to represent a LAB
> 3. Track range of empty regions in addition to range of available regions in order to expedite humongous allocations
> 4. Treat collector reserves as available for Mutator allocations after evacuation completes
> 5. Improve encapsulation so as to enable an OldCollector reserve for future integration of generational Shenandoah
> 
> We have compared performance of existing FreeSet implementation with the proposed PR over a broad set of performance workloads and see that the impact is mostly neutral.
> 
> Comparing 105235.0 metrics from control, 220638.0 from experiment.
> Compare: 0.589s
>                           Most impacted benchmarks |                              Most impacted metrics
> -------------------------------------------------------------------------------------------------------
>                                  Shenandoah/jython |                                          cwr_total
> 
> 
>                                 Only in experiment |                                    Only in control
> -------------------------------------------------------------------------------------------------------
>                  crypto.signverify/trigger_failure |                        crypto.rsa/cmr_thread_roots
>                 extremem-large-31g/adjust_pointers |       scimark.sparse.small/concurrent_thread_roots
>             extremem-large-31g/calculate_addresses |              xml.transform/concurrent_thread_roots
>       crypto.signverify/class_unloading_rendezvous |                    mpegaudio/concurrent_weak_roots
>                                   serial/cmr_total |                        crypto.rsa/ctr_thread_roots
> 
> Shenandoah
> -------------------------------------------------------------------------------------------------------
> +5.64% jython/cwr_total p=0.00037
>   Control:      1.928ms (+/-272.40us)        170
>   Test:         2.037ms (+/-322.73us)        344

Kelvin Nilsen has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 94 commits:

 - Merge remote-tracking branch 'origin/master' into restructure-free-set
 - Merge branch 'openjdk:master' into master
 - Merge branch 'openjdk:master' into master
 - Fix for certain compilers
 - Add a few more conditions to ShenandoahSimpleBitMapTest
 - Fix typo in log message for 32-bit platforms
 - Fix one bug and add disabled instrumentation for debugging
 - Give special handling to count-zeros when arg is 0
 - Exploit count_<leading|trailing>_zeros instructions
   
   The ShenandoahSimpleBitMap can run more efficiently if we use hardware
   instructions to count leading and trailing zeros.
 - Remove comment that pertains only to generational mode
 - ... and 84 more: https://git.openjdk.org/jdk/compare/da8a095a...7bc418fa

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

Changes: https://git.openjdk.org/jdk/pull/17561/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17561&range=37
  Stats: 2534 lines in 6 files changed: 2150 ins; 194 del; 190 mod
  Patch: https://git.openjdk.org/jdk/pull/17561.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17561/head:pull/17561

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

From wkemper at openjdk.org  Tue Mar 26 16:17:52 2024
From: wkemper at openjdk.org (William Kemper)
Date: Tue, 26 Mar 2024 16:17:52 GMT
Subject: RFR: 8327097: GenShen: Align PLAB sizes down rather than up [v13]
In-Reply-To: <qB1k4Kz2inrPmJNmPp3isMaGQQvO2s1m30r-QsbE3wM=.e95bdb83-0c01-4097-b701-22e42f08bf67@github.com>
References: <ubIf-lmCiowlGhyHfBvq-zudoKSzp6MWHaB9UZh5FuM=.27238aa1-a55b-4a19-9cac-e9c4de961613@github.com>
 <qB1k4Kz2inrPmJNmPp3isMaGQQvO2s1m30r-QsbE3wM=.e95bdb83-0c01-4097-b701-22e42f08bf67@github.com>
Message-ID: <DovO9fJnNDgk22H9k2kBvRHByJknbUjd3Dm98m3As5o=.1cbd9e2a-9ad9-4998-aaa7-5086979c6174@github.com>

On Tue, 26 Mar 2024 15:37:02 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> When adjusting LAB sizes, round down rather than rounding up.  Otherwise, we may violate the ShenandoahHumongousThreshold bound.
>
> Kelvin Nilsen has updated the pull request incrementally with four additional commits since the last revision:
> 
>  - Add a missing include to fix zero build
>  - Add TODO comment for future refactoring of _plab initialization
>  - Bug fixes to address regressions encountered during integration testing
>  - Tighten up assert to assist with debugging

LGTM

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

Marked as reviewed by wkemper (Committer).

PR Review: https://git.openjdk.org/shenandoah/pull/401#pullrequestreview-1960951683

From rkennke at openjdk.org  Tue Mar 26 16:48:35 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Tue, 26 Mar 2024 16:48:35 GMT
Subject: RFR: 8324649: Shenandoah: refactor implementation of free set
 [v38]
In-Reply-To: <gV1jCqm2734Y1iPvnR7l85mor-ByjrqBcT2VMPDNnno=.03f625ff-2b64-4bb0-b9fe-d645c3fd319b@github.com>
References: <VAkn0SrKYZWmnflpM8ZwVAXjUF1LjA0_FCBmRJJ4VSc=.c2f979bd-2957-434e-95ca-7b11b1573900@github.com>
 <gV1jCqm2734Y1iPvnR7l85mor-ByjrqBcT2VMPDNnno=.03f625ff-2b64-4bb0-b9fe-d645c3fd319b@github.com>
Message-ID: <VVAFcCU-skwyZu83gyF076NsHIZhnOkK5yaTy_PBWN4=.47eca5e5-96fd-4abe-9b89-a6add83077fd@github.com>

On Tue, 26 Mar 2024 16:01:04 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> Several objectives:
>> 1. Reduce humongous allocation failures by segregating regular regions from humongous regions
>> 2. Do not retire regions just because an allocation failed within the region if the memory remaining within the region is large enough to represent a LAB
>> 3. Track range of empty regions in addition to range of available regions in order to expedite humongous allocations
>> 4. Treat collector reserves as available for Mutator allocations after evacuation completes
>> 5. Improve encapsulation so as to enable an OldCollector reserve for future integration of generational Shenandoah
>> 
>> We have compared performance of existing FreeSet implementation with the proposed PR over a broad set of performance workloads and see that the impact is mostly neutral.
>> 
>> Comparing 105235.0 metrics from control, 220638.0 from experiment.
>> Compare: 0.589s
>>                           Most impacted benchmarks |                              Most impacted metrics
>> -------------------------------------------------------------------------------------------------------
>>                                  Shenandoah/jython |                                          cwr_total
>> 
>> 
>>                                 Only in experiment |                                    Only in control
>> -------------------------------------------------------------------------------------------------------
>>                  crypto.signverify/trigger_failure |                        crypto.rsa/cmr_thread_roots
>>                 extremem-large-31g/adjust_pointers |       scimark.sparse.small/concurrent_thread_roots
>>             extremem-large-31g/calculate_addresses |              xml.transform/concurrent_thread_roots
>>       crypto.signverify/class_unloading_rendezvous |                    mpegaudio/concurrent_weak_roots
>>                                   serial/cmr_total |                        crypto.rsa/ctr_thread_roots
>> 
>> Shenandoah
>> -------------------------------------------------------------------------------------------------------
>> +5.64% jython/cwr_total p=0.00037
>>   Control:      1.928ms (+/-272.40us)        170
>>   Test:         2.037ms (+/-322.73us)        344
>
> Kelvin Nilsen has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 94 commits:
> 
>  - Merge remote-tracking branch 'origin/master' into restructure-free-set
>  - Merge branch 'openjdk:master' into master
>  - Merge branch 'openjdk:master' into master
>  - Fix for certain compilers
>  - Add a few more conditions to ShenandoahSimpleBitMapTest
>  - Fix typo in log message for 32-bit platforms
>  - Fix one bug and add disabled instrumentation for debugging
>  - Give special handling to count-zeros when arg is 0
>  - Exploit count_<leading|trailing>_zeros instructions
>    
>    The ShenandoahSimpleBitMap can run more efficiently if we use hardware
>    instructions to count leading and trailing zeros.
>  - Remove comment that pertains only to generational mode
>  - ... and 84 more: https://git.openjdk.org/jdk/compare/da8a095a...7bc418fa

Please remove the KELVIN_DEBUG stuff, otherwise this is hard to review. ;-)

src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp line 53:

> 51:   uintx omit_mask = right_n_bits(bit_number);
> 52:   uintx mask = ((uintx) 0 - 1) & ~omit_mask;
> 53: #undef KELVIN_DEBUG

Please remove KELVIN_DEBUG before integration. You may want to turn it into proper logging, if you think it may be useful.

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

Changes requested by rkennke (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17561#pullrequestreview-1961091861
PR Review Comment: https://git.openjdk.org/jdk/pull/17561#discussion_r1539704512

From rkennke at openjdk.org  Tue Mar 26 16:48:35 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Tue, 26 Mar 2024 16:48:35 GMT
Subject: RFR: 8324649: Shenandoah: refactor implementation of free set
 [v38]
In-Reply-To: <VVAFcCU-skwyZu83gyF076NsHIZhnOkK5yaTy_PBWN4=.47eca5e5-96fd-4abe-9b89-a6add83077fd@github.com>
References: <VAkn0SrKYZWmnflpM8ZwVAXjUF1LjA0_FCBmRJJ4VSc=.c2f979bd-2957-434e-95ca-7b11b1573900@github.com>
 <gV1jCqm2734Y1iPvnR7l85mor-ByjrqBcT2VMPDNnno=.03f625ff-2b64-4bb0-b9fe-d645c3fd319b@github.com>
 <VVAFcCU-skwyZu83gyF076NsHIZhnOkK5yaTy_PBWN4=.47eca5e5-96fd-4abe-9b89-a6add83077fd@github.com>
Message-ID: <D5wRh8BgYZ1twV9FH6kwu97L48ohmuGLW59zjaK15OI=.5a1de2d3-976a-4ea0-9ce5-e0c1a84f1b52@github.com>

On Tue, 26 Mar 2024 16:38:10 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> Kelvin Nilsen has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 94 commits:
>> 
>>  - Merge remote-tracking branch 'origin/master' into restructure-free-set
>>  - Merge branch 'openjdk:master' into master
>>  - Merge branch 'openjdk:master' into master
>>  - Fix for certain compilers
>>  - Add a few more conditions to ShenandoahSimpleBitMapTest
>>  - Fix typo in log message for 32-bit platforms
>>  - Fix one bug and add disabled instrumentation for debugging
>>  - Give special handling to count-zeros when arg is 0
>>  - Exploit count_<leading|trailing>_zeros instructions
>>    
>>    The ShenandoahSimpleBitMap can run more efficiently if we use hardware
>>    instructions to count leading and trailing zeros.
>>  - Remove comment that pertains only to generational mode
>>  - ... and 84 more: https://git.openjdk.org/jdk/compare/da8a095a...7bc418fa
>
> src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp line 53:
> 
>> 51:   uintx omit_mask = right_n_bits(bit_number);
>> 52:   uintx mask = ((uintx) 0 - 1) & ~omit_mask;
>> 53: #undef KELVIN_DEBUG
> 
> Please remove KELVIN_DEBUG before integration. You may want to turn it into proper logging, if you think it may be useful.

log_*_develop() is only built in debug builds, that may be useful.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17561#discussion_r1539717602

From wkemper at openjdk.org  Tue Mar 26 17:06:06 2024
From: wkemper at openjdk.org (William Kemper)
Date: Tue, 26 Mar 2024 17:06:06 GMT
Subject: RFR: 8328626: GenShen: Combine old generation surplus/deficit
 fields into a single balance field [v6]
In-Reply-To: <aoGfU4G3UAbcCMY1yHupTPG1yAf9wQbJ6C1kZ6T7K6Q=.4324cfc3-d477-4e68-b73b-4f38b59b2277@github.com>
References: <aoGfU4G3UAbcCMY1yHupTPG1yAf9wQbJ6C1kZ6T7K6Q=.4324cfc3-d477-4e68-b73b-4f38b59b2277@github.com>
Message-ID: <GdH_SdPrSOo3RwfxyqmvAkiNho38IqWVFfW59FwtcVg=.64b5c69d-136c-418e-9701-4c78200d083a@github.com>

> This is a follow up to https://github.com/openjdk/shenandoah/pull/406.

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. The pull request contains ten additional commits since the last revision:

 - Merge remote-tracking branch 'shenandoah/master' into combine-surplus-deficit
 - Merge remote-tracking branch 'shenandoah/master' into combine-surplus-deficit
 - Update comments
 - Consolidate region transfer logic, move generational specific code out of ShenandoahHeap
 - Use pass by reference for consistency with other methods
 - Fix zero build
 - Fix comments
 - Factor computation of generational reserves into its own method
 - Combine old region surplus and deficit into a single balance field

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

Changes:
  - all: https://git.openjdk.org/shenandoah/pull/410/files
  - new: https://git.openjdk.org/shenandoah/pull/410/files/31285e29..f38f2e0b

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

  Stats: 297143 lines in 518 files changed: 7612 ins; 7225 del; 282306 mod
  Patch: https://git.openjdk.org/shenandoah/pull/410.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah.git pull/410/head:pull/410

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

From lucy at openjdk.org  Tue Mar 26 17:09:26 2024
From: lucy at openjdk.org (Lutz Schmidt)
Date: Tue, 26 Mar 2024 17:09:26 GMT
Subject: RFR: JDK-8241503: C2: Share MacroAssembler between mach nodes
 during code emission [v10]
In-Reply-To: <b0kJcywc9OD_TrAq6FJ9bvHE5WeiCD2hXXItkoseuIk=.e7d36d93-0f5f-4139-b0fd-ec2370f0cdef@github.com>
References: <ExCrwPns55nw2P62UI3vzSVTmFCh3dzJq7u3Kugp9EA=.c20cd86c-2c16-4869-ba7f-76f2a53821d0@github.com>
 <b0kJcywc9OD_TrAq6FJ9bvHE5WeiCD2hXXItkoseuIk=.e7d36d93-0f5f-4139-b0fd-ec2370f0cdef@github.com>
Message-ID: <QZBE76R11oIVXJLZwYXlIWEH-3JqrLxHHbr9lDG_EiM=.a3efd8ff-d642-4f20-9877-c76109878e3d@github.com>

On Fri, 22 Mar 2024 18:19:39 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`.
>
> Cesar Soares Lucas has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix AArch64 build & improve comment about InstructionMark

s390 changes look good to me.

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

Marked as reviewed by lucy (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16484#pullrequestreview-1961167500

From cslucas at openjdk.org  Tue Mar 26 19:02:42 2024
From: cslucas at openjdk.org (Cesar Soares Lucas)
Date: Tue, 26 Mar 2024 19:02:42 GMT
Subject: RFR: JDK-8241503: C2: Share MacroAssembler between mach nodes
 during code emission [v11]
In-Reply-To: <ExCrwPns55nw2P62UI3vzSVTmFCh3dzJq7u3Kugp9EA=.c20cd86c-2c16-4869-ba7f-76f2a53821d0@github.com>
References: <ExCrwPns55nw2P62UI3vzSVTmFCh3dzJq7u3Kugp9EA=.c20cd86c-2c16-4869-ba7f-76f2a53821d0@github.com>
Message-ID: <dQZjFk-E_tYaTTg7CzDj_bFhPb4RHsI6EKlga4vsNbQ=.9339a5c7-72c5-425c-b90b-6261d53f5a58@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`.

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 12 commits:

 - Merge remote-tracking branch 'origin/master' into reuse-macroasm
 - Fix AArch64 build & improve comment about InstructionMark
 - Catching up with changes in master
 - Catching up with origin/master
 - Catch up with origin/master
 - Merge with origin/master
 - Fix build, copyright dates, m4 files.
 - Fix merge
 - Catch up with master branch.
   
   Merge remote-tracking branch 'origin/master' into reuse-macroasm
 - Some inst_mark fixes; Catch up with master.
 - ... and 2 more: https://git.openjdk.org/jdk/compare/89e0889a...b4d73c98

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

Changes: https://git.openjdk.org/jdk/pull/16484/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16484&range=10
  Stats: 2153 lines in 60 files changed: 136 ins; 431 del; 1586 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 ysr at openjdk.org  Wed Mar 27 06:49:39 2024
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Wed, 27 Mar 2024 06:49:39 GMT
Subject: RFR: 8327097: GenShen: Align PLAB sizes down rather than up [v13]
In-Reply-To: <qB1k4Kz2inrPmJNmPp3isMaGQQvO2s1m30r-QsbE3wM=.e95bdb83-0c01-4097-b701-22e42f08bf67@github.com>
References: <ubIf-lmCiowlGhyHfBvq-zudoKSzp6MWHaB9UZh5FuM=.27238aa1-a55b-4a19-9cac-e9c4de961613@github.com>
 <qB1k4Kz2inrPmJNmPp3isMaGQQvO2s1m30r-QsbE3wM=.e95bdb83-0c01-4097-b701-22e42f08bf67@github.com>
Message-ID: <ZCYASZRK2rX73vVhF-mlY0v8-Rhh7NxiwBd9PnwEDMg=.0249ece9-6219-44eb-9b5d-d9a6f3de56aa@github.com>

On Tue, 26 Mar 2024 15:37:02 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> When adjusting LAB sizes, round down rather than rounding up.  Otherwise, we may violate the ShenandoahHumongousThreshold bound.
>
> Kelvin Nilsen has updated the pull request incrementally with four additional commits since the last revision:
> 
>  - Add a missing include to fix zero build
>  - Add TODO comment for future refactoring of _plab initialization
>  - Bug fixes to address regressions encountered during integration testing
>  - Tighten up assert to assist with debugging

LGTM

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

Marked as reviewed by ysr (Committer).

PR Review: https://git.openjdk.org/shenandoah/pull/401#pullrequestreview-1962441794

From shade at openjdk.org  Wed Mar 27 11:41:28 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 27 Mar 2024 11:41:28 GMT
Subject: RFR: 8329134: Reconsider TLAB zapping
Message-ID: <cWkDJ301cKsXnEsx2wDgNV1fzqiYqaYBIXNzrKpvL0o=.5171a404-f1ef-43b7-b879-ff9c514379ad@github.com>

We zap the entire TLAB on initial allocation (`MemAllocator::mem_allocate_inside_tlab_slow`), and then also rezap the object contents when object is allocated from the TLAB (`ThreadLocalAllocBuffer::allocate`). The second part seems excessive, given the TLAB is already fully zapped.

There is also no way to disable this zapping, like you would in other places with the relevant Zap* flags.

Fixing both these issues allows to improve fastdebug tests performance, e.g. in jcstress. 

It also allows to remove the related Zero kludge.

Additional testing:
 - [ ] Linux AArch64 server fastdebug, `all` tests 
 - [x] MacOS AArch64 Zero fastdebug, `bootcycle-images` pass

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

Commit messages:
 - Touchups
 - Also remove Zero kludge
 - Fix

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

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

From stefank at openjdk.org  Wed Mar 27 14:04:29 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Wed, 27 Mar 2024 14:04:29 GMT
Subject: RFR: 8329134: Reconsider TLAB zapping
In-Reply-To: <cWkDJ301cKsXnEsx2wDgNV1fzqiYqaYBIXNzrKpvL0o=.5171a404-f1ef-43b7-b879-ff9c514379ad@github.com>
References: <cWkDJ301cKsXnEsx2wDgNV1fzqiYqaYBIXNzrKpvL0o=.5171a404-f1ef-43b7-b879-ff9c514379ad@github.com>
Message-ID: <x5DdDUarqJuFdTf4EvZ-KHyqxn6zb2omVPS22Du6NvI=.d2bf8447-7622-4613-9649-23687c03362b@github.com>

On Tue, 26 Mar 2024 21:08:16 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> We zap the entire TLAB on initial allocation (`MemAllocator::mem_allocate_inside_tlab_slow`), and then also rezap the object contents when object is allocated from the TLAB (`ThreadLocalAllocBuffer::allocate`). The second part seems excessive, given the TLAB is already fully zapped.
> 
> There is also no way to disable this zapping, like you would in other places with the relevant Zap* flags.
> 
> Fixing both these issues allows to improve fastdebug tests performance, e.g. in jcstress. 
> 
> It also allows to remove the related Zero kludge.
> 
> Additional testing:
>  - [ ] Linux AArch64 server fastdebug, `all` tests 
>  - [x] MacOS AArch64 Zero fastdebug, `bootcycle-images` pass

This looks like a worth-while change. I listed a couple of nits that I think would be nice to clean up.

src/hotspot/share/gc/shared/memAllocator.cpp line 323:

> 321:     Copy::zero_to_words(mem, allocation._allocated_tlab_size);
> 322:   } else if (ZapTLAB) {
> 323:     // ...and zap just allocated TLAB.

Could you add a blank line after this, so that the two separate comments don't get bunched together?

src/hotspot/share/gc/shared/threadLocalAllocBuffer.inline.hpp line 43:

> 41:   if (pointer_delta(end(), obj) >= size) {
> 42:     // successful thread-local allocation
> 43: #ifdef ASSERT

Could you add a blank line after this, so that the two separate comments don't get bunched together?

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

> 882:     Copy::zero_to_words(gclab_buf, actual_size);
> 883:   } else if (ZapTLAB) {
> 884:     // ...and zap just allocated TLAB.

Could you add a blank line after this, so that the two separate comments don't get bunched together?

src/hotspot/share/interpreter/zero/bytecodeInterpreter.cpp line 1996:

> 1994:               // Initialize object field block.
> 1995:               // If TLAB was pre-zeroed, we can skip this path.
> 1996:               if (!ZeroTLAB) {

"skip this path" refers to the code inside the if block. I think it would be nicer to just place a comment in that block, so that we don't have to figure out what "this path" means. Maybe something like:


if (!ZeroTLAB) {
  // The TLAB was not pre-zeroed, so clear the memory here.

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

Changes requested by stefank (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18500#pullrequestreview-1963374309
PR Review Comment: https://git.openjdk.org/jdk/pull/18500#discussion_r1541141628
PR Review Comment: https://git.openjdk.org/jdk/pull/18500#discussion_r1541142044
PR Review Comment: https://git.openjdk.org/jdk/pull/18500#discussion_r1541145082
PR Review Comment: https://git.openjdk.org/jdk/pull/18500#discussion_r1541159636

From stefank at openjdk.org  Wed Mar 27 14:04:30 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Wed, 27 Mar 2024 14:04:30 GMT
Subject: RFR: 8329134: Reconsider TLAB zapping
In-Reply-To: <x5DdDUarqJuFdTf4EvZ-KHyqxn6zb2omVPS22Du6NvI=.d2bf8447-7622-4613-9649-23687c03362b@github.com>
References: <cWkDJ301cKsXnEsx2wDgNV1fzqiYqaYBIXNzrKpvL0o=.5171a404-f1ef-43b7-b879-ff9c514379ad@github.com>
 <x5DdDUarqJuFdTf4EvZ-KHyqxn6zb2omVPS22Du6NvI=.d2bf8447-7622-4613-9649-23687c03362b@github.com>
Message-ID: <q09cnLEMYe8cn-77je-YxF5AqeKsOJyLY78GTglCK9Y=.73ce3a4a-c0d7-43da-b0f7-83ca961aa638@github.com>

On Wed, 27 Mar 2024 13:42:08 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> We zap the entire TLAB on initial allocation (`MemAllocator::mem_allocate_inside_tlab_slow`), and then also rezap the object contents when object is allocated from the TLAB (`ThreadLocalAllocBuffer::allocate`). The second part seems excessive, given the TLAB is already fully zapped.
>> 
>> There is also no way to disable this zapping, like you would in other places with the relevant Zap* flags.
>> 
>> Fixing both these issues allows to improve fastdebug tests performance, e.g. in jcstress. 
>> 
>> It also allows to remove the related Zero kludge.
>> 
>> Additional testing:
>>  - [ ] Linux AArch64 server fastdebug, `all` tests 
>>  - [x] MacOS AArch64 Zero fastdebug, `bootcycle-images` pass
>
> src/hotspot/share/gc/shared/memAllocator.cpp line 323:
> 
>> 321:     Copy::zero_to_words(mem, allocation._allocated_tlab_size);
>> 322:   } else if (ZapTLAB) {
>> 323:     // ...and zap just allocated TLAB.
> 
> Could you add a blank line after this, so that the two separate comments don't get bunched together?

Rereading the patch, I also so that we have:

// ..and clear it.
...
// ...and zap just allocated TLAB.

Maybe just unify this into:

// ..and clear it.
...
// ...and zap it.

Alternatively:

// ..and clear just allocated TLAB.
...
// ...and zap just allocated TLAB.


And while you are changing this. What's up with the `..` vs `...`? (rhetoric question) I'd prefer if we just picked either of those.

This comment also applies to the duplicated code in shenandoahHeap.cpp.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18500#discussion_r1541177284

From shade at openjdk.org  Wed Mar 27 14:55:35 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 27 Mar 2024 14:55:35 GMT
Subject: RFR: 8329134: Reconsider TLAB zapping [v2]
In-Reply-To: <cWkDJ301cKsXnEsx2wDgNV1fzqiYqaYBIXNzrKpvL0o=.5171a404-f1ef-43b7-b879-ff9c514379ad@github.com>
References: <cWkDJ301cKsXnEsx2wDgNV1fzqiYqaYBIXNzrKpvL0o=.5171a404-f1ef-43b7-b879-ff9c514379ad@github.com>
Message-ID: <uZhJWOZ46zIL4x_Zv6_SPppmAYLfMkeOkCM-CHUSOx4=.c0269562-c250-4f5b-9aeb-718821f4050a@github.com>

> We zap the entire TLAB on initial allocation (`MemAllocator::mem_allocate_inside_tlab_slow`), and then also rezap the object contents when object is allocated from the TLAB (`ThreadLocalAllocBuffer::allocate`). The second part seems excessive, given the TLAB is already fully zapped.
> 
> There is also no way to disable this zapping, like you would in other places with the relevant Zap* flags.
> 
> Fixing both these issues allows to improve fastdebug tests performance, e.g. in jcstress. 
> 
> It also allows to remove the related Zero kludge.
> 
> Additional testing:
>  - [x] Linux AArch64 server fastdebug, `all` tests 
>  - [x] MacOS AArch64 Zero fastdebug, `bootcycle-images` pass

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

  Review comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18500/files
  - new: https://git.openjdk.org/jdk/pull/18500/files/8fe98c4c..72bf1e8a

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

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

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

From shade at openjdk.org  Wed Mar 27 14:55:35 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 27 Mar 2024 14:55:35 GMT
Subject: RFR: 8329134: Reconsider TLAB zapping [v2]
In-Reply-To: <q09cnLEMYe8cn-77je-YxF5AqeKsOJyLY78GTglCK9Y=.73ce3a4a-c0d7-43da-b0f7-83ca961aa638@github.com>
References: <cWkDJ301cKsXnEsx2wDgNV1fzqiYqaYBIXNzrKpvL0o=.5171a404-f1ef-43b7-b879-ff9c514379ad@github.com>
 <x5DdDUarqJuFdTf4EvZ-KHyqxn6zb2omVPS22Du6NvI=.d2bf8447-7622-4613-9649-23687c03362b@github.com>
 <q09cnLEMYe8cn-77je-YxF5AqeKsOJyLY78GTglCK9Y=.73ce3a4a-c0d7-43da-b0f7-83ca961aa638@github.com>
Message-ID: <l5Gcbj3ICa7FnfiJUBvt3a_vRIwJ_5AwDrpQzNn0G60=.4ec85a4c-ed3c-4862-87f3-dd21e9c7cd71@github.com>

On Wed, 27 Mar 2024 14:00:56 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> src/hotspot/share/gc/shared/memAllocator.cpp line 323:
>> 
>>> 321:     Copy::zero_to_words(mem, allocation._allocated_tlab_size);
>>> 322:   } else if (ZapTLAB) {
>>> 323:     // ...and zap just allocated TLAB.
>> 
>> Could you add a blank line after this, so that the two separate comments don't get bunched together?
>
> Rereading the patch, I also so that we have:
> 
> // ..and clear it.
> ...
> // ...and zap just allocated TLAB.
> 
> Maybe just unify this into:
> 
> // ..and clear it.
> ...
> // ...and zap it.
> 
> Alternatively:
> 
> // ..and clear just allocated TLAB.
> ...
> // ...and zap just allocated TLAB.
> 
> 
> And while you are changing this. What's up with the `..` vs `...`? (rhetoric question) I'd prefer if we just picked either of those.
> 
> This comment also applies to the duplicated code in shenandoahHeap.cpp.

I meditated about this code a bit, and I think we have a cleaner third option, see new commit.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18500#discussion_r1541280635

From kdnilsen at openjdk.org  Wed Mar 27 15:29:46 2024
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Wed, 27 Mar 2024 15:29:46 GMT
Subject: Integrated: 8327097: GenShen: Align PLAB sizes down rather than up
In-Reply-To: <ubIf-lmCiowlGhyHfBvq-zudoKSzp6MWHaB9UZh5FuM=.27238aa1-a55b-4a19-9cac-e9c4de961613@github.com>
References: <ubIf-lmCiowlGhyHfBvq-zudoKSzp6MWHaB9UZh5FuM=.27238aa1-a55b-4a19-9cac-e9c4de961613@github.com>
Message-ID: <H02OYgoql7LtL1d5kCbINcv0C2tZG5nJHHzj4BEi06U=.1e28929e-9563-44c7-8696-286fd803de35@github.com>

On Mon, 26 Feb 2024 21:27:37 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

> When adjusting LAB sizes, round down rather than rounding up.  Otherwise, we may violate the ShenandoahHumongousThreshold bound.

This pull request has now been integrated.

Changeset: f1d98490
Author:    Kelvin Nilsen <kdnilsen at openjdk.org>
URL:       https://git.openjdk.org/shenandoah/commit/f1d98490f4e2fe94f2ed6db961934812c53395ae
Stats:     155 lines in 12 files changed: 73 ins; 35 del; 47 mod

8327097: GenShen: Align PLAB sizes down rather than up

Reviewed-by: ysr, wkemper

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

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

From wkemper at openjdk.org  Wed Mar 27 16:08:57 2024
From: wkemper at openjdk.org (William Kemper)
Date: Wed, 27 Mar 2024 16:08:57 GMT
Subject: RFR: 8328626: GenShen: Combine old generation surplus/deficit
 fields into a single balance field [v7]
In-Reply-To: <aoGfU4G3UAbcCMY1yHupTPG1yAf9wQbJ6C1kZ6T7K6Q=.4324cfc3-d477-4e68-b73b-4f38b59b2277@github.com>
References: <aoGfU4G3UAbcCMY1yHupTPG1yAf9wQbJ6C1kZ6T7K6Q=.4324cfc3-d477-4e68-b73b-4f38b59b2277@github.com>
Message-ID: <YGfc922tWckKSssJmyfnqhVSZzJ08oaBrYqjuhRZFes=.441c6230-5c9f-43f6-adc1-c446715c41f9@github.com>

> This is a follow up to https://github.com/openjdk/shenandoah/pull/406.

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

 - Merge remote-tracking branch 'shenandoah/master' into combine-surplus-deficit
 - Merge remote-tracking branch 'shenandoah/master' into combine-surplus-deficit
 - Merge remote-tracking branch 'shenandoah/master' into combine-surplus-deficit
 - Update comments
 - Consolidate region transfer logic, move generational specific code out of ShenandoahHeap
 - Use pass by reference for consistency with other methods
 - Fix zero build
 - Fix comments
 - Factor computation of generational reserves into its own method
 - Combine old region surplus and deficit into a single balance field

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

Changes: https://git.openjdk.org/shenandoah/pull/410/files
  Webrev: https://webrevs.openjdk.org/?repo=shenandoah&pr=410&range=06
  Stats: 277 lines in 10 files changed: 100 ins; 119 del; 58 mod
  Patch: https://git.openjdk.org/shenandoah/pull/410.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah.git pull/410/head:pull/410

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

From bulasevich at openjdk.org  Wed Mar 27 16:15:28 2024
From: bulasevich at openjdk.org (Boris Ulasevich)
Date: Wed, 27 Mar 2024 16:15:28 GMT
Subject: RFR: JDK-8241503: C2: Share MacroAssembler between mach nodes
 during code emission [v11]
In-Reply-To: <dQZjFk-E_tYaTTg7CzDj_bFhPb4RHsI6EKlga4vsNbQ=.9339a5c7-72c5-425c-b90b-6261d53f5a58@github.com>
References: <ExCrwPns55nw2P62UI3vzSVTmFCh3dzJq7u3Kugp9EA=.c20cd86c-2c16-4869-ba7f-76f2a53821d0@github.com>
 <dQZjFk-E_tYaTTg7CzDj_bFhPb4RHsI6EKlga4vsNbQ=.9339a5c7-72c5-425c-b90b-6261d53f5a58@github.com>
Message-ID: <zDAtg_h3PMKma0jA6Phr7_Cu-xbERmW8QMzmsbh6_WI=.7ac7920b-7288-4d0a-817a-d3184a47ab08@github.com>

On Tue, 26 Mar 2024 19:02:42 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`.
>
> 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 12 commits:
> 
>  - Merge remote-tracking branch 'origin/master' into reuse-macroasm
>  - Fix AArch64 build & improve comment about InstructionMark
>  - Catching up with changes in master
>  - Catching up with origin/master
>  - Catch up with origin/master
>  - Merge with origin/master
>  - Fix build, copyright dates, m4 files.
>  - Fix merge
>  - Catch up with master branch.
>    
>    Merge remote-tracking branch 'origin/master' into reuse-macroasm
>  - Some inst_mark fixes; Catch up with master.
>  - ... and 2 more: https://git.openjdk.org/jdk/compare/89e0889a...b4d73c98

FYI. Something goes wrong with the change on ARM32.

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (/ws/workspace/jdk-dev/label/linux-arm/type/b11/jdk/src/hotspot/share/asm/codeBuffer.hpp:163), pid=10782, tid=10796
#  assert(_mark != nullptr) failed: not an offset
#
# JRE version: OpenJDK Runtime Environment (23.0) (fastdebug build 23-commit8fc9097b-adhoc.re.jdk)
# Java VM: OpenJDK Server VM (fastdebug 23-commit8fc9097b-adhoc.re.jdk, mixed mode, g1 gc, linux-arm)
# Problematic frame:
# V  [libjvm.so+0x136ccc]  emit_call_reloc(C2_MacroAssembler*, MachCallNode const*, MachOper*, RelocationHolder const&)+0x2ac
#
# Core dump will be written. Default location: Core dumps may be processed with "/usr/share/apport/apport %p %s %c %d %P %E" (or dumping to /ws/workspace/jdk-dev-jtreg/label/linux-arm/suite/jdk-tier1/type/t11/core.10782)
#
# If you would like to submit a bug report, please visit:
#   https://bugreport.java.com/bugreport/crash.jsp
#

---------------  S U M M A R Y ------------

Command Line:

Host: vm-ubuntu-16v4-aarch64-1, ARM, 4 cores, 7G, Ubuntu 16.04.7 LTS
Time: Wed Mar 27 07:16:41 2024 UTC elapsed time: 0.097440 seconds (0d 0h 0m 0s)

---------------  T H R E A D  ---------------

Current thread (0xb120cd10):  JavaThread "C2 CompilerThread0" daemon [_thread_in_vm, id=10796, stack(0xb1090000,0xb1110000) (512K)]

Stack: [0xb1090000,0xb1110000],  sp=0xb110d200,  free space=500k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0x136ccc]  emit_call_reloc(C2_MacroAssembler*, MachCallNode const*, MachOper*, RelocationHolder const&)+0x2ac  (codeBuffer.hpp:163)
V  [libjvm.so+0x14ca28]  CallRuntimeDirectNode::emit(C2_MacroAssembler*, PhaseRegAlloc*) const+0x80
V  [libjvm.so+0x10ed850]  PhaseOutput::scratch_emit_size(Node const*)+0x37c
V  [libjvm.so+0x10e5f64]  PhaseOutput::shorten_branches(unsigned int*)+0x274
V  [libjvm.so+0x10f6dcc]  PhaseOutput::Output()+0x488
V  [libjvm.so+0x699b54]  Compile::Code_Gen()+0x424
V  [libjvm.so+0x69a87c]  Compile::Compile(ciEnv*, TypeFunc const* (*)(), unsigned char*, char const*, int, bool, bool, DirectiveSet*)+0xb3c
V  [libjvm.so+0x122e73c]  OptoRuntime::generate_stub(ciEnv*, TypeFunc const* (*)(), unsigned char*, char const*, int, bool, bool)+0xb4
V  [libjvm.so+0x122ec68]  OptoRuntime::generate(ciEnv*)+0x50
V  [libjvm.so+0x4994cc]  C2Compiler::init_c2_runtime()+0x104
V  [libjvm.so+0x4996dc]  C2Compiler::initialize()+0x9c
V  [libjvm.so+0x6a371c]  CompileBroker::init_compiler_runtime()+0x35c
V  [libjvm.so+0x6ab90c]  CompileBroker::compiler_thread_loop()+0x178
V  [libjvm.so+0xb30c94]  JavaThread::thread_main_inner()+0x27c
V  [libjvm.so+0x13b3aa0]  Thread::call_run()+0x130
V  [libjvm.so+0x10c98bc]  thread_native_entry(Thread*)+0x13c

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

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

From stefank at openjdk.org  Wed Mar 27 16:28:22 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Wed, 27 Mar 2024 16:28:22 GMT
Subject: RFR: 8329134: Reconsider TLAB zapping [v2]
In-Reply-To: <uZhJWOZ46zIL4x_Zv6_SPppmAYLfMkeOkCM-CHUSOx4=.c0269562-c250-4f5b-9aeb-718821f4050a@github.com>
References: <cWkDJ301cKsXnEsx2wDgNV1fzqiYqaYBIXNzrKpvL0o=.5171a404-f1ef-43b7-b879-ff9c514379ad@github.com>
 <uZhJWOZ46zIL4x_Zv6_SPppmAYLfMkeOkCM-CHUSOx4=.c0269562-c250-4f5b-9aeb-718821f4050a@github.com>
Message-ID: <oInRlW3dRsBinpYQLbZMJ-eq-l4xsVUml3IdcxlE1I8=.1ece562d-8d41-4e80-88b8-cc529e52d1f2@github.com>

On Wed, 27 Mar 2024 14:55:35 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> We zap the entire TLAB on initial allocation (`MemAllocator::mem_allocate_inside_tlab_slow`), and then also rezap the object contents when object is allocated from the TLAB (`ThreadLocalAllocBuffer::allocate`). The second part seems excessive, given the TLAB is already fully zapped.
>> 
>> There is also no way to disable this zapping, like you would in other places with the relevant Zap* flags.
>> 
>> Fixing both these issues allows to improve fastdebug tests performance, e.g. in jcstress. 
>> 
>> It also allows to remove the related Zero kludge.
>> 
>> Additional testing:
>>  - [x] Linux AArch64 server fastdebug, `all` tests 
>>  - [x] MacOS AArch64 Zero fastdebug, `bootcycle-images` pass
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments

Thanks! Looks good.

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

Marked as reviewed by stefank (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18500#pullrequestreview-1963856718

From cslucas at openjdk.org  Wed Mar 27 17:05:28 2024
From: cslucas at openjdk.org (Cesar Soares Lucas)
Date: Wed, 27 Mar 2024 17:05:28 GMT
Subject: RFR: JDK-8241503: C2: Share MacroAssembler between mach nodes
 during code emission [v11]
In-Reply-To: <zDAtg_h3PMKma0jA6Phr7_Cu-xbERmW8QMzmsbh6_WI=.7ac7920b-7288-4d0a-817a-d3184a47ab08@github.com>
References: <ExCrwPns55nw2P62UI3vzSVTmFCh3dzJq7u3Kugp9EA=.c20cd86c-2c16-4869-ba7f-76f2a53821d0@github.com>
 <dQZjFk-E_tYaTTg7CzDj_bFhPb4RHsI6EKlga4vsNbQ=.9339a5c7-72c5-425c-b90b-6261d53f5a58@github.com>
 <zDAtg_h3PMKma0jA6Phr7_Cu-xbERmW8QMzmsbh6_WI=.7ac7920b-7288-4d0a-817a-d3184a47ab08@github.com>
Message-ID: <8G-DywP4PPoHwjFOf44Ho6mc4iwPYtyfGPzSByRK6zY=.2a47a06d-8039-4fde-bd27-b3c938fcae87@github.com>

On Wed, 27 Mar 2024 16:12:26 GMT, Boris Ulasevich <bulasevich 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 12 commits:
>> 
>>  - Merge remote-tracking branch 'origin/master' into reuse-macroasm
>>  - Fix AArch64 build & improve comment about InstructionMark
>>  - Catching up with changes in master
>>  - Catching up with origin/master
>>  - Catch up with origin/master
>>  - Merge with origin/master
>>  - Fix build, copyright dates, m4 files.
>>  - Fix merge
>>  - Catch up with master branch.
>>    
>>    Merge remote-tracking branch 'origin/master' into reuse-macroasm
>>  - Some inst_mark fixes; Catch up with master.
>>  - ... and 2 more: https://git.openjdk.org/jdk/compare/89e0889a...b4d73c98
>
> FYI. Something goes wrong with the change on ARM32.
> 
> #
> # A fatal error has been detected by the Java Runtime Environment:
> #
> #  Internal Error (/ws/workspace/jdk-dev/label/linux-arm/type/b11/jdk/src/hotspot/share/asm/codeBuffer.hpp:163), pid=10782, tid=10796
> #  assert(_mark != nullptr) failed: not an offset
> #
> # JRE version: OpenJDK Runtime Environment (23.0) (fastdebug build 23-commit8fc9097b-adhoc.re.jdk)
> # Java VM: OpenJDK Server VM (fastdebug 23-commit8fc9097b-adhoc.re.jdk, mixed mode, g1 gc, linux-arm)
> # Problematic frame:
> # V  [libjvm.so+0x136ccc]  emit_call_reloc(C2_MacroAssembler*, MachCallNode const*, MachOper*, RelocationHolder const&)+0x2ac
> #
> # Core dump will be written. Default location: Core dumps may be processed with "/usr/share/apport/apport %p %s %c %d %P %E" (or dumping to /ws/workspace/jdk-dev-jtreg/label/linux-arm/suite/jdk-tier1/type/t11/core.10782)
> #
> # If you would like to submit a bug report, please visit:
> #   https://bugreport.java.com/bugreport/crash.jsp
> #
> 
> ---------------  S U M M A R Y ------------
> 
> Command Line:
> 
> Host: vm-ubuntu-16v4-aarch64-1, ARM, 4 cores, 7G, Ubuntu 16.04.7 LTS
> Time: Wed Mar 27 07:16:41 2024 UTC elapsed time: 0.097440 seconds (0d 0h 0m 0s)
> 
> ---------------  T H R E A D  ---------------
> 
> Current thread (0xb120cd10):  JavaThread "C2 CompilerThread0" daemon [_thread_in_vm, id=10796, stack(0xb1090000,0xb1110000) (512K)]
> 
> Stack: [0xb1090000,0xb1110000],  sp=0xb110d200,  free space=500k
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
> V  [libjvm.so+0x136ccc]  emit_call_reloc(C2_MacroAssembler*, MachCallNode const*, MachOper*, RelocationHolder const&)+0x2ac  (codeBuffer.hpp:163)
> V  [libjvm.so+0x14ca28]  CallRuntimeDirectNode::emit(C2_MacroAssembler*, PhaseRegAlloc*) const+0x80
> V  [libjvm.so+0x10ed850]  PhaseOutput::scratch_emit_size(Node const*)+0x37c
> V  [libjvm.so+0x10e5f64]  PhaseOutput::shorten_branches(unsigned int*)+0x274
> V  [libjvm.so+0x10f6dcc]  PhaseOutput::Output()+0x488
> V  [libjvm.so+0x699b54]  Compile::Code_Gen()+0x424
> V  [libjvm.so+0x69a87c]  Compile::Compile(ciEnv*, TypeFunc const* (*)(), unsigned char*, char const*, int, bool, bool, DirectiveSet*)+0xb3c
> V  [libjvm.so+0x122e73c]  OptoRuntime::generate_stub(ciEnv*, TypeFunc const* (*)(), unsigned char*, char const*, int, bool, bool)+0xb4
> V  [libjvm.so+0x122ec68]  OptoRuntime::generate(ciEnv*)+0x50
> V  [libjvm.so+0x4994cc]  C2Compiler::init_c2_runtime()+0x104
> V  [libjvm.so+0x4996dc]  C2Compiler::initialize()+0x9c
> V  [libjvm.so+...

Thanks for testing @bulasevich . I'm going to take a look and get back to you asap.

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

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

From simonis at openjdk.org  Wed Mar 27 17:32:32 2024
From: simonis at openjdk.org (Volker Simonis)
Date: Wed, 27 Mar 2024 17:32:32 GMT
Subject: RFR: 8329204: Diagnostic command for zeroing unused parts of the heap
Message-ID: <b4mPQ-O25iKRZTAsKCoUJ2IrB78D_aEYs1kZRNRS4O4=.e64e5fee-52f4-4543-8c5e-3d6dd60cd8d7@github.com>

Diagnostic command for zeroing unused parts of the heap

I propose to add a new diagnostic command `System.zero_unused_memory` which zeros out all unused parts of the heap. The name of the command is intentionally GC/heap agnostic because in the future it might be extended to also zero unused parts of the Metaspace and/or CodeCache.

Currently `System.zero_unused_memory` triggers a full GC and afterwards zeros unused parts of the heap. Zeroing can help snapshotting technologies like [CRIU][1] or [Firecracker][2] to shrink the snapshot size of VMs/containers with running JVM processes because pages which only contain zero bytes can be easily removed from the image by making the image *sparse* (e.g. with [`fallocate -p`][3]).

Notice that uncommitting unused heap parts in the JVM doesn't help in the context of virtualization (e.g. KVM/Firecracker) because from the host perspective they are still dirty and can't be easily removed from the snapshot image because they usually contain some non-zero data. More details can be found in my FOSDEM talk ["Zeroing and the semantic gap between host and guest"][4].

Furthermore, removing pages which only contain zero bytes (i.e. "empty pages") from a snapshot image not only decreases the image size but also speeds up the restore process because empty pages don't have to be read from the image file but will be populated by the kernel zero page first until they are used for the first time. This also decreases the initial memory footprint of a restored process. 

An additional argument for memory zeroing is security. By zeroing unused heap parts, we can make sure that secrets contained in unreferenced Java objects are deleted. Something that's currently impossibly to achieve from Java because even if a Java program zeroes out arrays with sensitive data after usage, it can never guarantee that the corresponding object hasn't already been moved by the GC and an old, unreferenced copy of that data still exists somewhere in the heap.

A prototype implementation for this proposal for Serial, Parallel, G1 and Shenandoah GC is available in the linked pull request.

[1]: https://criu.org
[2]: https://github.com/firecracker-microvm/firecracker/blob/main/docs/snapshotting/snapshot-support.md
[3]: https://man7.org/linux/man-pages/man1/fallocate.1.html
[4]: https://fosdem.org/2024/schedule/event/fosdem-2024-3454-zeroing-and-the-semantic-gap-between-host-and-guest/

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

Commit messages:
 - Make VM_ZeroUnusedMemory a VM_GC_Sync_Operation
 - Implement unused memory zeroing for ShenadoahGC and move the zeroing part into a VM operation
 - Implement unused memory zeroing for G1GC
 - Implement unused memory zeroing for ParallelGC
 - 8329204: Diagnostic command for zeroing unused parts of the heap

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

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

From simonis at openjdk.org  Wed Mar 27 18:10:34 2024
From: simonis at openjdk.org (Volker Simonis)
Date: Wed, 27 Mar 2024 18:10:34 GMT
Subject: RFR: 8329204: Diagnostic command for zeroing unused parts of the
 heap [v2]
In-Reply-To: <b4mPQ-O25iKRZTAsKCoUJ2IrB78D_aEYs1kZRNRS4O4=.e64e5fee-52f4-4543-8c5e-3d6dd60cd8d7@github.com>
References: <b4mPQ-O25iKRZTAsKCoUJ2IrB78D_aEYs1kZRNRS4O4=.e64e5fee-52f4-4543-8c5e-3d6dd60cd8d7@github.com>
Message-ID: <p4sSye_a4X9sPx6nscEVzKvZBc50BEYDpIBtKu1ObB8=.42fd8b03-97af-4b4c-bd00-9da18e86e3e4@github.com>

> Diagnostic command for zeroing unused parts of the heap
> 
> I propose to add a new diagnostic command `System.zero_unused_memory` which zeros out all unused parts of the heap. The name of the command is intentionally GC/heap agnostic because in the future it might be extended to also zero unused parts of the Metaspace and/or CodeCache.
> 
> Currently `System.zero_unused_memory` triggers a full GC and afterwards zeros unused parts of the heap. Zeroing can help snapshotting technologies like [CRIU][1] or [Firecracker][2] to shrink the snapshot size of VMs/containers with running JVM processes because pages which only contain zero bytes can be easily removed from the image by making the image *sparse* (e.g. with [`fallocate -p`][3]).
> 
> Notice that uncommitting unused heap parts in the JVM doesn't help in the context of virtualization (e.g. KVM/Firecracker) because from the host perspective they are still dirty and can't be easily removed from the snapshot image because they usually contain some non-zero data. More details can be found in my FOSDEM talk ["Zeroing and the semantic gap between host and guest"][4].
> 
> Furthermore, removing pages which only contain zero bytes (i.e. "empty pages") from a snapshot image not only decreases the image size but also speeds up the restore process because empty pages don't have to be read from the image file but will be populated by the kernel zero page first until they are used for the first time. This also decreases the initial memory footprint of a restored process. 
> 
> An additional argument for memory zeroing is security. By zeroing unused heap parts, we can make sure that secrets contained in unreferenced Java objects are deleted. Something that's currently impossibly to achieve from Java because even if a Java program zeroes out arrays with sensitive data after usage, it can never guarantee that the corresponding object hasn't already been moved by the GC and an old, unreferenced copy of that data still exists somewhere in the heap.
> 
> A prototype implementation for this proposal for Serial, Parallel, G1 and Shenandoah GC is available in the linked pull request.
> 
> [1]: https://criu.org
> [2]: https://github.com/firecracker-microvm/firecracker/blob/main/docs/snapshotting/snapshot-support.md
> [3]: https://man7.org/linux/man-pages/man1/fallocate.1.html
> [4]: https://fosdem.org/2024/schedule/event/fosdem-2024-3454-zeroing-and-the-semantic-gap-between-host-and-guest/

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

  Fix build error on MacOs (with clang, if we use 'override' for a virtual method we have to use it for all methods to avoid '-Winconsistent-missing-override')

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18521/files
  - new: https://git.openjdk.org/jdk/pull/18521/files/b06aa327..4264e53d

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

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

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

From coleenp at openjdk.org  Wed Mar 27 23:47:32 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 27 Mar 2024 23:47:32 GMT
Subject: RFR: 8328507: Move StackWatermark code from safepoint cleanup [v2]
In-Reply-To: <LMUQuZEpeCPn_xdm329qS6K86GSx4T2l_jl2tWuVtuk=.f654c2f0-ddd1-488e-8535-e4f22e75a679@github.com>
References: <KfeqCRDfFUvcktwgMdsAJue9YLYs59GmcD8tZkgbFfE=.ab777a29-cdaa-4249-9b92-4b3338954017@github.com>
 <LMUQuZEpeCPn_xdm329qS6K86GSx4T2l_jl2tWuVtuk=.f654c2f0-ddd1-488e-8535-e4f22e75a679@github.com>
Message-ID: <cj1dSA8rN9JT_A5Ltiqgw0zrCYuY_GzGB6WYOEg5HkQ=.07d1589e-a3fb-466a-97aa-e48c911559b0@github.com>

On Tue, 19 Mar 2024 14:41:33 GMT, Erik ?sterlund <eosterlund at openjdk.org> wrote:

>> There is some stack watermark code in safepoint cleanup that flushes out concurrent stack processing, as a defensive measure to guard safepoint operations that assume the stacks have been fixed up. However, we wish to get rid of safepoint cleanup so this operation should move out from the safepoint. This proposal moves it into CollectedHeap::safepoint_synchronize_begin instead which runs before we start shutting down Java threads. This moves the code into more obvious GC places and reduces time spent inside of non-GC safepoints.
>
> Erik ?sterlund has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove incorrect assert

This makes sense.

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

Marked as reviewed by coleenp (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18378#pullrequestreview-1964934082

From kdnilsen at openjdk.org  Thu Mar 28 00:01:01 2024
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Thu, 28 Mar 2024 00:01:01 GMT
Subject: RFR: 8328307: GenShen: Re-enable old-has-grown trigger for
 old-generation GC [v2]
In-Reply-To: <V2UNOek4Z21vTS_GBk5oi3MfJyC8hkELnTcGc-OxpGU=.09e42b4e-5b0c-493f-8292-6bf78658c553@github.com>
References: <V2UNOek4Z21vTS_GBk5oi3MfJyC8hkELnTcGc-OxpGU=.09e42b4e-5b0c-493f-8292-6bf78658c553@github.com>
Message-ID: <E3I2-9vHa4k7XaKQThxIbniwjJU2ituLZ6RGUhe7prs=.60b52e39-ad9f-49ca-80b0-a5b765398761@github.com>

> Enable old-gen growth triggers, which were inadvertantly disabled.  This passes the internal regression pipeline tests.
> 
> As would be expected, we see an increase in mixed-evacuation triggers.  We also see significant improvement on certain extremem workloads due to improved clearing of old-gen.
> 
> 
>    Control: shenandoah-x86-template
> Experiment: enable-old-growth-triggers-gh-x86
> 
>                           Most impacted benchmarks |                              Most impacted metrics
> -------------------------------------------------------------------------------------------------------
>                            Genshen/extremem-phased |                             trigger_expedite_mixed
>                 Genshen/specjbb2015_weak_ref_patch |                                    trigger_failure
>                                Genshen/specjbb2015 |                               context_switch_count
>                     Genshen/hyperalloc_a3072_o4096 |                                     sla_25000_jops
>                             Shenandoah/specjbb2015 |                                      trigger_learn
> 
> 
>                                 Only in experiment |                                    Only in control
> -------------------------------------------------------------------------------------------------------
>      hyperalloc_a2048_o2048/trigger_expedite_mixed |                   compress/concurrent_thread_roots
>      hyperalloc_a2048_o4096/trigger_expedite_mixed |                        crypto.rsa/ctr_thread_roots
>      hyperalloc_a3072_o2048/trigger_expedite_mixed |                               crypto.rsa/ctr_total
>      hyperalloc_a3072_o4096/trigger_expedite_mixed |               extremem-large-31g/trigger_expansion
>               extremem-large-31g/trigger_overgrown |                  extremem-phased/trigger_expansion
> 
> Genshen
> -------------------------------------------------------------------------------------------------------
> +685.00% specjbb2015_weak_ref_patch/trigger_expedite_mixed p=0.00002
>   Control:      2.500   (+/-  0.68  )         30
>   Test:        19.625   (+/-  4.79  )         10
> 
> +561.90% specjbb2015/trigger_expedite_mixed p=0.00001
>   Control:      2.625   (+/-  0.92  )         30
>   Test:        17.375   (+/-  3.89  )         10
> 
> +225.42% extremem-phased/trigger_expedite_mixed p=0.00000
>   Control:      9.833   (+/-  3.48  )         30
>   Test:        32.000   (+/-  2.58  )         10
> 
> +63.84% hyperalloc_a3072_o4096/evacuation p=0.02662
>   Control:     37....

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

  Respond to reviewer feedback

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

Changes:
  - all: https://git.openjdk.org/shenandoah/pull/409/files
  - new: https://git.openjdk.org/shenandoah/pull/409/files/aed9633f..c9500508

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

  Stats: 113 lines in 4 files changed: 61 ins; 44 del; 8 mod
  Patch: https://git.openjdk.org/shenandoah/pull/409.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah.git pull/409/head:pull/409

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

From shade at openjdk.org  Thu Mar 28 10:55:34 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 28 Mar 2024 10:55:34 GMT
Subject: RFR: 8329134: Reconsider TLAB zapping [v2]
In-Reply-To: <uZhJWOZ46zIL4x_Zv6_SPppmAYLfMkeOkCM-CHUSOx4=.c0269562-c250-4f5b-9aeb-718821f4050a@github.com>
References: <cWkDJ301cKsXnEsx2wDgNV1fzqiYqaYBIXNzrKpvL0o=.5171a404-f1ef-43b7-b879-ff9c514379ad@github.com>
 <uZhJWOZ46zIL4x_Zv6_SPppmAYLfMkeOkCM-CHUSOx4=.c0269562-c250-4f5b-9aeb-718821f4050a@github.com>
Message-ID: <JG1lWWhDZOb6PCLlb7JzKtMnJo0lLUxz65z3FcwzhHE=.01c0b1a1-0d58-45d2-ab6d-c65540b64b46@github.com>

On Wed, 27 Mar 2024 14:55:35 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> We zap the entire TLAB on initial allocation (`MemAllocator::mem_allocate_inside_tlab_slow`), and then also rezap the object contents when object is allocated from the TLAB (`ThreadLocalAllocBuffer::allocate`). The second part seems excessive, given the TLAB is already fully zapped.
>> 
>> There is also no way to disable this zapping, like you would in other places with the relevant Zap* flags.
>> 
>> Fixing both these issues allows to improve fastdebug tests performance, e.g. in jcstress. 
>> 
>> It also allows to remove the related Zero kludge.
>> 
>> Additional testing:
>>  - [x] Linux AArch64 server fastdebug, `all` tests 
>>  - [x] MacOS AArch64 Zero fastdebug, `bootcycle-images` pass
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments

Thanks! I would wait for more reviews now.

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

PR Comment: https://git.openjdk.org/jdk/pull/18500#issuecomment-2024904926

From rkennke at openjdk.org  Thu Mar 28 11:12:36 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Thu, 28 Mar 2024 11:12:36 GMT
Subject: RFR: 8329134: Reconsider TLAB zapping [v2]
In-Reply-To: <uZhJWOZ46zIL4x_Zv6_SPppmAYLfMkeOkCM-CHUSOx4=.c0269562-c250-4f5b-9aeb-718821f4050a@github.com>
References: <cWkDJ301cKsXnEsx2wDgNV1fzqiYqaYBIXNzrKpvL0o=.5171a404-f1ef-43b7-b879-ff9c514379ad@github.com>
 <uZhJWOZ46zIL4x_Zv6_SPppmAYLfMkeOkCM-CHUSOx4=.c0269562-c250-4f5b-9aeb-718821f4050a@github.com>
Message-ID: <Es-59hPafI9KjW9SH1zbNoJFeRnnrmPLgm1LesrpY4g=.d95c2bd6-9516-4ddd-abf8-56bc924ebefc@github.com>

On Wed, 27 Mar 2024 14:55:35 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> We zap the entire TLAB on initial allocation (`MemAllocator::mem_allocate_inside_tlab_slow`), and then also rezap the object contents when object is allocated from the TLAB (`ThreadLocalAllocBuffer::allocate`). The second part seems excessive, given the TLAB is already fully zapped.
>> 
>> There is also no way to disable this zapping, like you would in other places with the relevant Zap* flags.
>> 
>> Fixing both these issues allows to improve fastdebug tests performance, e.g. in jcstress. 
>> 
>> It also allows to remove the related Zero kludge.
>> 
>> Additional testing:
>>  - [x] Linux AArch64 server fastdebug, `all` tests 
>>  - [x] MacOS AArch64 Zero fastdebug, `bootcycle-images` pass
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments

Looks good to me. Thank you!

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

Marked as reviewed by rkennke (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18500#pullrequestreview-1965810416

From eosterlund at openjdk.org  Thu Mar 28 14:02:31 2024
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Thu, 28 Mar 2024 14:02:31 GMT
Subject: RFR: 8328507: Move StackWatermark code from safepoint cleanup [v2]
In-Reply-To: <cj1dSA8rN9JT_A5Ltiqgw0zrCYuY_GzGB6WYOEg5HkQ=.07d1589e-a3fb-466a-97aa-e48c911559b0@github.com>
References: <KfeqCRDfFUvcktwgMdsAJue9YLYs59GmcD8tZkgbFfE=.ab777a29-cdaa-4249-9b92-4b3338954017@github.com>
 <LMUQuZEpeCPn_xdm329qS6K86GSx4T2l_jl2tWuVtuk=.f654c2f0-ddd1-488e-8535-e4f22e75a679@github.com>
 <cj1dSA8rN9JT_A5Ltiqgw0zrCYuY_GzGB6WYOEg5HkQ=.07d1589e-a3fb-466a-97aa-e48c911559b0@github.com>
Message-ID: <TK0ovL8jjjdp5_pmWl2ehVNMYi4NTS5pOm44XDHGJj8=.a321dd84-3449-4976-92a8-33f6b625d70b@github.com>

On Wed, 27 Mar 2024 23:44:52 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Erik ?sterlund has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove incorrect assert
>
> This makes sense.

Thanks for the review, @coleenp and @xmas92!

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

PR Comment: https://git.openjdk.org/jdk/pull/18378#issuecomment-2025256046

From eosterlund at openjdk.org  Thu Mar 28 14:14:39 2024
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Thu, 28 Mar 2024 14:14:39 GMT
Subject: Integrated: 8328507: Move StackWatermark code from safepoint cleanup
In-Reply-To: <KfeqCRDfFUvcktwgMdsAJue9YLYs59GmcD8tZkgbFfE=.ab777a29-cdaa-4249-9b92-4b3338954017@github.com>
References: <KfeqCRDfFUvcktwgMdsAJue9YLYs59GmcD8tZkgbFfE=.ab777a29-cdaa-4249-9b92-4b3338954017@github.com>
Message-ID: <pkwiPRxm-GXiWdwW72lyL5MV2m9DgY_re0GLHujzlIw=.72ad29f3-5c3d-463f-b9df-833c015542f5@github.com>

On Tue, 19 Mar 2024 13:30:39 GMT, Erik ?sterlund <eosterlund at openjdk.org> wrote:

> There is some stack watermark code in safepoint cleanup that flushes out concurrent stack processing, as a defensive measure to guard safepoint operations that assume the stacks have been fixed up. However, we wish to get rid of safepoint cleanup so this operation should move out from the safepoint. This proposal moves it into CollectedHeap::safepoint_synchronize_begin instead which runs before we start shutting down Java threads. This moves the code into more obvious GC places and reduces time spent inside of non-GC safepoints.

This pull request has now been integrated.

Changeset: aa595dbd
Author:    Erik ?sterlund <eosterlund at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/aa595dbda4e64d76eeaff941b2f1e1ef2414d7af
Stats:     76 lines in 11 files changed: 23 ins; 45 del; 8 mod

8328507: Move StackWatermark code from safepoint cleanup

Reviewed-by: aboldtch, coleenp

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

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

From kdnilsen at openjdk.org  Thu Mar 28 15:10:59 2024
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Thu, 28 Mar 2024 15:10:59 GMT
Subject: RFR: 8328307: GenShen: Re-enable old-has-grown trigger for
 old-generation GC [v2]
In-Reply-To: <TfsTJl0K9aiKVBd-VYS6wjmqbBSOvIM-HI9g6B7b12g=.b69c76b4-47d2-4e7e-b9bf-1f13a4930ff3@github.com>
References: <V2UNOek4Z21vTS_GBk5oi3MfJyC8hkELnTcGc-OxpGU=.09e42b4e-5b0c-493f-8292-6bf78658c553@github.com>
 <TfsTJl0K9aiKVBd-VYS6wjmqbBSOvIM-HI9g6B7b12g=.b69c76b4-47d2-4e7e-b9bf-1f13a4930ff3@github.com>
Message-ID: <bGXXewLQGmVmn4piSuZRe8eT03CQZZTksNWsJ8cidFY=.f006d1ac-3200-4561-9d00-7e58977df9b8@github.com>

On Mon, 18 Mar 2024 17:12:31 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Respond to reviewer feedback
>
> src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp line 3194:
> 
>> 3192:   _free_set->rebuild(young_cset_regions, old_cset_regions);
>> 3193: 
>> 3194:   if (mode()->is_generational()) {
> 
> In the spirit of moving generational mode things out of `ShenandoahHeap`, may I suggest factoring out two methods here for `ShenandoahOldGeneration`:
> * `trigger_collection_if_fragmented`
> * `trigger_collection_if_overgrown`
> 
> Or perhaps, make `ShenandoahHeap::rebuild_free_set` virtual and put all the generational code into an override in `ShenandoahGenerationalHeap`?

Done.  Testing now.

> test/hotspot/jtreg/gc/shenandoah/generational/TestOldGrowthTriggers.java line 42:
> 
>> 40: public class TestOldGrowthTriggers {
>> 41: 
>> 42:   public static void do_old_allocations() {
> 
> Nit, but Java convention is usually camel case: `doOldAllocations` or `makeOldAllocations` if the `oO` looks weird to you ;)

Thanks.  Fixed.

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

PR Review Comment: https://git.openjdk.org/shenandoah/pull/409#discussion_r1543141957
PR Review Comment: https://git.openjdk.org/shenandoah/pull/409#discussion_r1543142203

From kdnilsen at openjdk.org  Thu Mar 28 15:10:59 2024
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Thu, 28 Mar 2024 15:10:59 GMT
Subject: RFR: 8328307: GenShen: Re-enable old-has-grown trigger for
 old-generation GC [v2]
In-Reply-To: <t8YntjQPeet6t5dZj-8eQanw15WNo8VX0EO0e2m_WpU=.6e57d042-b317-4956-a539-5cf25b9956c9@github.com>
References: <V2UNOek4Z21vTS_GBk5oi3MfJyC8hkELnTcGc-OxpGU=.09e42b4e-5b0c-493f-8292-6bf78658c553@github.com>
 <t8YntjQPeet6t5dZj-8eQanw15WNo8VX0EO0e2m_WpU=.6e57d042-b317-4956-a539-5cf25b9956c9@github.com>
Message-ID: <cu7rOLd4WvKz_7ik_ueMTDXfufhPa1nMFn9mOiWWdAg=.47c19ad6-38bf-4f9c-b0ba-1a178c8507fb@github.com>

On Mon, 18 Mar 2024 17:25:13 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Respond to reviewer feedback
>
> test/hotspot/jtreg/gc/shenandoah/generational/TestOldGrowthTriggers.java line 61:
> 
>> 59:         int derive_index = r.nextInt(array_size);
>> 60:         switch (i & 0x3) {
>> 61:           case 0:
> 
> Intended to break after each case.  Let me fix this and adjust refill iterations.

Done.  Testing now.

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

PR Review Comment: https://git.openjdk.org/shenandoah/pull/409#discussion_r1543142450

From kdnilsen at openjdk.org  Thu Mar 28 15:16:04 2024
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Thu, 28 Mar 2024 15:16:04 GMT
Subject: RFR: 8328307: GenShen: Re-enable old-has-grown trigger for
 old-generation GC [v3]
In-Reply-To: <V2UNOek4Z21vTS_GBk5oi3MfJyC8hkELnTcGc-OxpGU=.09e42b4e-5b0c-493f-8292-6bf78658c553@github.com>
References: <V2UNOek4Z21vTS_GBk5oi3MfJyC8hkELnTcGc-OxpGU=.09e42b4e-5b0c-493f-8292-6bf78658c553@github.com>
Message-ID: <wHsjJVWBO84dfPPCHX-emXUEbfAYk4v3PzEi_VwbJqA=.927c2b39-7c9e-48a9-a3ca-355e74abd121@github.com>

> Enable old-gen growth triggers, which were inadvertantly disabled.  This passes the internal regression pipeline tests.
> 
> As would be expected, we see an increase in mixed-evacuation triggers.  We also see significant improvement on certain extremem workloads due to improved clearing of old-gen.
> 
> 
>    Control: shenandoah-x86-template
> Experiment: enable-old-growth-triggers-gh-x86
> 
>                           Most impacted benchmarks |                              Most impacted metrics
> -------------------------------------------------------------------------------------------------------
>                            Genshen/extremem-phased |                             trigger_expedite_mixed
>                 Genshen/specjbb2015_weak_ref_patch |                                    trigger_failure
>                                Genshen/specjbb2015 |                               context_switch_count
>                     Genshen/hyperalloc_a3072_o4096 |                                     sla_25000_jops
>                             Shenandoah/specjbb2015 |                                      trigger_learn
> 
> 
>                                 Only in experiment |                                    Only in control
> -------------------------------------------------------------------------------------------------------
>      hyperalloc_a2048_o2048/trigger_expedite_mixed |                   compress/concurrent_thread_roots
>      hyperalloc_a2048_o4096/trigger_expedite_mixed |                        crypto.rsa/ctr_thread_roots
>      hyperalloc_a3072_o2048/trigger_expedite_mixed |                               crypto.rsa/ctr_total
>      hyperalloc_a3072_o4096/trigger_expedite_mixed |               extremem-large-31g/trigger_expansion
>               extremem-large-31g/trigger_overgrown |                  extremem-phased/trigger_expansion
> 
> Genshen
> -------------------------------------------------------------------------------------------------------
> +685.00% specjbb2015_weak_ref_patch/trigger_expedite_mixed p=0.00002
>   Control:      2.500   (+/-  0.68  )         30
>   Test:        19.625   (+/-  4.79  )         10
> 
> +561.90% specjbb2015/trigger_expedite_mixed p=0.00001
>   Control:      2.625   (+/-  0.92  )         30
>   Test:        17.375   (+/-  3.89  )         10
> 
> +225.42% extremem-phased/trigger_expedite_mixed p=0.00000
>   Control:      9.833   (+/-  3.48  )         30
>   Test:        32.000   (+/-  2.58  )         10
> 
> +63.84% hyperalloc_a3072_o4096/evacuation p=0.02662
>   Control:     37....

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

  Fix typo introduced during refactoring

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

Changes:
  - all: https://git.openjdk.org/shenandoah/pull/409/files
  - new: https://git.openjdk.org/shenandoah/pull/409/files/c9500508..052d3811

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

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

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

From kdnilsen at openjdk.org  Thu Mar 28 15:25:09 2024
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Thu, 28 Mar 2024 15:25:09 GMT
Subject: RFR: 8328307: GenShen: Re-enable old-has-grown trigger for
 old-generation GC [v4]
In-Reply-To: <V2UNOek4Z21vTS_GBk5oi3MfJyC8hkELnTcGc-OxpGU=.09e42b4e-5b0c-493f-8292-6bf78658c553@github.com>
References: <V2UNOek4Z21vTS_GBk5oi3MfJyC8hkELnTcGc-OxpGU=.09e42b4e-5b0c-493f-8292-6bf78658c553@github.com>
Message-ID: <zHWoxIJcOqP0w8qLmm3XmZWv3NqBVkbak99puMXWgqo=.94761e8d-0330-4909-b7c0-af1f2248e98d@github.com>

> Enable old-gen growth triggers, which were inadvertantly disabled.  This passes the internal regression pipeline tests.
> 
> As would be expected, we see an increase in mixed-evacuation triggers.  We also see significant improvement on certain extremem workloads due to improved clearing of old-gen.
> 
> 
>    Control: shenandoah-x86-template
> Experiment: enable-old-growth-triggers-gh-x86
> 
>                           Most impacted benchmarks |                              Most impacted metrics
> -------------------------------------------------------------------------------------------------------
>                            Genshen/extremem-phased |                             trigger_expedite_mixed
>                 Genshen/specjbb2015_weak_ref_patch |                                    trigger_failure
>                                Genshen/specjbb2015 |                               context_switch_count
>                     Genshen/hyperalloc_a3072_o4096 |                                     sla_25000_jops
>                             Shenandoah/specjbb2015 |                                      trigger_learn
> 
> 
>                                 Only in experiment |                                    Only in control
> -------------------------------------------------------------------------------------------------------
>      hyperalloc_a2048_o2048/trigger_expedite_mixed |                   compress/concurrent_thread_roots
>      hyperalloc_a2048_o4096/trigger_expedite_mixed |                        crypto.rsa/ctr_thread_roots
>      hyperalloc_a3072_o2048/trigger_expedite_mixed |                               crypto.rsa/ctr_total
>      hyperalloc_a3072_o4096/trigger_expedite_mixed |               extremem-large-31g/trigger_expansion
>               extremem-large-31g/trigger_overgrown |                  extremem-phased/trigger_expansion
> 
> Genshen
> -------------------------------------------------------------------------------------------------------
> +685.00% specjbb2015_weak_ref_patch/trigger_expedite_mixed p=0.00002
>   Control:      2.500   (+/-  0.68  )         30
>   Test:        19.625   (+/-  4.79  )         10
> 
> +561.90% specjbb2015/trigger_expedite_mixed p=0.00001
>   Control:      2.625   (+/-  0.92  )         30
>   Test:        17.375   (+/-  3.89  )         10
> 
> +225.42% extremem-phased/trigger_expedite_mixed p=0.00000
>   Control:      9.833   (+/-  3.48  )         30
>   Test:        32.000   (+/-  2.58  )         10
> 
> +63.84% hyperalloc_a3072_o4096/evacuation p=0.02662
>   Control:     37....

Kelvin Nilsen has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits:

 - Merge branch 'master' of https://git.openjdk.org/shenandoah into enable-old-growth-triggers
 - Fix typo introduced during refactoring
 - Respond to reviewer feedback
 - Add a jtreg test for old growth trigger
 - Re-enable old-growth trigger
 - Make satb-mode Info logging less verbose
 - Merge branch 'openjdk:master' into master
 - Merge branch 'openjdk:master' into master
 - Revert "Round LAB sizes down rather than up to force alignment"
   
   This reverts commit 99cce53b3e6e51cee2ed71e0b7c7caa016a8ed4f.
 - Round LAB sizes down rather than up to force alignment
   
   When we round up, we introduce the risk that the new size exceeds the
   maximum LAB size, resulting in an assertion error.
 - ... and 2 more: https://git.openjdk.org/shenandoah/compare/f1d98490...f99a71ac

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

Changes: https://git.openjdk.org/shenandoah/pull/409/files
  Webrev: https://webrevs.openjdk.org/?repo=shenandoah&pr=409&range=03
  Stats: 218 lines in 4 files changed: 171 ins; 41 del; 6 mod
  Patch: https://git.openjdk.org/shenandoah/pull/409.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah.git pull/409/head:pull/409

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

From kdnilsen at openjdk.org  Thu Mar 28 15:37:28 2024
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Thu, 28 Mar 2024 15:37:28 GMT
Subject: RFR: 8328307: GenShen: Re-enable old-has-grown trigger for
 old-generation GC [v5]
In-Reply-To: <V2UNOek4Z21vTS_GBk5oi3MfJyC8hkELnTcGc-OxpGU=.09e42b4e-5b0c-493f-8292-6bf78658c553@github.com>
References: <V2UNOek4Z21vTS_GBk5oi3MfJyC8hkELnTcGc-OxpGU=.09e42b4e-5b0c-493f-8292-6bf78658c553@github.com>
Message-ID: <BFuizLduIbx5NeR5F_0MVUqDCbZJsCbGGrzVESBsS8w=.5848ac32-fcb0-4a0e-94ce-b76f34fa2629@github.com>

> Enable old-gen growth triggers, which were inadvertantly disabled.  This passes the internal regression pipeline tests.
> 
> As would be expected, we see an increase in mixed-evacuation triggers.  We also see significant improvement on certain extremem workloads due to improved clearing of old-gen.
> 
> 
>    Control: shenandoah-x86-template
> Experiment: enable-old-growth-triggers-gh-x86
> 
>                           Most impacted benchmarks |                              Most impacted metrics
> -------------------------------------------------------------------------------------------------------
>                            Genshen/extremem-phased |                             trigger_expedite_mixed
>                 Genshen/specjbb2015_weak_ref_patch |                                    trigger_failure
>                                Genshen/specjbb2015 |                               context_switch_count
>                     Genshen/hyperalloc_a3072_o4096 |                                     sla_25000_jops
>                             Shenandoah/specjbb2015 |                                      trigger_learn
> 
> 
>                                 Only in experiment |                                    Only in control
> -------------------------------------------------------------------------------------------------------
>      hyperalloc_a2048_o2048/trigger_expedite_mixed |                   compress/concurrent_thread_roots
>      hyperalloc_a2048_o4096/trigger_expedite_mixed |                        crypto.rsa/ctr_thread_roots
>      hyperalloc_a3072_o2048/trigger_expedite_mixed |                               crypto.rsa/ctr_total
>      hyperalloc_a3072_o4096/trigger_expedite_mixed |               extremem-large-31g/trigger_expansion
>               extremem-large-31g/trigger_overgrown |                  extremem-phased/trigger_expansion
> 
> Genshen
> -------------------------------------------------------------------------------------------------------
> +685.00% specjbb2015_weak_ref_patch/trigger_expedite_mixed p=0.00002
>   Control:      2.500   (+/-  0.68  )         30
>   Test:        19.625   (+/-  4.79  )         10
> 
> +561.90% specjbb2015/trigger_expedite_mixed p=0.00001
>   Control:      2.625   (+/-  0.92  )         30
>   Test:        17.375   (+/-  3.89  )         10
> 
> +225.42% extremem-phased/trigger_expedite_mixed p=0.00000
>   Control:      9.833   (+/-  3.48  )         30
>   Test:        32.000   (+/-  2.58  )         10
> 
> +63.84% hyperalloc_a3072_o4096/evacuation p=0.02662
>   Control:     37....

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

  Fix another typo

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

Changes:
  - all: https://git.openjdk.org/shenandoah/pull/409/files
  - new: https://git.openjdk.org/shenandoah/pull/409/files/f99a71ac..e9fcdc16

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

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

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

From kdnilsen at openjdk.org  Thu Mar 28 16:06:58 2024
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Thu, 28 Mar 2024 16:06:58 GMT
Subject: RFR: 8324649: Shenandoah: refactor implementation of free set
 [v39]
In-Reply-To: <VAkn0SrKYZWmnflpM8ZwVAXjUF1LjA0_FCBmRJJ4VSc=.c2f979bd-2957-434e-95ca-7b11b1573900@github.com>
References: <VAkn0SrKYZWmnflpM8ZwVAXjUF1LjA0_FCBmRJJ4VSc=.c2f979bd-2957-434e-95ca-7b11b1573900@github.com>
Message-ID: <aRJBboj41vv0D7F4jIrN2kzBZoXYEbIMrMfAIO3IMjg=.9e7917b1-7912-4409-bf51-bb073f133374@github.com>

> Several objectives:
> 1. Reduce humongous allocation failures by segregating regular regions from humongous regions
> 2. Do not retire regions just because an allocation failed within the region if the memory remaining within the region is large enough to represent a LAB
> 3. Track range of empty regions in addition to range of available regions in order to expedite humongous allocations
> 4. Treat collector reserves as available for Mutator allocations after evacuation completes
> 5. Improve encapsulation so as to enable an OldCollector reserve for future integration of generational Shenandoah
> 
> We have compared performance of existing FreeSet implementation with the proposed PR over a broad set of performance workloads and see that the impact is mostly neutral.
> 
> Comparing 105235.0 metrics from control, 220638.0 from experiment.
> Compare: 0.589s
>                           Most impacted benchmarks |                              Most impacted metrics
> -------------------------------------------------------------------------------------------------------
>                                  Shenandoah/jython |                                          cwr_total
> 
> 
>                                 Only in experiment |                                    Only in control
> -------------------------------------------------------------------------------------------------------
>                  crypto.signverify/trigger_failure |                        crypto.rsa/cmr_thread_roots
>                 extremem-large-31g/adjust_pointers |       scimark.sparse.small/concurrent_thread_roots
>             extremem-large-31g/calculate_addresses |              xml.transform/concurrent_thread_roots
>       crypto.signverify/class_unloading_rendezvous |                    mpegaudio/concurrent_weak_roots
>                                   serial/cmr_total |                        crypto.rsa/ctr_thread_roots
> 
> Shenandoah
> -------------------------------------------------------------------------------------------------------
> +5.64% jython/cwr_total p=0.00037
>   Control:      1.928ms (+/-272.40us)        170
>   Test:         2.037ms (+/-322.73us)        344

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

  Remove debugging instrumentation

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17561/files
  - new: https://git.openjdk.org/jdk/pull/17561/files/7bc418fa..84c5875d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17561&range=38
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17561&range=37-38

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

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

From kdnilsen at openjdk.org  Thu Mar 28 16:06:58 2024
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Thu, 28 Mar 2024 16:06:58 GMT
Subject: RFR: 8324649: Shenandoah: refactor implementation of free set
 [v38]
In-Reply-To: <D5wRh8BgYZ1twV9FH6kwu97L48ohmuGLW59zjaK15OI=.5a1de2d3-976a-4ea0-9ce5-e0c1a84f1b52@github.com>
References: <VAkn0SrKYZWmnflpM8ZwVAXjUF1LjA0_FCBmRJJ4VSc=.c2f979bd-2957-434e-95ca-7b11b1573900@github.com>
 <gV1jCqm2734Y1iPvnR7l85mor-ByjrqBcT2VMPDNnno=.03f625ff-2b64-4bb0-b9fe-d645c3fd319b@github.com>
 <VVAFcCU-skwyZu83gyF076NsHIZhnOkK5yaTy_PBWN4=.47eca5e5-96fd-4abe-9b89-a6add83077fd@github.com>
 <D5wRh8BgYZ1twV9FH6kwu97L48ohmuGLW59zjaK15OI=.5a1de2d3-976a-4ea0-9ce5-e0c1a84f1b52@github.com>
Message-ID: <SqHFCUBesjqpzOlKAwjilcdmvvCGMiPTOcrtfbsBfV4=.a3d00346-f0fb-4bb7-b448-465928ac6a9a@github.com>

On Tue, 26 Mar 2024 16:44:25 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp line 53:
>> 
>>> 51:   uintx omit_mask = right_n_bits(bit_number);
>>> 52:   uintx mask = ((uintx) 0 - 1) & ~omit_mask;
>>> 53: #undef KELVIN_DEBUG
>> 
>> Please remove KELVIN_DEBUG before integration. You may want to turn it into proper logging, if you think it may be useful.
>
> log_*_develop() is only built in debug builds, that may be useful.

Thanks for that catch.  Removing.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17561#discussion_r1543223245

From wkemper at openjdk.org  Thu Mar 28 16:30:52 2024
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 28 Mar 2024 16:30:52 GMT
Subject: Integrated: 8328626: GenShen: Combine old generation surplus/deficit
 fields into a single balance field
In-Reply-To: <aoGfU4G3UAbcCMY1yHupTPG1yAf9wQbJ6C1kZ6T7K6Q=.4324cfc3-d477-4e68-b73b-4f38b59b2277@github.com>
References: <aoGfU4G3UAbcCMY1yHupTPG1yAf9wQbJ6C1kZ6T7K6Q=.4324cfc3-d477-4e68-b73b-4f38b59b2277@github.com>
Message-ID: <VzTytYo6Oz-nsIWwzbsZ8_a67NUP_xuAuURPVyk38Kg=.3bb3031d-1b83-4e50-aa00-5553a34f901b@github.com>

On Wed, 20 Mar 2024 21:09:56 GMT, William Kemper <wkemper at openjdk.org> wrote:

> This is a follow up to https://github.com/openjdk/shenandoah/pull/406.

This pull request has now been integrated.

Changeset: 573618e6
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.org/shenandoah/commit/573618e60e4c5201d3cbce2dbb9c0112ce852b4a
Stats:     277 lines in 10 files changed: 100 ins; 119 del; 58 mod

8328626: GenShen: Combine old generation surplus/deficit fields into a single balance field

Reviewed-by: kdnilsen, ysr

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

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

From wkemper at openjdk.org  Fri Mar 29 14:15:01 2024
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 29 Mar 2024 14:15:01 GMT
Subject: RFR: Merge openjdk/jdk:master
Message-ID: <wtKK8aVEN5OGNEkDW9SJMxFAwn8JQ7KcBC1mgVSOrV4=.062d2de2-7ead-4ac1-a395-66ddbae4a22e@github.com>

Merges tag jdk-23+16

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

Commit messages:
 - 8329178: Clean up jdk.accessibility native compilation
 - 8329096: G1: Change the type of G1BlockOffsetTable::_offset_base to uint8_t*
 - 8328986: Deprecate UseRTM* flags for removal
 - 8327875: ChoiceFormat should advise throwing UnsupportedOperationException for unused methods
 - 8328819: Remove applet usage from JFileChooser tests bug6698013
 - 8328227: Remove applet usage from JColorChooser tests Test4887836
 - 8329189: runtime/stack/Stack016.java fails on libgraal
 - 8329163: C2: possible overflow in PhaseIdealLoop::extract_long_range_checks()
 - 8328638: Fallback option for POST-only OCSP requests
 - 8329086: Clean up java.desktop native compilation
 - ... and 104 more: https://git.openjdk.org/shenandoah/compare/481473ef...d580bcf9

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

Changes: https://git.openjdk.org/shenandoah/pull/412/files
  Stats: 60155 lines in 2428 files changed: 11537 ins; 6518 del; 42100 mod
  Patch: https://git.openjdk.org/shenandoah/pull/412.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah.git pull/412/head:pull/412

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

From wkemper at openjdk.org  Fri Mar 29 20:26:17 2024
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 29 Mar 2024 20:26:17 GMT
Subject: RFR: Merge openjdk/jdk:master [v2]
In-Reply-To: <wtKK8aVEN5OGNEkDW9SJMxFAwn8JQ7KcBC1mgVSOrV4=.062d2de2-7ead-4ac1-a395-66ddbae4a22e@github.com>
References: <wtKK8aVEN5OGNEkDW9SJMxFAwn8JQ7KcBC1mgVSOrV4=.062d2de2-7ead-4ac1-a395-66ddbae4a22e@github.com>
Message-ID: <c8zNdV1_BpnZhc3rJWsRTLyx5CDs288GLKuvQb_4Ops=.6690f213-fd52-4abe-a237-fdd0cab1c382@github.com>

> Merges tag jdk-23+16

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/412/files
  - new: https://git.openjdk.org/shenandoah/pull/412/files/d580bcf9..d580bcf9

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

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

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

From wkemper at openjdk.org  Fri Mar 29 20:26:19 2024
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 29 Mar 2024 20:26:19 GMT
Subject: Integrated: Merge openjdk/jdk:master
In-Reply-To: <wtKK8aVEN5OGNEkDW9SJMxFAwn8JQ7KcBC1mgVSOrV4=.062d2de2-7ead-4ac1-a395-66ddbae4a22e@github.com>
References: <wtKK8aVEN5OGNEkDW9SJMxFAwn8JQ7KcBC1mgVSOrV4=.062d2de2-7ead-4ac1-a395-66ddbae4a22e@github.com>
Message-ID: <Wy5n6LmlPd2q5PLN95DjTQfS_w2ClXp3MP1HNK6kELY=.22bcb446-b4ae-455a-a739-ea3068f8605b@github.com>

On Fri, 29 Mar 2024 14:09:38 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Merges tag jdk-23+16

This pull request has now been integrated.

Changeset: c6d39d0a
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.org/shenandoah/commit/c6d39d0a4d376b8550f2f80628985b0cdc13e639
Stats:     60155 lines in 2428 files changed: 11537 ins; 6518 del; 42100 mod

Merge

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

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

From wkemper at openjdk.org  Fri Mar 29 20:33:12 2024
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 29 Mar 2024 20:33:12 GMT
Subject: RFR: 8329342: GenShen: Synchronize shenandoah-jdk21u:master with
 shenandoah:master
Message-ID: <BLGkG6VPUxEesmsfk-vAEt2lWQQwizYWyha0_f3uAcI=.a5965c43-e923-4f1e-91b3-cf06f4b7e28b@github.com>

Pull in recent changes from shenandoah:master, _en masse_.

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

Commit messages:
 - Sync up gtest test
 - Merge remote-tracking branch 'shenandoah-21/master' into synch-up-with-shenandoah-master
 - Fix up tests
 - Sync up with shenandoah tip
 - Merge remote-tracking branch 'openjdk-21u-dev/master' into synch-up-with-shenandoah-master
 - 8328825: Google CAInterop test failures
 - 8328948: GHA: Restoring sysroot from cache skips the build after JDK-8326960
 - 8327261: Parsing test for Double/Float succeeds w/o testing all bad cases
 - 8319648: java/lang/SecurityManager tests ignore vm flags
 - 8326948: Force English locale for timeout formatting
 - ... and 115 more: https://git.openjdk.org/shenandoah-jdk21u/compare/2531dfa3...6e465522

Changes: https://git.openjdk.org/shenandoah-jdk21u/pull/29/files
  Webrev: https://webrevs.openjdk.org/?repo=shenandoah-jdk21u&pr=29&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8329342
  Stats: 27289 lines in 545 files changed: 14653 ins; 7206 del; 5430 mod
  Patch: https://git.openjdk.org/shenandoah-jdk21u/pull/29.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah-jdk21u.git pull/29/head:pull/29

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

From wkemper at openjdk.org  Fri Mar 29 20:33:12 2024
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 29 Mar 2024 20:33:12 GMT
Subject: RFR: 8329342: GenShen: Synchronize shenandoah-jdk21u:master with
 shenandoah:master
In-Reply-To: <BLGkG6VPUxEesmsfk-vAEt2lWQQwizYWyha0_f3uAcI=.a5965c43-e923-4f1e-91b3-cf06f4b7e28b@github.com>
References: <BLGkG6VPUxEesmsfk-vAEt2lWQQwizYWyha0_f3uAcI=.a5965c43-e923-4f1e-91b3-cf06f4b7e28b@github.com>
Message-ID: <J6iCJ--WncXj0oPEQxgyu2iEp8PXbypuFqAP8ph-4b8=.f14ce897-f61c-4ae8-9cb8-e87da801706f@github.com>

On Fri, 29 Mar 2024 16:40:12 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Pull in recent changes from shenandoah:master, _en masse_.

Zero build failure is a known issue and will be fixed by https://github.com/openjdk/shenandoah/pull/401

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

PR Comment: https://git.openjdk.org/shenandoah-jdk21u/pull/29#issuecomment-2027707200

From wkemper at openjdk.org  Fri Mar 29 21:21:18 2024
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 29 Mar 2024 21:21:18 GMT
Subject: RFR: 8329350: GenShen: Do not reset mark bitmaps on a safepoint
Message-ID: <9D7mi7sbY8lCY9njdei5rIyosleJYr7EW5NbQdvy4oY=.e660695f-7f43-453d-9fc4-6983633035f4@github.com>

Shenandoah is currently resetting mark bitmaps during the init mark pause. This work should happen during the concurrent reset phase to avoid prolonging the safepoint. Also, free regions need to have the corresponding bitmap region reset or we risk having marked regions with no live data (which violates asserts during final mark).

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

Commit messages:
 - Remove TODO comment (not going to do it here)
 - No thank you, CLION
 - Need to reset bitmaps for free regions
 - Do not clear mark bitmaps on a safepoint

Changes: https://git.openjdk.org/shenandoah/pull/413/files
  Webrev: https://webrevs.openjdk.org/?repo=shenandoah&pr=413&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8329350
  Stats: 134 lines in 11 files changed: 66 ins; 57 del; 11 mod
  Patch: https://git.openjdk.org/shenandoah/pull/413.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah.git pull/413/head:pull/413

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

From wkemper at openjdk.org  Fri Mar 29 21:24:04 2024
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 29 Mar 2024 21:24:04 GMT
Subject: Integrated: Merge openjdk/jdk21u-dev:master
Message-ID: <EHKnfnlmDFOyNFw0nVz55WjGkoBYeBqygqgev0JhPeA=.b8dee5b4-65e8-44cb-abae-f7ae0ee032b1@github.com>

We have 'upstream' changes in `jdk21u-dev` that are not available in `jdk21u`. This merge takes changes from `jdk21u-dev`.

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

Commit messages:
 - Merge remote-tracking branch 'openjdk-21u-dev/master' into merge-jdk21u-dev-into-shenandoah-21u-master
 - Merge
 - Merge
 - 8325670: GenShen: Allow old to expand at end of each GC
 - 8326626: GenShen: Remove dead code associated with non-elastic TLABS
 - Merge
 - Merge
 - Merge
 - 8324173: GenShen: Fix error that could cause young gcs to fail when old marking is running
 - 8321816: GenShen: Provide a minimum amount of time for an old collection to run
 - ... and 13 more: https://git.openjdk.org/shenandoah-jdk21u/compare/f2a013bd...144f87c9

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

Changes: https://git.openjdk.org/shenandoah-jdk21u/pull/30/files
  Stats: 21982 lines in 221 files changed: 19951 ins; 952 del; 1079 mod
  Patch: https://git.openjdk.org/shenandoah-jdk21u/pull/30.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah-jdk21u.git pull/30/head:pull/30

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

From wkemper at openjdk.org  Fri Mar 29 21:24:05 2024
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 29 Mar 2024 21:24:05 GMT
Subject: Integrated: Merge openjdk/jdk21u-dev:master
In-Reply-To: <EHKnfnlmDFOyNFw0nVz55WjGkoBYeBqygqgev0JhPeA=.b8dee5b4-65e8-44cb-abae-f7ae0ee032b1@github.com>
References: <EHKnfnlmDFOyNFw0nVz55WjGkoBYeBqygqgev0JhPeA=.b8dee5b4-65e8-44cb-abae-f7ae0ee032b1@github.com>
Message-ID: <YRDJMIlcxc1W4oah1aYk_gIcBl2xtR0Ry4ZVHwSrAu0=.dba9ecdb-3eac-4376-b8a6-5143c044963d@github.com>

On Fri, 29 Mar 2024 21:19:36 GMT, William Kemper <wkemper at openjdk.org> wrote:

> We have 'upstream' changes in `jdk21u-dev` that are not available in `jdk21u`. This merge takes changes from `jdk21u-dev`.

This pull request has now been integrated.

Changeset: 176d2328
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.org/shenandoah-jdk21u/commit/176d2328f6dd881f0f53c763c1f3d9c8a73fadd0
Stats:     21638 lines in 473 files changed: 11711 ins; 4989 del; 4938 mod

Merge

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

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

From wkemper at openjdk.org  Fri Mar 29 21:26:25 2024
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 29 Mar 2024 21:26:25 GMT
Subject: RFR: 8329342: GenShen: Synchronize shenandoah-jdk21u:master with
 shenandoah:master [v2]
In-Reply-To: <BLGkG6VPUxEesmsfk-vAEt2lWQQwizYWyha0_f3uAcI=.a5965c43-e923-4f1e-91b3-cf06f4b7e28b@github.com>
References: <BLGkG6VPUxEesmsfk-vAEt2lWQQwizYWyha0_f3uAcI=.a5965c43-e923-4f1e-91b3-cf06f4b7e28b@github.com>
Message-ID: <_5KloWY2US-Yxgu1qD54H09M22U5MX8ZFb8O0jDt29Y=.4196c912-9f44-4b25-b570-67f766a982ea@github.com>

> Pull in recent changes from shenandoah:master, _en masse_.

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

 - Sync up gtest test
 - Merge remote-tracking branch 'shenandoah-21/master' into synch-up-with-shenandoah-master
 - Merge
 - Merge
 - Fix up tests
 - Sync up with shenandoah tip
 - Merge remote-tracking branch 'openjdk-21u-dev/master' into synch-up-with-shenandoah-master
 - 8324325: [Genshen] Normalize wrt AgeTable changes from JDK-8314329
   
   Make GenShen consistent with changes in JDK-8314329.
   
   Reviewed-by: shade
 - 8325670: GenShen: Allow old to expand at end of each GC
   
   Backport-of: 2f1fa6dbe2b6dcea15603ac42087af83961622f9
 - 8326626: GenShen: Remove dead code associated with non-elastic TLABS
   
   Backport-of: 9fde64ecf7f4954dbd4028a57cdeb400de8b0268
 - ... and 18 more: https://git.openjdk.org/shenandoah-jdk21u/compare/f2a013bd...6e465522

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

Changes: https://git.openjdk.org/shenandoah-jdk21u/pull/29/files
  Webrev: https://webrevs.openjdk.org/?repo=shenandoah-jdk21u&pr=29&range=01
  Stats: 23634 lines in 234 files changed: 21102 ins; 1378 del; 1154 mod
  Patch: https://git.openjdk.org/shenandoah-jdk21u/pull/29.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah-jdk21u.git pull/29/head:pull/29

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

From wkemper at openjdk.org  Fri Mar 29 22:12:02 2024
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 29 Mar 2024 22:12:02 GMT
Subject: RFR: 8329342: GenShen: Synchronize shenandoah-jdk21u:master with
 shenandoah:master [v2]
In-Reply-To: <_5KloWY2US-Yxgu1qD54H09M22U5MX8ZFb8O0jDt29Y=.4196c912-9f44-4b25-b570-67f766a982ea@github.com>
References: <BLGkG6VPUxEesmsfk-vAEt2lWQQwizYWyha0_f3uAcI=.a5965c43-e923-4f1e-91b3-cf06f4b7e28b@github.com>
 <_5KloWY2US-Yxgu1qD54H09M22U5MX8ZFb8O0jDt29Y=.4196c912-9f44-4b25-b570-67f766a982ea@github.com>
Message-ID: <cgwub7F6oiX6VQWx1123UOfJPnR9erqQWKpdIj7vn6w=.f8da98da-d81c-4b3e-86e3-692156f2a6b1@github.com>

On Fri, 29 Mar 2024 21:26:25 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> Pull in recent changes from shenandoah:master, _en masse_.
>
> William Kemper has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 28 commits:
> 
>  - Sync up gtest test
>  - Merge remote-tracking branch 'shenandoah-21/master' into synch-up-with-shenandoah-master
>  - Merge
>  - Merge
>  - Fix up tests
>  - Sync up with shenandoah tip
>  - Merge remote-tracking branch 'openjdk-21u-dev/master' into synch-up-with-shenandoah-master
>  - 8324325: [Genshen] Normalize wrt AgeTable changes from JDK-8314329
>    
>    Make GenShen consistent with changes in JDK-8314329.
>    
>    Reviewed-by: shade
>  - 8325670: GenShen: Allow old to expand at end of each GC
>    
>    Backport-of: 2f1fa6dbe2b6dcea15603ac42087af83961622f9
>  - 8326626: GenShen: Remove dead code associated with non-elastic TLABS
>    
>    Backport-of: 9fde64ecf7f4954dbd4028a57cdeb400de8b0268
>  - ... and 18 more: https://git.openjdk.org/shenandoah-jdk21u/compare/f2a013bd...6e465522

Abandoning this PR in favor of: https://github.com/openjdk/shenandoah-jdk21u/pull/29

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

PR Comment: https://git.openjdk.org/shenandoah-jdk21u/pull/29#issuecomment-2027781767

From wkemper at openjdk.org  Fri Mar 29 22:12:02 2024
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 29 Mar 2024 22:12:02 GMT
Subject: Withdrawn: 8329342: GenShen: Synchronize shenandoah-jdk21u:master with
 shenandoah:master
In-Reply-To: <BLGkG6VPUxEesmsfk-vAEt2lWQQwizYWyha0_f3uAcI=.a5965c43-e923-4f1e-91b3-cf06f4b7e28b@github.com>
References: <BLGkG6VPUxEesmsfk-vAEt2lWQQwizYWyha0_f3uAcI=.a5965c43-e923-4f1e-91b3-cf06f4b7e28b@github.com>
Message-ID: <YcVBceyRuOHEus9hnUFD-d8l0F_mYPp5TJoo2PVo8wo=.693b7b46-73c6-456a-90bd-8df7100e7a86@github.com>

On Fri, 29 Mar 2024 16:40:12 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Pull in recent changes from shenandoah:master, _en masse_.

This pull request has been closed without being integrated.

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

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

From wkemper at openjdk.org  Fri Mar 29 22:12:29 2024
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 29 Mar 2024 22:12:29 GMT
Subject: RFR: 8329342: GenShen: Synchronize shenandoah-jdk21u:master with
 shenandoah:master
Message-ID: <Sge-9K0CA-yVExf4NZXAFtLHVl4wWyuNOowyj3AU0C4=.db32b336-b20d-401a-accb-50d92a4a74a3@github.com>

The delta for this fork has grown too great for individual backport PRs. This change synchronizes the `shenandoah-jdk21u` fork by essentially checking out the `shenandoah` directory from `shenandoah` and reverting the few things we can't take because of changes outside of `shenandoah`.

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

Commit messages:
 - 8324325: [Genshen] Normalize wrt AgeTable changes from JDK-8314329
 - Sync up gtest test
 - Fix up tests
 - Sync up with shenandoah tip

Changes: https://git.openjdk.org/shenandoah-jdk21u/pull/31/files
  Webrev: https://webrevs.openjdk.org/?repo=shenandoah-jdk21u&pr=31&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8329342
  Stats: 5656 lines in 76 files changed: 2945 ins; 2220 del; 491 mod
  Patch: https://git.openjdk.org/shenandoah-jdk21u/pull/31.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah-jdk21u.git pull/31/head:pull/31

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

From kdnilsen at openjdk.org  Fri Mar 29 23:41:58 2024
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Fri, 29 Mar 2024 23:41:58 GMT
Subject: RFR: 8329342: GenShen: Synchronize shenandoah-jdk21u:master with
 shenandoah:master
In-Reply-To: <Sge-9K0CA-yVExf4NZXAFtLHVl4wWyuNOowyj3AU0C4=.db32b336-b20d-401a-accb-50d92a4a74a3@github.com>
References: <Sge-9K0CA-yVExf4NZXAFtLHVl4wWyuNOowyj3AU0C4=.db32b336-b20d-401a-accb-50d92a4a74a3@github.com>
Message-ID: <S9kL5-P9AHT2dY9NugDKaOoXZ2810qdOvz1-i9Gk7uI=.8db6a1dd-fd13-49bd-863a-1298a23753f9@github.com>

On Fri, 29 Mar 2024 22:08:06 GMT, William Kemper <wkemper at openjdk.org> wrote:

> The delta for this fork has grown too great for individual backport PRs. This change synchronizes the `shenandoah-jdk21u` fork by essentially checking out the `shenandoah` directory from `shenandoah` and reverting the few things we can't take because of changes outside of `shenandoah`.

Thanks for pulling all these pieces together.  LGTM.

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

Marked as reviewed by kdnilsen (Committer).

PR Review: https://git.openjdk.org/shenandoah-jdk21u/pull/31#pullrequestreview-1969684200

From wkemper at openjdk.org  Fri Mar 29 23:45:42 2024
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 29 Mar 2024 23:45:42 GMT
Subject: RFR: 8329342: GenShen: Synchronize shenandoah-jdk21u:master with
 shenandoah:master
In-Reply-To: <Sge-9K0CA-yVExf4NZXAFtLHVl4wWyuNOowyj3AU0C4=.db32b336-b20d-401a-accb-50d92a4a74a3@github.com>
References: <Sge-9K0CA-yVExf4NZXAFtLHVl4wWyuNOowyj3AU0C4=.db32b336-b20d-401a-accb-50d92a4a74a3@github.com>
Message-ID: <JROd2sY2ZrTCHEg8KwdAdpEfvQr9DsgO-oA_4-TipNU=.dccbd235-c8b8-4a4e-b8cc-14ddd8bbe6e1@github.com>

On Fri, 29 Mar 2024 22:08:06 GMT, William Kemper <wkemper at openjdk.org> wrote:

> The delta for this fork has grown too great for individual backport PRs. This change synchronizes the `shenandoah-jdk21u` fork by essentially checking out the `shenandoah` directory from `shenandoah` and reverting the few things we can't take because of changes outside of `shenandoah`.

Thanks for the review. I'm going to integrate once the GHA tests look good.

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

PR Comment: https://git.openjdk.org/shenandoah-jdk21u/pull/31#issuecomment-2027825033

From kvn at openjdk.org  Sat Mar 30 01:48:47 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Sat, 30 Mar 2024 01:48:47 GMT
Subject: RFR: 8329332: Remove CompiledMethod and CodeBlobLayout classes
Message-ID: <ImQruaXQMD_OppiLZDYuic6PsiEeXofKOzFAE1XrD0s=.c9d0a2ee-ef41-4e4e-82eb-135405111962@github.com>

Revert [JDK-8152664](https://bugs.openjdk.org/browse/JDK-8152664) RFE [changes](https://github.com/openjdk/jdk/commit/b853eb7f5ca24eeeda18acbb14287f706499c365) which was used for AOT [JEP 295](https://openjdk.org/jeps/295) implementation in JDK 9. The code was left in HotSpot assuming it will help in a future. But during work on Leyden we decided to not use it. In Leyden cached compiled code will be restored in CodeCache as normal nmethods: no need to change VM's runtime and GC code to process them.

I may work on optimizing `CodeBlob` and `nmethod` fields layout to reduce header size in separate changes. In these changes I did simple fields reordering to keep small (1 byte) fields together.

I do not see (and not expected) performance difference with these changes.

Tested tier1-5, xcomp, stress. Running performance testing.

I need help with testing on platforms which Oracle does not support.

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

Commit messages:
 - remove trailing whitespace
 - 8329332: Remove CompiledMethod and CodeBlobLayout classes

Changes: https://git.openjdk.org/jdk/pull/18554/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18554&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8329332
  Stats: 3885 lines in 118 files changed: 1281 ins; 1723 del; 881 mod
  Patch: https://git.openjdk.org/jdk/pull/18554.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18554/head:pull/18554

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

From ysr at openjdk.org  Sat Mar 30 08:16:54 2024
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Sat, 30 Mar 2024 08:16:54 GMT
Subject: RFR: 8329342: GenShen: Synchronize shenandoah-jdk21u:master with
 shenandoah:master
In-Reply-To: <Sge-9K0CA-yVExf4NZXAFtLHVl4wWyuNOowyj3AU0C4=.db32b336-b20d-401a-accb-50d92a4a74a3@github.com>
References: <Sge-9K0CA-yVExf4NZXAFtLHVl4wWyuNOowyj3AU0C4=.db32b336-b20d-401a-accb-50d92a4a74a3@github.com>
Message-ID: <4oe1pJLz1MtXp_KJGXp6EKcQBFXuHzf98omPoo2rLM8=.4fccd52a-9997-42e9-9720-9f62b4138243@github.com>

On Fri, 29 Mar 2024 22:08:06 GMT, William Kemper <wkemper at openjdk.org> wrote:

> The delta for this fork has grown too great for individual backport PRs. This change synchronizes the `shenandoah-jdk21u` fork by essentially checking out the `shenandoah` directory from `shenandoah` and reverting the few things we can't take because of changes outside of `shenandoah`.

This is an excellent move. Thank you!

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

Marked as reviewed by ysr (Committer).

PR Review: https://git.openjdk.org/shenandoah-jdk21u/pull/31#pullrequestreview-1969857133