>> Not to mention, it has no idea how your program uses memory, such that it is bound to use a generic approach

> Ditto for malloc.

malloc != manual management

> Using a GC does not mean you can't manually manage allocations. E.g. say you are allocating and deallocating a lot of Point objects...

But that's not using a GC. It's manual memory management.

That's aggressively missing the point. If you design the program architecture around manual memory techniques, the runtimes are stable even in a GC. If you use malloc willy-nilly throughout core algorithms, your runtimes become unpredictable.

But my point was simply that you can't defend GC by contrasting to manual management, if you do manual management.

> If you use malloc willy-nilly throughout core algorithms, your runtimes become unpredictable.

First, where did I say "use malloc willy-nilly"? Second, do you have experience with that? I haven't much, but I haven't heard your claim before.

Of course "willy-nilly" should not be done with real-time constraints. But I have written a substantial algorithmic program (no RT constraints) in that style when I didn't know better, and it was very well performing. (probably glibc's malloc was optimized for my allocation patterns).

The main problem I see with that style is that each malloc has memory overhead, and that it leads to unmaintainable code.

Actually, to address realtime constraints... In my job, I work on systems with realtime constraints and even in less critical parts (latency of ~100 microseconds is still acceptable) we had to eliminate all malloc calls. Mostly because malloc on our platform essentially acquires one big lock for memory operations and if some other process has that lock, you get nasty delays or even priority inversions. Allocate a big chunk beforehand, preferrably in the form of ring buffers, and then operate on these if you need precise timing and performance.

... or use a version of malloc on that preallocated thread-local chunk. At least if the only problem is locking overhead.