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.
