A separate GC idea - multiple D GCs

rikki cattermole rikki at cattermole.co.nz
Sat Jan 22 11:06:24 UTC 2022

On 22/01/2022 11:59 PM, Ola Fosheim Grøstad wrote:
>> 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.
> But you need to scan those memory ranges if they can contain pointers 
> that can reach GC-memory?

Yeah those are roots. They still have to be added into the global heap 
to be scanned.

The goal is to decrease the number of memory ranges that need to be 
scanned for in a full scan.

Cost = Roots * Ranges

Get Ranges down (until it actually does need to be scanned for), lowers 
the cost, that's the goal by what I am suggesting!

>> 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.
> You want to require taking a snapshot-copy of the pointer-containing 
> heap? That will make the collector much less useful, I think.

We already have forking, and that is super useful for getting user 
threads to not stop. We are only missing snapshotting for Windows now.

More information about the Digitalmars-d mailing list