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