RFR: Implement heuristics to switch between merged and separate update-refs phase

Aleksey Shipilev shade at redhat.com
Mon May 8 20:24:48 UTC 2017


On 05/08/2017 10:23 PM, Roman Kennke wrote:
> Am 08.05.2017 um 21:57 schrieb Aleksey Shipilev:
>> On 05/08/2017 09:52 PM, Roman Kennke wrote:
>>> Am 08.05.2017 um 18:23 schrieb Aleksey Shipilev:
>>>> On 05/08/2017 05:12 PM, Roman Kennke wrote:
>>>>> This also means that, at least when running with adaptive heuristics
>>>>> (the default), the argument -XX:+/-ShenandoahUpdateRefsEarly is unused.
>>>> Um. I wonder if there is an option to turn off UR unconditionally. Should we
>>>> rewire that flag have three values: always-on, always-off, adaptive?
>>> Like this ?
>>>
>>> http://cr.openjdk.java.net/~rkennke/merge-uprefs/webrev.02/
>> *) Um. AdaptiveHeuristics() would still execute ShenandoahHeuristics(), right?
>> Which will then print the warning message?
>>
>>  227   } else if (strcmp(ShenandoahUpdateRefsEarly, "adaptive") == 0) {
>>  228     log_warning(gc)("-XX:ShenandoahUpdateRefsEarly=adaptive only useful
>> with -XX:ShenandoahGCHeuristics=adaptive. Defaulting to 'true' instead.");
>>  229     _update_refs_early = true;
> Duh.
> 
> Ok, I moved it all into ShenandoahHeuristics constructor now. Life's too
> short.
> 
>> *) Leftover:
>>
>>  588     tty->print_cr("last cycle gap: %f ms", last_cycle_gap);
>>
>> Otherwise seems fine.
> Removed.
> 
> http://cr.openjdk.java.net/~rkennke/merge-uprefs/webrev.03/
> <http://cr.openjdk.java.net/%7Erkennke/merge-uprefs/webrev.03/>
> 
> Ok now?

OK.

-Aleksey




More information about the shenandoah-dev mailing list