Chociaż nie testowałem G1 w produkcji, pomyślałem, że skomentuję, że GC są już problematyczne dla przypadków bez „ogromnych” stosów. GC może mieć poważny wpływ na usługi z, powiedzmy, 2 lub 4 koncertami. GC młodego pokolenia zwykle nie stanowią problemu, ponieważ kończą się w jednocyfrowych milisekundach (lub co najwyżej dwucyfrowych). Ale kolekcje starej generacji są znacznie bardziej problematyczne, ponieważ zajmują wiele sekund przy rozmiarach starej generacji wynoszących 1 gig lub więcej.
Otóż: teoretycznie CMS może tam bardzo pomóc, ponieważ większość operacji może działać równolegle. Jednak z biegiem czasu zdarzają się sytuacje, w których nie może tego zrobić i będzie musiał wrócić do zbiórki „stop the world”. A kiedy to się stanie (powiedzmy po 1 godzinie - niezbyt często, ale wciąż za często), no cóż, trzymaj się swoich pieprzonych czapek. Może to zająć minutę lub dłużej. Jest to szczególnie problematyczne w przypadku usług, które próbują ograniczyć maksymalne opóźnienia; zamiast, powiedzmy, 25 milisekund, aby obsłużyć żądanie, zajmuje teraz dziesięć sekund lub dłużej. Aby dodać obrażenia do obrażeń, klienci często przekraczają limit czasu i ponawiają żądanie, co prowadzi do dalszych problemów (tzw. „Burza gówna”).
Jest to jeden obszar, w którym G1 miał nadzieję bardzo pomóc. Pracowałem dla dużej firmy, która oferuje usługi w chmurze do przechowywania i wysyłania wiadomości; i nie mogliśmy użyć CMS, ponieważ chociaż przez większość czasu działał lepiej niż równoległe odmiany, miał te załamania. Tak więc przez około godzinę było fajnie; a potem coś uderzyło w wentylator ... a ponieważ usługa była oparta na klastrach, kiedy jeden węzeł miał kłopoty, inne zazwyczaj podążały za nimi (ponieważ przekroczenia czasu spowodowane przez GC prowadzą do tego, że inne węzły uważają, że węzeł uległ awarii, co prowadzi do ponownych tras).
Nie sądzę, aby GC stanowiło tak duży problem dla aplikacji, a być może nawet usługi nieklastrowe są rzadziej dotykane. Jednak coraz więcej systemów jest klastrowanych (szczególnie dzięki magazynom danych NoSQL), a rozmiary stert rosną. GC OldGen są superliniowo powiązane z rozmiarem sterty (co oznacza, że podwojenie rozmiaru sterty ponad dwukrotnie zwiększa czas GC, zakładając, że rozmiar zestawu danych na żywo również się podwoi).