A separate GC idea - multiple D GCs

Ola Fosheim Grøstad ola.fosheim.grostad at gmail.com
Sat Jan 22 09:24:02 UTC 2022


On Friday, 21 January 2022 at 14:09:18 UTC, rikki cattermole 
wrote:
>
> On 22/01/2022 2:56 AM, Chris Katko wrote:
>> So a related question: Has anyone ever thought about 
>> "thread-local garbage collection" or some sort of "multiple 
>> pool [same process/thread] garbage collection"? The idea here 
>> is, each thread [or thread collection] would have its own 
>> garbage collector, and, be the only thread that pauses during 
>> a collection event.
>
> Indeed we have thought about this.
>
> What I want is a fiber aware GC and that implicitly means 
> thread-local too.

Yes, this is better, although you would need to change the 
language semantics so that non-shared means local to a 
fiber/actor as the fiber/actor can move from one thread to 
another.

You also need a per-thread runtime that can collect from sleeping 
fibers/actors and in the worst case signal other thread runtimes 
to collect theirs. Otherwise you would run out of memory when 
memory is available...

In general I'd say you would want to have support for many 
different memory managers in the same executable as different 
fibers/actors may have different memory management needs.






More information about the Digitalmars-d mailing list