Granular GC

Amorphorious Amorphorious at gmail.com
Sat Mar 10 19:53:22 UTC 2018


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 
lambda's/delegates, etc.

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.



More information about the Digitalmars-d mailing list