Incremental garbage collection

[Elronnd]

On Thursday, 20 January 2022 at 23:56:42 UTC, Chris Katko wrote:
> I'm just curious what the D language community's thoughts are 
> on it. The tradeoff is: For
> a longer total time / lower throughput, you reduce stress on 
> individual frames which prevents hiccups. That's pretty darn 
> important for games and soft/hard real-time systems.

You can already avoid pauses by simply not allocating.  I would 
prefer to see a generational gc (much higher throughput).  Note 
also incremental is not a panacea; the mutator can still get 
ahead of the collector; go has a somewhat laughable solution to 
this.

On Friday, 21 January 2022 at 00:55:43 UTC, H. S. Teoh wrote:
> Write barriers are required for an incremental GC to work. 
> Write barriers are unlikely to be accepted in D because they 
> introduce synchonization overhead per pointer write. This would 
> kill D's performance in low-level code, and I don't think 
> Walter will ever accept this.

I have heard this claim before.  I don't buy it.

1. Barriers are not that slow.  It is not a 'synchronization'; it 
is a cheap compare-and-branch that will be correctly predicted.  
(Nobody complains about bounds checking...)

2. You do not need a barrier on _every_ pointer write

3. It can be a compile-time option to disable it

4. Lack of typed pointers (gc/non-gc) can be solved 
conservatively with monomorphization