You can predict the time that malloc(3) and free(3) take to run? You know they are backed by very complex data structures that need to manipulated and iterated over?

The point you mention is only valid when using entirely static memory, which is a very rare case in real C code (only really used in a few small embedded codebases).

>You can predict the time that malloc(3) and free(3) take to run?

The correct answer would be: depends on the concrete implementation. There are implementations with real-time guarantees.

However, assuming standard desktop OS malloc()/free() the answer is: No. These functions can execute very quickly.. or very slowly, depending on their current internal state. But you can control when they get called, which can be an important difference.

>The point you mention is only valid when using entirely static memory, which is a very rare case in real C code (only really used in a few small embedded codebases).

Depends on what you mean by "entirely static memory". No malloc() calls at all? Yes, that is rare and pretty much limited to the embedded realm I think. Memory pools however are very common in performance critical code.

You speak sense. I tend to use apr pools all the time in critical sections.

> You can predict the time that malloc(3) and free(3) take to run?

Thanks for pointing this out.

This is often a misunderstanding from manual memory management fans. In many cases malloc()/free() also behave non-deterministic.

This is the main reason why for special types of applications, you need to have malloc()/free() implementations specially targeted to the use case at hand.

This is no different from the GC runtimes, which are coded specifically for real time applications, like avionics, for example.

It's very different in one significant regard: it's very easy to write your own acceptably performant and deterministic malloc and free, compared to the effort it takes to write a GC that would fit in to those constraints.

malloc and free are much cheaper than a mark-and-sweep. It is a much easier task to write a bounded-latency malloc suitable for real-time applications - for example, dlmalloc has a NO_SEGMENT_TRAVERSAL flag that assures bounded execution. By contrast, making GC with bounded latency is hard.

Why are you comparing an API (malloc/free) to an implementation (mark and sweep)?

Anyway, take a look at the OCaml GC. It's simple (probably simpler than glibc's malloc) and very performant particularly if you understand how it works and use it intelligently in your app.

Not that complex really, if we are talking about buddy allocator or jemalloc. They both have predictable and limited running time.

Default platform malloc(3) and free(3) can be a crap indeed, but they are drop-in replaceable with the above at any time, unlike Go GC - if practical testing suggests such replacement is necessary (e.g. Firefox, Facebook servers)

> The point you mention is only valid when using entirely static memory

Exactly, and you can also do that in Go to avoid the GC.

Not sure exactly what you mean by "entirely static", but in the signal processing application I worked on we used an allocate once/deallocate once design where we allocated gigabytes of RAM per node up-front and reused the buffers and data structures during operation. We took over the entire node, essentially, and we were a closed system, so this design didn't cause most of the problems this normally would.