Releasing unused memory

[Aleksey Shipilev]

On 10/18/2018 12:19 PM, Per Liden wrote:
> Yes, this has the problem that is puts the GC in a mode where it strives to reach a back-to-back GC
> steady state, which probably isn't desirable. So deciding what a reasonable GC frequency is will be
> hard without user input. And one could argue that this user input _is_ Xmx, so don't bother doing
> some conservative heap growth thing.

Yup, that's what Shenandoah is doing: tell the active footprint it can have with -Xmx, and
optionally tune down ShenandoahUncommitDelay and ShenandoahGuaranteedGCInterval (or use "compact"
that does prepackaged settings for you) to tell how aggressively it should progress towards minimal
idle footprint. This seems much saner and straightforward; doing it more intelligently always ended
up in desperation when another workload goes belly-up with back-to-back GCs, while there is plenty
of memory. We can handwave a bit that it does not hurt as much with _concurrent_ back-to-back GCs,
but...

Over time, I convinced myself there is no way out, and I wish others learned from this too :)

-Aleksey