The GC sucks because it requires one to use it or jump through
many hoops and unsafe techniques to get away from it.
It would be better if we simply had more control over the GC.
1. Allow for granular GC - Multiple independent GC's that handle
independent parts of the D ecosystem each of which can be
overridden in code if desired.
One GC for the main user program(allocations, etc), One for D
internals such as slices, One for exception handling, One for
The idea is that by having better resolution each GC can be
tailored for it's specific purpose. For example, having a GC that
handles the exception handling can be tailored so that it uses
smaller memory and does not need to escape the memory reason to
scan for false pointers, etc. It can also does not need to be run
very often and should be relatively fast... in fact, if no
exceptions are on the stack then it should exist immediately.
Similarly, lambda and delegates would have a relatively simple
and fast GC since no false pointers need to be scanned, etc. In
fact, some simple escape analysis should allow local allocations
to bypass the GC.
What these do is reduce the overhead that might trigger a
complete GC scan for no real purpose other than that is the way
the current GC is designed.
When new GC topologies are added they simply replace the old. The
main idea is to granularize the GC which simply requires
modifying the compiler to use the specific GC(e.g., when slices
are allocated, instead of allocating with the GC, it allocates
with GC.Slices, or whatever).
The goal here is to still allow most of the D dependent GC
functionality to persist but not have to throw the baby out with
the bath water. E.g., keep the GC for exceptions(if it still uses
it), lambda's/delegates, but allow one to use manual memory
management for slices, or any combination one ones. The main
problem with the GC is stop the world and it's scanning for false
pointers. But we really don't have to have an all or nothing
attitude which is what is forced on us by a poor design.