4 ms·

Go's garbage collector is concurrent, too. GC assist makes sure the GC can keep up with allocations.

• gf000 2y ago
  Correct me if I'm wrong, but concurrent GC only means that certain phases of GC can be done in parallel. GC pauses are a necessity exactly for the part that can't be done in parallel, and Go is definitely not using ZGC's next-generation design that would decouple the pause's length from the heap size, so we still have our "arbitrary long pause" problem on the table.
  • kgeist 2y ago
    From Go's docs: >The Go GC avoids making the length of any global application pauses proportional to the size of the heap, and that the core tracing algorithm is performed while the application is actively executing. >Brief stop-the-world pauses when the GC transitions between the mark and sweep phases. I didn't benchmark it myself, though. Go is mostly used in stateless microservices where huge heap sizes are very uncommon. We usually scale horizontally, not vertically. Also, Go has value objects which can be allocated on the stack or embedded inside other objects, so it allocates far less garbage than Java. So practically for me Go's GC has been a non-issue, I barely remember it even exists.
  • yvdriess 2y ago
    Go GC's stop the world pauses are essentially synchronization barriers at the start and end of a GC phase. That pause length is a function of the number of worker threads, not the size of the heap. You can check this yourself by running the tile38 and cockroachdb benchmarks with GODEBUG=gctrace=1 .
    • gf000 2y ago
      It's the function of both, as per even the sibling comment. Obviously there is not much to synchronize when there is only a single thread.