3 ms·

That’s theory, though — has any implementation ever achieved that?

wbl 4y ago
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.
- pkolaczk 4y ago
  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).
kaba0 4y ago
Why do you think that Java, JS and other high performance managed languages all use tracing GCs? They hover around 2x native performance with that. Out of major languages that try to be somewhat highish performance, only swift does ref counting, but that was more of a tradeoff for its lower memory usage which is important on mobile devices.

wbl 4y ago

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.

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

kaba0 4y ago

Why do you think that Java, JS and other high performance managed languages all use tracing GCs? They hover around 2x native performance with that. Out of major languages that try to be somewhat highish performance, only swift does ref counting, but that was more of a tradeoff for its lower memory usage which is important on mobile devices.