Rare very big pause

[Kirill A. Korinsky]

Thanks!

Good point.

May you suggest any way to understand where and how much it try to allocate?

Because this application shouldn't allocate so big memory and how I can see it from line before it had 245Mb free memory when GC cycle happened.
> Concurrent marking triggered. Free: 245M, Free Threshold: 245M; Allocated: 245M, Alloc Threshold: 0M




--
wbr, Kirill


> On 19 Dec 2017, at 19:05, Aleksey Shipilev <shade at redhat.com> wrote:
> 
> 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
>