RFR: Expand old on demand [v63]

Kelvin Nilsen kdnilsen at openjdk.org
Thu May 25 16:50:02 UTC 2023


On Thu, 25 May 2023 15:27:02 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> Kelvin Nilsen has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Allow OOM failures to occur more quickly
>>    
>>    After a change to increase the defaulit number of consecutive
>>    degenerated cycles that can occur before a full gc is triggered,
>>    the number of allocation retries that must be completed before throwing
>>    an OutOfMemory exception increased significantly.  This commit provides
>>    a mechanism to more quickly decide to throw OOM.
>>  - Revert default value of ShenandoahGuaranteedYoungGCInterval
>>    
>>    The previous change was somewhat arbitrary and masks a bigger problem
>>    with triggering GC following periods of idle activity.  An alternative
>>    approach to triggering should be developed in the future.
>
> src/hotspot/share/gc/shenandoah/shenandoahHeap.hpp line 358:
> 
>> 356: 
>> 357:   // How many full-gc cycles have been completed?
>> 358:   volatile size_t _completed_fullgc_cycles;
> 
> `ShenandoahCollectorPolicy` already counts full GC cycles (implicit and  explicit). We could add a `get_full_gc_count` there without duplicating any functionality.

good idea.  I searched around and couldn't figure out where this was.  I'll pursue this simplification.

> src/hotspot/share/gc/shenandoah/shenandoahHeap.hpp line 397:
> 
>> 395: 
>> 396:   void finish_fullgc() {
>> 397:     Atomic::add(&_completed_fullgc_cycles, (size_t) 1);
> 
> `Atomic::inc`? Also - this will only be called on a safepoint at the end of full gc? Does it need atomic access?

Thanks for looking at this.  This is only written from within full gc.  Maybe declaring the variable volatile is sufficient to assure that the "many" mutator threads that access the variable will see any change written by full-gc control thread.  I followed the Atomic pattern out of an abundance of caution.

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

PR Review Comment: https://git.openjdk.org/shenandoah/pull/248#discussion_r1205783818
PR Review Comment: https://git.openjdk.org/shenandoah/pull/248#discussion_r1205783367


More information about the shenandoah-dev mailing list