The idea of mark/scavenge is pretty cool for page-based allocation and deallocation.
Also real-time or maybe latency-intolerant systems, which basically can't block for garbage collection. You could probably keep scavenging and stay ahead of things without impacting things in a black and white way.
The big lie of GC is that you never need to worry about memory management. The insidious lie is that you have no control when you do need it
Rust went with a new extreme: no GC, but the compiler does a memory verification and a LOT of obscure complex notation and keywords
So ... I'm wondering if there is a happy medium, where you can have keywords that strongly hint to a GC how to manage memory (eg arena/permanent, thread group bound, local/young, etc) that will be easier than rust.
Maybe we could have multiple heaps defined (a big problem with GC heaps is the bigger they are the harder it is for the bigO of the management algorithms to scale, so nice they aren't linear bigO).
I'm thinking of something like Cassandra where tables and even subsections of tables don't need their bloom filters, commit logs, atc all intermingled in a single heap, to the great detriment of heao performance.
Instead, provide annotations to partition the heaps or run multiple heaps
Of course this is a massive complexity rabbit hole/slippery slide.
I think this idea could work really well the the memory system - a pool could be a number of underlying pages and gc would be easy, and letting go of the pages would be too.
As far as I understand, Erlang has one heap per actor. The cost is that messages have to be serialized to pass from one actor to another. But it means there are lots of independent, often tiny heaps which don't need very complicated GCs.