Incremental garbage collection

[Paulo Pinto]

On Friday, 21 January 2022 at 02:17:34 UTC, Brad Roberts wrote:
> On 1/20/2022 5:46 PM, Elronnd via Digitalmars-d wrote:
>> 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 synchronization 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.
>
> This is clearly an area where anecdotals like "Walter will 
> never accept this" aren't useful.  There's ample evidence to 
> show that he accepts when he's proven wrong.
>
> To make any progress towards a better GC it's going to have to 
> be demonstrated.  And the proof will justify the changes.  If 
> they're good and the complexities required to get there aren't 
> awful, then they'll make into the code base.  If they're not, 
> then they wont.  The status quo is easy to get stuck in and 
> help no one.
>
> Someone with a good background in GC's needs to step up and be 
> it's champion.  I expect that several people would rally to 
> help once some basic momentum is established.  So, willing to 
> be the rallying cry and step up?

To be honest, that is something that is more fun to do in the Go, 
.NET and Java communities, because not only no one cares about 
the matra that on a systems programming language GC verbotten is 
supposed to be a thing, there are hardware companies shipping 
real products with them.

So in those communities the whole discussion isn't if GC belongs 
or not in a systems programming language, being rebooted every 
couple of months, rather how to improve it to the point that e.g. 
writing firmware in Go is a reality that one can ship into a 
commercial product (USB Armory).