Deep Dive into ZGC: A Modern Garbage Collector in OpenJDK (2022) [pdf] | Hacker News Reader

Deep Dive into ZGC: A Modern Garbage Collector in OpenJDK (2022) [pdf]

dl.acm.org

36 pointsmfiguiere11 comments

One thing I still dont get is how can ZGC be safe if it literally reserves all native memory available on the machine.

This or why NMT shows stupid numbers when using ZGC.

TBH the more I dived into JVM memory management the more disgusting it became.

You cant be sure of anything, its totally not straightforward, has many pitfalls and requires stupid amount of useless JVM only knowledge to work well.

Im starting to think that in containers age, an intermediate bytecode language is not needed anymore.

May be the reason why CPython or Go see such huge adoption in contenerised world.

That's most likely reserved virtual memory. It's not committed, meaning it's not backed by physical memory.

From what I could check those are all memory mapped files.

Required simply by ZGC to work, but still its super confusing and convoluted and our tooling is not aware of that at all.

Well yes, because on Linux you use mmap to reserve virtual memory.

I wouldn't say that tooling is not aware of all that. For example, top and htop display virtual memory and resident memory and shared memory. You need to look at resident memory if you want to know physical memory usage.

What I meant by tooling not being aware is that its hard to pinpoint what exactly is using that memory.

Best you can do is do dumps, verify, enable NMT, verify.

It gives me no value to know that my heap is 60m, but my RSS is 600mb while reserved is 40GB. Need more details and those are not always provided i.e. “Unknown” category in NMT details.

Best is that top, pmap and nmt are all showing completely different values for resident size :> and its not a unit issue.

Not dumped to the OS of course, but JMX does have metrics for a lot of the in use non heap storage like codegen, profiler, etc..

Go's GC uses the same trick, and also shows a giant virtual size.

But you're right more broadly, it's nice to not have bad performance be a bunch of finger pointing between dev and ops with Go. With Java there's always another, untried GC twiddle to fix everything.

> With Java there's always another, untried GC twiddle to fix everything

That hasn’t been true since.. forever. If you have GC problems with Java, you are doing something stupid in 99% of the cases that can be easily fixed by any kind of profiler. That’s not true for most other GCd languages.

For me main reason to prefer Go is its fantastic start time and low memory consumption.

Last time I tried to build a lean Java project, I end up with 300MB heap. With small Go service, it can easily live on 30MB container.

It's true, per default the jvm takes a bunch of memory. I have been successful with running complex java apps in very memory constrained environments though, choosing frameworks and the right -xmx value is usually enough, but yeah, the 30mb res region is not javas sweetspot, but 100mb res mem allowes leveraging much of the java ecosystem.

How does it have to do anything with safety?

And you can just ignore anything GC specific almost all the time..

Reply on news.ycombinator.com