A separate GC idea - multiple D GCs

Ola Fosheim Grøstad ola.fosheim.grostad at gmail.com
Sat Jan 22 10:59:07 UTC 2022


On Saturday, 22 January 2022 at 10:38:36 UTC, rikki cattermole 
wrote:
> 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.

I believe the number of roots is irrelevant, what you need is to 
have heap separation where you ensure through the type system 
that there can never be an owning pointer in heap #1 for objects 
located in heap #2. You can still have borrowing pointers from 
heap #1 to heap #2 as a non-null borrowing pointer means that the 
type system (or programmer) is responsible for the pointed-to 
object being live.

So, if you let a fiber have it's own heap of this kind, then you 
can reduce the scanning?

But you need to either improve the type system or put the burden 
on the programmer in C++-style.

Either way, I believe distinguishing between ownership and 
borrows can improve on GC performance, not only unique_ptr style 
ownership.

> 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?

> 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.



More information about the Digitalmars-d mailing list