Google opisuje swoje doświadczenia z GC dla Go

Znalazłem ciekawą prezentacje-artykuł odnośni ewolucji GC (garbage collector) w języku Go: https://blog.golang.org/ismmkeynote

TL;DR => Goście z G opisują swoje drutowania z GC dla Go, drobną rewolucję między wersjami 1.4 a 1.5, związane z tym cele - dla nich nieefektywny algorytm GC to nic innego jak niemały koszt dodatkowej farmy serwerów, która nawet dla takiego giganta jak Google nie jest byle czym.
Do tego nie tylko sukcesy, ale też wpadki, złe decyzje projektowe itp. Jak ktoś jest zainteresowany tematyką GC ogółem to myślę, że go to zaciekawi. Generalnie artykuł pokazuje, jak zaawansowaną inżynierią są algorytmy GC, dzięki którym nie trzeba pisać 2-3x tyle kodu extra do logiki biznesowej, by potem przekonać się, że nam pamięć zwiała akurat taką ścieżką, o której jeszcze nie pomyśleliśmy w nadmiarowym kodzie[1]

[1] Oczywiście nie dotyczy Rusta i języków, które radzą sobie w inny sposób bez GC.

dla nich nieefektywny algorytm GC to nic innego jak niemały koszt dodatkowej farmy serwerów, która nawet dla takiego giganta jak Google nie jest byle czym

To wymaga małego wyjaśnienia - ta dodatkowa farma serwerów to podejście siłowe do rozwiązania problemu wysokich opóźnień GC. Zamiast obsługiwać żądanie przez jeden komputer obsłużmy go przez 10 komputerów (czyli praca zostanie niepotrzebnie zduplikowana) - wtedy ryzyko, że trzeba będzie długo czekać na odpowiedź z powodu STW (stop the world) GC znacznie spadnie.

Ogólnie niezła robota, brawa dla autorów Go. Ja ze swojej strony dodam iż w świecie Javy bezpauzowe* GC istnieje od bardzo dawna w płatnej postaci od Azul Systems: http://go.azul.com/continuously-concurrent-compacting-collector
Java 11 dla Linuksa będzie miała wbudowany eksperymentalny bezpauzowy* darmowy ZGC: http://openjdk.java.net/projects/zgc/ a RedHat pracuje nad własnym odpowiednikiem: http://openjdk.java.net/projects/shenandoah/
* bezpauzowy w rzeczywistości oznacza bardzo niskie pauzy

Pojawiła się teraz propozycja kolejnych usprawnień w GC, według opisu obiecująca, bo znacznie upraszczająca dotychczasowy algorytm: https://go-review.googlesource.com/c/proposal/+/128896

Pewnie musi to przejść solidne review, ale uważam, że jakiś eksperymentalny algorytm GC winien być dostępny na żądanie jakimś callem do runtime.*, nie musi ich być tak dużo jak w JVMie, ale stabilny+eksperymentalny byłoby dobrym kompromisem, gdzie takie "propozycje" mogłyby szybciej lądować do testów dla chętnych.

Pewnie musi to przejść solidne review, ale uważam, że jakiś eksperymentalny algorytm GC winien być dostępny na żądanie jakimś callem do runtime

W locie chciałbyś zmieniać algorytm GC? To raczej problematyczne, bo każdy GC korzysta z własnych pomocniczych struktur danych.

Aczkolwiek w .NETu GC ma różne tryby, które chyba można przełączać w locie: https://docs.microsoft.com/en-us/previous-versions/dotnet/netframework-4.0/bb384202(v=vs.100) Jednak zmiana trybu GC to nie zmiana całego GC.