RFR: 8349094: GenShen: Race between control and regulator threads may violate assertions [v14]

Y. Srinivas Ramakrishna ysr at openjdk.org
Wed Feb 26 01:32:06 UTC 2025


On Wed, 26 Feb 2025 01:22:05 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

>> William Kemper has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 32 commits:
>> 
>>  - Merge tag 'jdk-25+11' into fix-control-regulator-threads
>>    
>>    Added tag jdk-25+11 for changeset 0131c1bf
>>  - Address review feedback (better comments, better names)
>>  - Merge remote-tracking branch 'jdk/master' into fix-control-regulator-threads
>>  - Old gen bootstrap cycle must make it to init mark
>>  - Merge remote-tracking branch 'jdk/master' into fix-control-regulator-threads
>>  - Improve message for assertion
>>  - Make shutdown safer for threads requesting (or expecting) gc
>>  - Do not accept requests if control thread is terminating
>>  - Notify waiters when control thread terminates
>>  - Add event for control thread state changes
>>  - ... and 22 more: https://git.openjdk.org/jdk/compare/0131c1bf...d7858deb
>
> src/hotspot/share/gc/shenandoah/shenandoahHeap.hpp line 687:
> 
>> 685:   HeapWord* allocate_from_gclab_slow(Thread* thread, size_t size);
>> 686:   HeapWord* allocate_new_gclab(size_t min_size, size_t word_size, size_t* actual_size);
>> 687:   bool retry_allocation(size_t original_full_gc_count) const;
> 
> It feels like this should be called `should_retry_allocation()`. Also a 1-line documentation comment: ``` // We want to retry an unsuccessful attempt at allocation until at least a full gc. ```

PS: do we know that a full gc will reclaim all soft refs? I suppose that is Shenandoah policy?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23475#discussion_r1970762980


More information about the hotspot-gc-dev mailing list