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.scha...@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@openjdk.java.net > https://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use > -- Stefan Reich BotCompany.de // Java-based operating systems
_______________________________________________ hotspot-gc-use mailing list hotspot-gc-use@openjdk.java.net https://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use
