"Could be better" is of course true for every single situation, no matter how good.
But even Java, which has what is generally regarded as the most advanced GC ever written, still has lots of applications doing the free-list of ByteBuffers or even better, the free-list of off-heap-allocated DirectByteBuffers which don't have to be moved during tenured generation compactions.
It seems pretty reasonable to me to have one or two freelists at the spots you're frequently allocating 64kb buffers, along with using the GC for the other 5,000 allocations in your project.
Let me put it another way: Go's GC is still in its infancy compared to those in most other languages. It's perfectly fine to use, but there are some big things (e.g. no compaction) that stick out when using the language, whether you're working with free-lists or something else.
I think you're going to find that even with no attention to allocation at all, your Golang programs are going to outperform their Ruby and Python equivalents.
That's a dicier assertion to make versus other languages, notably Java, but if you're coming to Golang from a high level language like Python, you're probably going to be happy with the performance you get out of naive code.
You're right (except for some cases like crypto and regex where other languages "cheat" by using C bindings or unstable versions), but that isn't where it has bit me. In general all my Go programs have been more than fast enough, but on several occasions I've had memory starvation problems that I would not be having in other languages (even if there is a way to do it without doing a lot of allocation and fragmentation in Go.)
I love Go, but "it's fast" isn't a good reason not to improve a subpar GC. (Which fortunately isn't a position the Go team is taking. I know everyone there would like to see a lot of interesting things happen with the GC. It just hasn't been one of the more pressing issues so far, and I've agreed. It's also a very difficult and "boring" thing to work on for most people, so it's not surprising that somebody hasn't just added an Azul C4-style concurrent GC in their spare time.)
Azul C4 requires a kernel module or a specialized kernel to support all the MMU tricks that it relies on to achieve maximum performance. I don't think it's really an appropriate choice for general purpose GC in a language that's designed to be easy to deploy.
Java HotSpot's collector makes the most sense IMHO: stop the world compacting in the young generation, mostly concurrent in the tenured generation. It achieves better throughput than Azul C4 too, according to the C4 paper.
I vaguely remember reading somewhere that they figured out a way to run their collector on stock Linux; I think the price they paid in exchange was (even) lower throughput (trying to track down reference so I know I wasn't daydreaming) (yes, I daydream about GCs).
A while ago, I read through the kernel patch they provided, and it was basically adding batch APIs for mremap so you don't have to have a TLB flush for every call. Also because all mutator threads needed to be paused at a safepoint while the remaps happen, so the batch API has much shorter pause time.
> In general all my Go programs have been more than fast enough, but on several occasions I've had memory starvation problems that I would not be having in other languages
The problem with GC's languages, is that GC is "good enough" for prototyping and for undemanding stuff, but there are still these corner cases. Really, it's no different than other forms of memory management in this regard. It's just particularly beginner friendly.
Yes, Golang is very young and its gc is one of the more 'immature' portions. However, in comparison to the tools that it is regularly displacing the overall speed is still a huge win. Eventually, Golang will get a better gc and in the meantime we can already enjoy faster programs. Nobody is arguing that the gc of today should be Golang's gc forever.
People pick Ruby and Python without having unrealistic expectations for performance and throughput. We already know their implementations suck and being the high-level languages that they are, we know how difficult they are to optimize.
However, if performance is a concern, then picking Go seems to me like quite a step back from say Ruby.
There are other alternatives as well, that are higher level and that are much better at performance than Ruby/Python. E.g. Java, C#, Scala, Clojure, Ocaml, Haskell.
Personally I love Scala and the JVM, but the one thing I don't like is the GC. The JVM has the best GCs ever, but sometimes you just want to do without one at all.
This is why I don't like Go. While it's a tasteful language, it's too low level, but it still depends on a GC (that's not precise, compacting or generational).
I agree, given the type of issues they are addressing (very high throughput application servers), I don't think a general purpose allocator (garbage collected or not) will ever get the performance they want. Recycling buffers is not a bad strategy for this type of application, no matter the language.
But even Java, which has what is generally regarded as the most advanced GC ever written, still has lots of applications doing the free-list of ByteBuffers or even better, the free-list of off-heap-allocated DirectByteBuffers which don't have to be moved during tenured generation compactions.
It seems pretty reasonable to me to have one or two freelists at the spots you're frequently allocating 64kb buffers, along with using the GC for the other 5,000 allocations in your project.