RFR (XS): Enable UseCountedLoopSafepoints with Shenandoah

[Lennart Börjeson]

I feel I must chip in here…

(I’m continuously testing Shenandoah, as well as other JVM variants, with our products, as part of my work.)

We have recently encountered an issue with a commercial JVM which had elected to skip safepoint checks for all counted loops. This broke our product, since we have a crucial spin wait in a long-indexed loop.

(As you know, the JVM normally inserts safepoint checks in long-indexed, but not in int-indexed, counted loops.)

Such a change in behaviour is extremely hard to track down, and I regard it as a significant functional change.

I urge you, as I’ve urged the vendor in question, to keep the ”standard” behaviour as default.


And BTW, Shenandoah is starting to perform very well in my tests. Our primary metric is transaction roundtrip time, and outlier elimination is important. In my latest tests (of a week ago), Shenandoah had much shorter maximum times than our baseline (which uses Hotspot+ParNew+CMS). You really have made a fantastic work this year!

Best regards,

/Lennart


> 20 dec. 2016 kl. 15:01 skrev Roman Kennke <rkennke at redhat.com>:
> 
> 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