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

[Roman Kennke]

Am 04.05.2017 um 19:41 schrieb Aleksey Shipilev:
> 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.

ok. Like this?

http://cr.openjdk.java.net/~rkennke/adaptive-minfree/webrev.01/
<http://cr.openjdk.java.net/%7Erkennke/adaptive-minfree/webrev.01/>

Roman