Long pause time of Final Mark in latest 11u shenandoah

[Aleksey Shipilev]

On 8/31/20 6:31 AM, Liang Mao wrote:
> Thanks very much for your quick reply! I tried the flush interval but it
> didn't work. And then I looked into the code and reduced the number of
> ShenandoahSATBBufferSize which resolved the problem. But now I don't have
> the testing environment and cannot do more verificatoins. Will let you
>   know once I have a double check.

Ah. Here is the thing: current FlushInterval only works when application comes with a full SATB 
buffer to the filtering code, which can then decide to flush if the period had expired. If mutator 
thread has something in the buffer, but _not_ anything else -- that would make the thread sit on the 
hidden elements until Final Mark. If you reduce ShenandoahSATBBufferSize, that probably makes those 
low-occupancy buffers submitted to filtering code, where flush deals with them.

> BTW, do you have any experience of performance impact if we reduce the
>   default value of ShenandoahSATBBufferSize? I guess is it possible that
> the "snapshots" in Shenandoah would be more than G1 because G1 satb
> only handles old objects?

SATB handles all reference stores, and it records "previous" values in the fields. So it is largely 
irrelevant if there are "old" or "young" objects. I'd expect the same kind of throughput loss as you 
would do with G1.

Really, the proper way to solve this is to "handshake" the mutator threads before finalizing the 
concurrent mark, and by doing so force them to flush however small SATB buffers they sit on.

-- 
Thanks,
-Aleksey