Uncommit delay option

[Aleksey Shipilev]

On 10/14/19 12:59 PM, Stefan Reich wrote:
> Thanks Aleksey. I'll now be brave and run Shenandoah on my desktop, without the per-minute gc()
> calls which I had in place before for G1 to keep the process compact. Shenandoah should compact on
> its own, right?

Shenandoah can schedule the GC cycles on its own, that's what ShenandoahGuaranteedGCInterval is for:
it has the default of 5 minutes, and "compact" tunes it down to 30 seconds.

> Would you say the "compact" setting is able to cause any noticeable performance degradation in general?

In general, you can't have your cake and eat it too.

Wiki page I referenced says: "compact ... ***This heuristics would normally incur throughput
overheads***, but shall provide the most prompt space reclamation."

My JVM AQ post says: "...we can clearly see "Shenandoah (compact)" taking quite a some additional
time to work. That is the price we have to pay to have the denser footprint. Or, in other words,
this is the manifestation of throughput-latency-footprint tradeoff."

And you would not be able to say by how much it hurts you until you try. The only ways to hide some
of that degradation is having very short GCs (which implies the workload is purely young-gc), or
having spare CPUs to offload the excess GC work to.

-- 
Thanks,
-Aleksey