Rare very big pause

[Aleksey Shipilev]

On 12/19/2017 03:57 PM, Kirill A. Korinsky wrote:
> 2017-12-19T12:11:03.960+0000: 12221.481: [Pause Init Mark, 5.081 ms]
> 2017-12-19T12:11:03.965+0000: 12221.485: [Concurrent markingCancelling concurrent GC: Allocation Failure
>  5887M->6130M(6144M), 653.310 ms]
> Adjusting free threshold to: 14% (860M)
> 2017-12-19T12:11:04.620+0000: 12222.139: [Pause Final MarkTotal Garbage: 4889M
> Immediate Garbage: 2018M, 1009 regions (44% of total)
> Garbage to be collected: 2435M (49% of total), 1264 regions
> Live objects to be evacuated: 87M
> Live/garbage ratio in collected regions: 3%
>  6130M->4114M(6144M), 446.259 ms]

This is degenerated mark: collector ran out of memory during concurrent mark (or, in other words,
application had allocated too much), and Shenandoah dived into Final Mark right away, where it
completed the marking phase.

Heuristics is supposed to find the optimal spot when to start the cycle to avoid this, but transient
hiccups like this might still happen early in the application lifecycle. Or, you might want to tell
heuristics how much free space to maintain to absorb allocations, see our Wiki about that.

Thanks,
-Aleksey