3 ms·

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 i

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.

pebal 4y ago
Only compacting GCs need to pause application. It is possible to implement GC without pauses.
- pkolaczk 4y ago
  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.
ngrilly 4y ago
I think the Go GC guarantees pauses bounded below 100 microseconds, regardless of the heap size. Of course, that means incremental GC.
- kaba0 4y ago
  Go’s GC is not state of the art, Java’s ZGC is.
  - ngrilly 4y ago
    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 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 https://go.dev/blog/ismmkeynote
kaba0 4y ago
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).

pebal 4y ago

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

pkolaczk 4y ago
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.

ngrilly 4y ago

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

kaba0 4y ago
Go’s GC is not state of the art, Java’s ZGC is.
- ngrilly 4y ago
  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 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 https://go.dev/blog/ismmkeynote

kaba0 4y ago

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).