From the list of features it is very similar / identical to JavaScript GC in V8 / Chrome, which honestly expected: browsers have been trying to one-up each other on benchmarks throughout all 2010s.
Go GC is incremental, concurrent, parallel, but it's not generational and not compacting. However, the way Go uses the memory internally is different from JavaScript, Java, C#, etc. Go data structures rely on pointers a lot less, and thus the process of inspecting the heap during garbage collection takes a lot less time, too. Many short-lived objects in Go remain on stack only, and do not need to be garbage-collected. So, their GC doesn't need to be as sophisticated as the ones in JVM, for example.
Stack allocation in GC managed languages is also available across C#, F#, Common Lisp, D, Nim, Mesa, Oberon, Oberon-2, Active Oberon, Oberon-07, Component Pascal, Swift (RC is a GC algorithm), Eiffel, and many others that usually are forgotten when discussing GC algorithms.
Also all modern Java implementations do escape analysis just like Go, instead of go build -gcflags='-m=3' one gets to use JITWatch or similar tooling, depending on the specific JVM implementation.
Given it still isn't as good as having explicit structs, hence the ongoing Valhala Project, that just got a second EA last week.
Finally, all this Go doesn't need to be like XYZ, usually ends up proven wrong a few years later.
Recently by adopting the keep alive and cleaner concepts from .NET and Java respectively, and a new GC implementation is in the works (Green Tea).
How does it compare to concurrent GCs like the one in Go?
https://go.dev/doc/gc-guide
From the list of features it is very similar / identical to JavaScript GC in V8 / Chrome, which honestly expected: browsers have been trying to one-up each other on benchmarks throughout all 2010s.
Go GC is incremental, concurrent, parallel, but it's not generational and not compacting. However, the way Go uses the memory internally is different from JavaScript, Java, C#, etc. Go data structures rely on pointers a lot less, and thus the process of inspecting the heap during garbage collection takes a lot less time, too. Many short-lived objects in Go remain on stack only, and do not need to be garbage-collected. So, their GC doesn't need to be as sophisticated as the ones in JVM, for example.
Stack allocation in GC managed languages is also available across C#, F#, Common Lisp, D, Nim, Mesa, Oberon, Oberon-2, Active Oberon, Oberon-07, Component Pascal, Swift (RC is a GC algorithm), Eiffel, and many others that usually are forgotten when discussing GC algorithms.
Also all modern Java implementations do escape analysis just like Go, instead of go build -gcflags='-m=3' one gets to use JITWatch or similar tooling, depending on the specific JVM implementation.
Given it still isn't as good as having explicit structs, hence the ongoing Valhala Project, that just got a second EA last week.
Finally, all this Go doesn't need to be like XYZ, usually ends up proven wrong a few years later.
Recently by adopting the keep alive and cleaner concepts from .NET and Java respectively, and a new GC implementation is in the works (Green Tea).
Sounds very impressive. That "precise" feature is new to me.
Most garbage collectors are precise, if possible.