Uncommit delay option

[Stefan Reich]

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?

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

Many greetings,
Stefan

On Mon, 14 Oct 2019 at 09:42, Aleksey Shipilev <shade at redhat.com> wrote:

> On 10/12/19 3:33 PM, Holger Hoffstätte wrote:
> > The option is called ShenandoahUncommitDelay (in milliseconds), e.g.
> > -XX:ShenandoahUncommitDelay=60000 will try to uncommit every minute.
> > Note that this doesn't *guarantee* RSS shrinking on every interval;
> > it might take a concurrent cycle or two for regions to be compact
> > enough.
>
> To add to this, ShenandoahUncommitDelay means the time the empty region
> stays committed. What is
> important here is that regions become empty as GC acts on the heap, which
> means whatever small
> uncommit delay would be useless unless you have GC cycles running as well.
>
> When optimizing for footprint, I would start with "compact" heuristics
> that tunes down everything to
> the densest extreme, and then worked backwards opting out of some of the
> tuning it ergonomically
> applied, checking it does not regress footprint numbers for your scenario.
> GC logs should say at the
> start what adjustments the heuristics made.
>
> Stefan, be sure to read our wiki page:
>   https://wiki.openjdk.java.net/display/Shenandoah
>
> --
> Thanks,
> -Aleksey
>
>

-- 
Stefan Reich
BotCompany.de // Java-based operating systems