[Dlang-internal] Concurrent No-Pause GC Option (idea)

[frame]

On Thursday, 25 August 2022 at 19:06:15 UTC, Krzysztof Jajeśnica 
wrote:
> On Monday, 22 August 2022 at 18:00:42 UTC, frame wrote:

> AFAIK forking does indeed eliminate the problem of another 
> thread using the data after scanner marks it as free.
>
> Forked process does not share address space with the parent 
> process (it gets a copy of the parent's address space), so any 
> memory accesses done in the application process after the 
> `fork()` will not influence the scanning process. If the 
> scanner process marks a block as free, then that means it was 
> definitely unreachable in the application process prior to the 
> `fork()`, so the application process has no way to access the 
> block (apart from cases where you hide the pointer from the GC 
> on purpose, but that's a problem for almost all GC 
> implementations, not just the `fork()` one)

I think it does share unless a write operation is performed on 
parent or child side, then both get a fresh mutable copy. So the 
child needs to commit IDs(?) indexes(?) whatever back to the 
parent, and the parent can map it to its memory block [or 
something like that].

That is, of course, way better than a background thread as it 
creates some isolated snapshot.

But consider the parent would call `GC.free()` manually while the 
child is running and the child thinks the block can be freed and 
the parent continued and just used the block right again (don't 
know if the GC actually does this, but I think so). The parent 
must ignore the supplied ID in this case or would collect used 
memory. The GC needs to work differently for this.