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