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