RFR: Use peak occupancy to optimize/pessimize free_threshold in adaptive heuristics

Aleksey Shipilev shade at redhat.com
Thu May 4 17:41:47 UTC 2017


On 05/04/2017 07:38 PM, Roman Kennke wrote:
> Am 04.05.2017 um 19:31 schrieb Aleksey Shipilev:
>> On 05/04/2017 07:17 PM, Roman Kennke wrote:
>>> That means, observe the peak occupancy (right before
>>> reclamation) and pessimize if peak occupancy is less than a threshold.
>>> Here I'm re-using ShenandoahMinFreeThreshold for this. This should
>>> balance our GC cycles around that threshold and leave some room for
>>> alloc spikes, thus leading to fewer degen cycles or full-gcs.
>>>
>>> http://cr.openjdk.java.net/~rkennke/adaptive-minfree/webrev.00/
>> Good stuff, I have zero degens on Compiler.compiler now.
>>
>> I think the capturing is slightly wrong though: it records occupancy at final
>> mark and before update-refs, overwriting the value. Which means if update-refs
>> managed to clean up enough (as they do), we may be blind about the case when
>> there is not enough space right after the mark. That would not be visible on
>> workloads where there is enough immediate garbage reclaimed after mark.
>>
>> I think we need to store MAX of observed occupancies, and reset it to zero when
>> we claim it in heuristics.
> Maybe.
> Currently we're simply always looking at the last heap occupancy, right
> before reclamation, and right before we would query it. Notice that we
> do adjust the free-threshold both after marking and after UR.
> 
> E.g.:
> final-mark:
> record-peak-occupancy
> reclaim-regions
> check for optimize/pessimize
> 
> final-update-refs:
> record-peak-occupancy
> reclaim-regions
> check for optimize/pessimize
> 
> Is that not ok? For the start? ;-)

Um, I see this guarded with !update_refs_early():

 528   virtual void record_cm_success() {
 529     ShenandoahHeuristics::record_cm_success();
 530     if (! update_refs_early()) {
 531       handle_gc_success(_successful_cm_cycles_in_a_row);
 532     }
 533   }

Which seems to tell different story: with UR enabled, we do not adjust after CM.
And actually, I think it is correct to compute the max over all phases in the
cycle to decide heuristics move. We only need to max, not destructively overwrite.

-Aleksey



More information about the shenandoah-dev mailing list