Strange behaviour on half-occupied heap

[Aleksey Shipilev]

On 08/29/2018 05:36 PM, Simon Ogorodnik wrote:
> Even with -XX:ShenandoahMaxCSetFactor=60 same situation reproduces. 
> 
> I recorded visualiser:
> https://drive.google.com/file/d/1uhJiGE3kCCDZNbOds6G853u7AmSlPbs0/view?usp=sharing

Aha. Heuristics have run is into the corner: there is no space to evacuate to with concurrent GC,
and all we are left to do is Full GC. I think I know what to do -- we have the "evacuation reserve"
patch that we need to get in, so heap always have some reserved space to evacuate to.

Give it more heap to work around meanwhile.

> Also, I noted that intense collections continues even after Full GC without reason to, and stops a bit later
> Looks like another heuristics problem
> Trigger: Average GC time (367.04 ms) is above the time for allocation rate (54.06 MB/s) to deplete free headroom (0M)
> Trigger: Average GC time (356.68 ms) is above the time for allocation rate (43.52 MB/s) to deplete free headroom (0M)
> Trigger: Average GC time (339.38 ms) is above the time for allocation rate (54.77 MB/s) to deplete free headroom (0M)
> Trigger: Average GC time (320.57 ms) is above the time for allocation rate (47.51 MB/s) to deplete free headroom (0M)
> Trigger: Average GC time (320.43 ms) is above the time for allocation rate (38.27 MB/s) to deplete free headroom (0M)
> 
> Full logs: 
> https://drive.google.com/file/d/1vfrj-Lk7_GEU3XlKQG7iSereyBqGfQ5s/view?usp=sharing

This is to be expected, because heuristics accrued penalty after Full GC. See the log:

Trigger: Average GC time (367.04 ms) is above the time for allocation rate (54.06 MB/s) to deplete
free headroom (0M)
Free headroom: 1555M (free) - 933M (cset) - 102M (spike) - 839M (penalties) = 0M

Penalties go down after each successful GC cycle.

Thanks,
-Aleksey