Hacker News Reader

Comment by wbl | Hacker News Reader

The basic semispace collector does. The big issue with GC is the space required and tail latency but often people forger the latency of malloc.

View on HN

The latency of malloc is nothing compared to latency of even the best low-pause tracing GCs. Several orders of magnitude difference. Malloc/free typically run in tens of nanoseconds. Low pause GCs tend to pause for milliseconds (and this is already considered a success).

Also the nature of pauses is different. A GC pauses everything. A malloc/free call only blocks the thread that called them. Threads that never allocate anything are never disturbed.

Only compacting GCs need to pause application. It is possible to implement GC without pauses.

Yes, it is, but not without a cost. High throughput, no pauses, low memory overhead - pick two. However, stack-based allocation + statically inferred memory management + a tiny addition of reference counting only where needed (like in C++ or Rust) can easily get you all of those features in one program.

I think the Go GC guarantees pauses bounded below 100 microseconds, regardless of the heap size. Of course, that means incremental GC.

Go’s GC is not state of the art, Java’s ZGC is.

Perhaps Go's GC is not state of the art, or perhaps it is, but I don't think that's a very helpful statement without being more specific.

Here is a what I found:

"The ZGC design strives to deliver a max pause time of a few milliseconds with marginal throughput loss." [1]

"We now have an objective of 500 microseconds stop the world pause per GC cycle." [2]

Of course, those GCs have different tradeoffs in terms of max pause time, app throughput, memory fragmention/usage, etc.

[1] Deep Dive into ZGC: A Modern Garbage Collector in OpenJDK , September 2022, https://dl.acm.org/doi/fullHtml/10.1145/3538532

[2] Getting to Go: The Journey of Go's Garbage Collector, July 2018, https://go.dev/blog/ismmkeynote

How many mallocs are run for a single GC pause though? You are comparing apples to oranges. GC runs on an almost human timescale, I wouldn’t be surprised if an “ordinary” app would have 1000x of mallocs for a full GC run.

Of course if you allocate arenas and reuse that cleverly you can beat any GC, but that’s far from obvious nowadays (e.g. I remember a reddit thread where naive Java beat naive Rust in some parsing to AST program (can’t find it currently). The reason was the speed of object allocation).

Reply on news.ycombinator.com