Since when does the garbage collector running actually increase the memory used??!!!

Not so # C#

It doesn't.
Get a heap dump, and analyse it.

JVM? since always. MinorGC causes some objects to be moved to the OldGen. If these objects do not fit in the OldGen, the GC has 2 options:

1. trigger FGC (but we want them triggered as rarely as possible because of those nasty STWs)

2. try and grow the Heap size if Xmx still allows it (and OG is not reaching the max limit yet).

Whenever possible, GC prefers #2. It commits more RAM from the OS and grows the OG.

I'm writing a blog series about JVM GC. You may find some explanations there: https://dev.to/netikras/...

if might, temporarily, while the GC is doing its stuff.

but the thing on the screenshot is not that. debugging is needed, someone fucked something up in a very amusing way.

GCs usually need to build a graph of object ownership to identify cyclical ownership and free those correctly (cyclical ownership is not advised), so it will probably increase a bit for a short period of time. But that looks dodgy.

That's actually something called a garbage creator. Oracle has a patent on it

Been there... We have queried the db too often for all records by mistake, basically used oracle query for postgres whatever. Noticed if from incoming traffic and the garbage collector was failing to do the job :D

@netikras I cannot red the full articles sadly as my brain is currently a nuclear wasteland with some haystacks rolling round...

But I glanced over it.

ZGC - default in JDK 11? That's news to me.

Afaik it's G1 GC and the implementation of G1 is different from the previous 8/9/10 releases.

ZGC is still experimental afaik and being worked on.

The "major" GC implementations all change a little bit from version to version...

I'll try to put the full article on my bookmark list and hope to remind myself in 2 weeks about it...

Back to the topic just a lil hint:

Anything that has to do with garbage collection or "memory page fiddling" has to do it...

... In some way or another.

Imagine laying on a carpet aka the memory page.

You wouldn't be happy if someone comes in and just randomly rolls you over with a vacuum cleaner...

Same for memory. You don't want to risk the process reading / writing to a memory segment that is getting "transformed". Transformed meaning shrinked -/ grown -/ freed -/ ... .

Doing so would lead to all kind of unpleasant surprises.

@IntrusionCM Thanks, fixed that. I have no idea how I made that mistake...

@netikras oh I knew absolutely how you can make that...

Brain goes bupoity boppity bleep... Brain says: Ah fuck it. Here's a random choice of possible answers, who gives a fuck wether it's right or wrong.

when it doesn't release everything + the pointers excepting when extra ram is demanded and the cpu use is lower :P

i've seen this before.

if this is dotnet call GC.Collect()

As my old mentor would say

"Its a feature !"

dotnet is trying not to bog down your process :P by leaving the ram full. so other processes get bogged down :P lmao

@netikras As a Rust developer I never understand why Java devs say "All these Rust memory rules are hard, GC makes things a lot easier" and then they pull out ancient tomes with dark magic and arcane knowledge on how extremely mystical garbage collectors are.

@bittersweet see, that's the whole point. One has to know all the black, white, gray, yellow, blue, transparent and all other kinds of magic. But that person does not have to be the dev who writes code. It could be an ops, a mw guy, a perf guy, or someone else with the right knowledge. And dev now only has to focus on writing code and baking features. Not worrying about how to properly manage memory. The gc will do it for him. And the mage will tune the gc for him.

jvm gc is decoupling mem mgmt from development. Just like networking and server management already is.

@netikras

Except not a single company hires that optimization shaman.

Brb, installing 64GB of RAM to decrease lagspikes in Minecraft 😂

@bittersweet I've been getting paid for pretending to be that shaman for years now :) And to be fair, there's a good share of our clients that desperately want such shamans.

In my prev workplace (corp) there was a whole team of shamans focusing on JVM tuning of all the internal and external apps.

Sooo... sorry, but I have to disagree with you there.

FTR: too much ram can make your app/game laggier. It will start freezing for longer pauses eventually. Better look at what the GC is doing :)

@bittersweet

"and then they pull out ancient tomes with dark magic and arcane knowledge on how extremely mystical garbage collectors are."

that's shit java devs then. because GC are arcane and mystical, kinda, yeah. but they CAN be, because unless you're doing something very weird or very wrong you don't have to know anything about them.

so as soon as the tome-pulling begins, you can be sure whoever needs to be pulling the tome has done something very weird or very wrong.

@bittersweet The need for the shaman is also vastly diminishing. It's become a nice to have more than a necessity in almost all cases.

20 years ago it was a necessity. The GC algorithms were genuinely hard to bash into shape, and if you didn't your app would often have intolerable lag, eat through RAM, or more often both.

These days the defaults are way more sensible, and most people are usually best leaving them alone (other than setting memory size.) They can be tuned for the better of course, but most well meaning devs now tend to make things worse rather than better in my experience.

Let's be honest here.

GC handling is hard.

If we had the chance to migrate to better JDK versions instead of waiting for a long long time for JDK 17 (oracles decisions regarding EOL regarding JDK 8 vs 11 were bad. Really bad) it would be a problem solved.

Reason e.g. why Elasticsearch used the short term versions of JDK and bundled them.

GC has improved _a lot_.

Overall, a lot of small and large changes in JDK accumulated and make JDK 11 / JDK 17 a lot better than JDK 8.

JDK 8s GCs were awful.

Simply for the reason that they predate what is currently available in hardware.

This is it. JDK 8s GC date far far far far far back in time.

If someone wants to get bonus points and some star stickers, find out when JDK 8 came out and when the GCs were designed.

You'll be surprised.