A separate GC idea - multiple D GCs

rikki cattermole rikki at cattermole.co.nz
Sat Jan 22 10:38:36 UTC 2022

That's not the direction I'm thinking. Its not about freeing memory. Its 
about deferment.

The best way to make your code faster is to simply do less work.

So to make global memory scanning faster, we either have to decrease the 
number of roots (likely to end with segfaults) or to decrease the memory 
ranges to scan for.

And since we have a context to associate with memory that is allocated 
and with it roots, we have a pretty good idea of if that memory is still 
alive or not during the execution of said context.

Think about the context of a web server/service. You have some global 
heap memory, router, plugins, adminy type stuff, that sort of thing. 
Most of that sort of memory is either reused or sticks around till the 
end of the process.

But then there is request specific memory that gets allocated then 
thrown away. If you can defer needing to add those memory ranges into 
the global heap, that'll speed up scanning drastically as that is where 
most of your free-able memory will originate from.

To top it off, when you have a concurrent GC design like forking or 
snapshotting, you can scan for those dead fibers memory ranges and it 
won't require stopping the world.

More information about the Digitalmars-d mailing list