Go's march to low-latency GC

[Martin Nowak via Digitalmars-d]

On Saturday, 9 July 2016 at 17:41:59 UTC, Andrei Alexandrescu 
wrote:
> On 7/7/16 6:36 PM, Enamex wrote:
>> https://news.ycombinator.com/item?id=12042198
>>
>> ^ reposting a link in the right place.
>
> A very nice article and success story. We've had similar 
> stories with several products at Facebook. There is of course 
> the opposite view - an orders-of-magnitude improvement means 
> there was quite a lot of waste just before that.

Exactly, how someone can run a big site with 2 second pauses in 
the GC code is beyond me.

> I wish we could amass the experts able to make similar things 
> happen for us.

We sort of have an agreement that we don't want to pay 5% for 
write barriers, so the common algorithmic GC improvements aren't 
available for us.
There is still connectivity based GC [¹], which is an interesting 
idea, but AFAIK it hasn't been widely tried.
Maybe someone has an idea for optional write barriers, i.e. zero 
cost if you don't use them. Or we agree that it's worth to have 
different incompatible binaries.

[¹]: https://www.cs.purdue.edu/homes/hosking/690M/cbgc.pdf

In any case now that we made the GC pluggable we should port the 
forking GC. It has almost no latency at the price of higher peak 
memory usage and throughput, the same trade-offs you have with 
any concurrent mark phase.
Moving the sweeping to background GC threads is sth. we should be 
doing anyhow.

Overall I think we should focus more on good deterministic MM 
alternatives, rather than investing years of engineering into our 
GC, or hoping for silver bullets.