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