You seem to have a very low opinion of other people. If these miraculous collectors are so generally applicable, why are very smart people putting effort into things like Perseus?
Smart, honest people can have sincere and earnest disagreements. I believe the manual-memory-management people are mistaken. That's not to say they're stupid: it means I believe they're going down the wrong path, as smart people have done since time immemorial. I wish them all the best. That said, I must wonder what other innovations they reject if they insist that GC is unacceptable.
And we disagree on how best to gain control of latency. Some say that the way to gain control of memory management latency is to track object-level allocations locally using malloc/free-style APIs, arenas, and so on. IMHO, low tail latency achieved through this approach is fragile and often illusory: object reference graphs are often bigger than you expect, and malloc/free-style heap managers (even with thread caches) need to do global synchronization eventually. Arenas work for some cases, but often break down for complex programs. (Look at libapr!)
No, I think GC is the way to control latency of memory handling. Plenty of work on real-time GC shows that you can construct a GC such that if the mutator allocates less than X MB/second you can achieve reclaim latencies under Y ms. The nice thing about these guarantees is that they're global: it doesn't matter how you allocate. All that matters is how much you allocate. It's a metric you can measure and optimize, IMHO, more easily than you can try to bound heap-manager contention and free-SCC size.
Granted, you can come back and point out that it's hard for me to prove I don't have allocation-rate spikes just like it's hard for you to prove you don't have lumpy free()s and malloc pool contention. But IME, it's a lot easier to bound latency rates, because we have good allocation profilers and in many cases you can prove allocation caps. IMHO, it's much harder to reason about long-range interactions of threads touching heaps.
The one primitive I wish we had but (outside BEAM) don't is object coloring. In a GC system, I should be able to allocate objects from different heaps and GC them independently .This way, a can write a subroutine that I can prove locally obeys the allocation-rate rule for my latency target and doesn't do any global allocations without giving up the use of the global heap for other purposes. They'd be a bit like the explicit arenas your tribe uses. (Your child heap would count as one "object" for purposes of parent-heap retention.) You could probably adapt existing multi-pool systems like MPS and ART's GC pretty easily too.
But even absent QoL features like these, modern GC is plenty suitable for programs that need to be responsive.
I feel I have to insist that to control latency one has to first eliminate any intrinsic source of it (a GC) and only then deal with what's left (using arena/pool allocators and such) in the face of even soft realtime requirement (which imo should be the default unless utterly impossible).
This is comparable to what you say about coloring, like, if say java had _both_ GC and zig-like allocator api, so one could have fine control over what is happening. Unfortunately it does not, and the idea of not putting all eggs in one basket is somehow unthinkable.
@LoganDark You're right, as long as there is an object graph to scan, 'uncontrollable' latency is an inherent trade-off in GC-based systems. I’ve taken a different route with a C++20 execution engine that eliminates the object graph scan entirely by using pre-allocated, static memory pools and lock-free SPSC structures. It's essentially moving from 'managing GC pauses' to 'deterministic, zero-allocation execution'. Have you ever benchmarked your systems against a lock-free architecture that bypasses the allocator on the hot path?
The lock-free architecture that bypasses the allocator on the hot path is called `alloca`. Many mainstream compilers, and nearly every language that is not C, seemingly haven't properly supported it for years.
Please don't twist. alloca is in fact a limited arena/pool allocator and as such for some small sizes it is latency-free. It is also there in C. It does not have anything to do with GCs.
You insist that offloading other allocations to a GC running on other threads somehow grants the current thread control over its own scheduling.
This is false.
One can say that you can't really control latency unless running under a RTOS and thus we shall never attempt that. This is also false.
There is no conceivable reason one should not assert absolute control upon what his own code does. GC injects uncertainity into that. This is intolerable.
