RFR: Remove CSetThreshold handling from heuristics

Roman Kennke rkennke at redhat.com
Thu Apr 5 14:56:28 UTC 2018


Am 05.04.2018 um 16:25 schrieb Aleksey Shipilev:
> On 04/05/2018 03:57 PM, Roman Kennke wrote:
>> Am 05.04.2018 um 15:50 schrieb Aleksey Shipilev:
>>> Ping?
>>>
>>> On 04/04/2018 07:57 PM, Aleksey Shipilev wrote:
>>>> http://cr.openjdk.java.net/~shade/shenandoah/purge-cset-threshold/webrev.01
>>>>
>>>> We did this thing before separate UR phase was introduced. The role for this threshold was to avoid
>>>> double-cycle when heuristics thinks the free space hoarded in cset is not available. However, it is
>>>> not fully reliable: the fact that we "appear" to have more free space than we actually have risks to
>>>> run into alloc-failure during late mark. Also, since separate UR phase is enabled, we don't even
>>>> care about double-cycle issue anymore: CM-with-UR cycles _are_ back-to-back.
>>>>
>>>> Removing this simplifies the code.
>>>>
>>>> Testing: hotspot_gc_shenandoah, SPECjbb (where the original double-cycle was observed)
>>>>
>>>> Thanks,
>>>> -Aleksey
>>>>
>>>
>>
>> Have you checked that the double-cycle issue does not occur? E.g. in
>> visualizer?
> 
> Yes, I did ran SPECjbb under Visualizer, and saw no double-cycles. Well, all cycles were
> CM-without-UR, and CM-with-UR happened only on small heaps where cycles are back-to-back anyway.
> 

Right. This is bogus code then.

Patch is good, go!

Roman



More information about the shenandoah-dev mailing list