Full GC without pause?

[Stefan Reich]

Hi Thomas, thanks for your answer.

The "Reasons?"  line was just meant as a heading for the reasons I listed
below it, not as a question... :)

ExplicitGCInvokesConcurrent is interesting, hadn't heard of that before.

> maybe the functionality in
https://bugs.openjdk.java.net/browse/JDK-8204089 provides what you want
for g1.

Yes that may also help me. I am not sure if the system is usually below the
default load threshold. I'll keep investigating.

Switching to ZGC I would rather like to avoid, but I might do that too.

Thank you


On Mon, 28 Jun 2021 at 09:28, Thomas Schatzl <thomas.schatzl at oracle.com>
wrote:

> Hi,
>
> On 27.06.21 10:30, Stefan Reich wrote:
> > Hi,
> >
> > in my <https://bea.gazelle.rocks/>application
> > <https://bea.gazelle.rocks> I have about 800 MB of live objects. I know
> > this because that's the used heap I get after running System.gc().
> >
> > However, in normal operation (without calling System.gc()), heap use
> > hovers around 3 GB out of 6 GB. I'm using G1.
> >
> > So my question is - since the garbage collector is supposed to "race"
> > the application threads anyway - can't it be made to "race to the end"?
> > Meaning, until no or almost no dead objects remain?
> >
> > I am totally fine with this potentially lowering the overall application
> > or GC throughput; it's supposed to happen in irelatively (though not
> > completely!) idle phases.
>
> Please give ZGC a try, it might give you exactly what you want here.
> There are only a few very small STW pauses (<1 ms) per collection cycle
> with it in jdk16/17.
>
> >
> > I really can't afford the seconds-long stop-the world pause of
> > System.gc(). I just wish to put the regular backgruond GC on
> > steroids for a few seconds until its job is done >
> > Reasons?
>
> Not sure exactly which reasons for which of the questions you expect
> here, but one reason for why g1 system.gc() call (without
> -XX:+ExplicitGCInvokesConcurrent) is that it's defined as a fully,
> maximally compacting stw gc pause.
>
> >
> > A. It just feels cleaner to have no more dead objects. (Gotta love the
> > clean feeling!)
>
> Options with G1 are to
>
> - enable -XX:+ExplicitGCInvokesConcurrent to get a concurrent marking
> with subsequent incremental collections since you "are not completely
> idle". This should give you lower pause times at least.
>
> - maybe the functionality in
> https://bugs.openjdk.java.net/browse/JDK-8204089 provides what you want
> for g1.
>
> > B. We find out how much heap we are actually using - no chance of that
> > in normal operation.
>
> MXBeans should give you a fairly good idea about that without an stw
> full gc, particularly after a concurrent marking.
>
> Thanks,
>    Thomas
> _______________________________________________
> hotspot-gc-use mailing list
> hotspot-gc-use at openjdk.java.net
> https://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use
>


-- 
Stefan Reich
BotCompany.de // Java-based operating systems
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/hotspot-gc-use/attachments/20210628/456b988a/attachment.htm>