RFR (XS): Enable UseCountedLoopSafepoints with Shenandoah

[Roman Kennke]

Am Dienstag, den 20.12.2016, 13:32 +0000 schrieb Andrew Haley:
> On 20/12/16 10:57, Aleksey Shipilev wrote:
> > Since we care mostly about pause times, and not the raw throughput,
> > it makes
> > sense to enable safepoints in counted loops. This makes us much
> > more responsive
> > (as in, TTSP is lower) in many interesting scenarios.
> 
> True, but I have seen some very interesting cases where we beat G1 in
> throughput.

Yes. As far as I can see, those are not affected by this (e.g. compiler
benchmarks). And multiple seconds (!) just to get to a safepoint seems
way too much, and it's more than 1 program that is affected by this.

>   Let's not overdo this: at the very least we need to know
> how to restore throughput when running Shenandoah;

easy: -XX:-UseCountedLoopSafepoints

Infact, I've been thinking for a while about a sort of 'priority'
setting for Shenandoah, where one could choose between 'throughput' and
'pausetime', and we would turn on or off specific options to improve
one or the other, e.g. this UseCountedLoopSafepoints flag, some
heuristics settings, and so on. Kindof like the -XX:+AggressiveOpts
setting, but towards one or the other priority.

However, so far there are not that many settings in this regard, and
our priority is always leaning towards pause times anyway...

>  all this business
> of one flag affecting others can be surprising.

Indeed. I would be most worried about turning on code paths that are
not used otherwise, and thus run into bugs that are not ours, but in
this case it seems to be simple enough.

Roman