Chciałem rozwiązać tylko jeden wątek tego pytania, ale zbieranie nie jest konieczne do stworzenia niskiego poziomu, krytycznych pod względem wydajności aspektów silnika gier AAA. W rzeczywistości omijanie tego rodzaju systemu odwołań i gromadzenia obiektów jest pomocne. Chcesz, aby nawet typy zdefiniowane przez użytkownika były ciągłe w pamięci i pasowały do sąsiednich obiektów w pamięci podręcznej, itp.
Oprócz problemów z wydajnością zbierania śmieci w okresowych odstępach czasu i rozpraszania obiektów w pamięci, gry nie mogą sobie pozwolić być nieszczelnym z ich większymi zasobami, a odśmiecacz śmieci przeszkadza w tym. Tak, właśnie powiedziałem, że GC utrudnia zdolność do unikania wycieków.
Zbieranie śmieci nie jest srebrną kulą przeciwko wyciekom zasobów.
Wbrew pozorom intuicyjności, spójrz na najodleglejsze aplikacje tam obecnie: te, w których im dłużej ich używasz, tym bardziej rośnie zużycie pamięci. Zazwyczaj nie są to aplikacje C lub C++. Aplikacje C/C++ mogą być znane z awarii, ale nie tyle z powodu przecieków. Te nieszczelne są znacznie częściej programowane w językach z funkcją zbierania śmieci.
Weźmy na przykład gry Flash. Jest wiele takich programów, a nie tylko kompletne amatorskie oprogramowanie, które wykorzystuje coraz więcej zasobów, a wolniej i wolniej, im dłużej grasz, co zmusza do restartowania przeglądarki, aby ponownie uzyskać szybką grę. Jednak są one kodowane w języku ActionScript, języku, który ma odśmiecanie.
Teoretycznie wywóz śmieci powinien zmniejszyć nieszczelności. W praktyce często eliminuje tańsze i łatwiejsze do naprawienia i zauważenia fizyczne przecieki (whoops zapomniałem usunąć ten ciąg) w zamian za dużo droższe i trudniejsze do wyodrębnienia logiczne wycieki (whoops, logika system powoduje, że duże zasoby pozostają w pobliżu, dopóki cała gra nie zostanie zamknięta).
Dzieje się tak, ponieważ w języku GC, jeśli chcesz utworzyć wspólną własność nowego zasobu, R, wszystko, co musisz zrobić, to przechować uchwyt/odniesienie do niego w innym obiekcie, A. B i C może również przechowywać uchwyt do R, a teraz R ma trzech właścicieli i zostanie zwolniony tylko wtedy, gdy wszyscy trzej właściciele zwolnią odniesienie. Użytkownik widzi i pracuje tylko z tym, co A przechowuje, więc logika gry polega na okresowym usuwaniu R z A, ale odniesienia do niej pozostają w milczeniu w kodzie, o którym zapomniał napisać kod: B i C.W C/C++ zwisający wskaźnik w tym przypadku może być w rzeczywistości preferowany, ponieważ prowadziłoby to do natychmiastowego wykrycia i usunięcia problemu podczas testowania gry, w którym programista korzystający z debuggera bardzo szybko wykryje i naprawi problem. W języku GC jest on niezwykle trudny do wykrycia i podczas gdy program się nie zawiesza, może zacząć tracić czas.
Więc GC zdecydowanie unika wiszących wskaźników, ale gdyby coś wisiało w C/C++ i nie zwisałoby w języku GC, to jest to logiczny przeciek zasobów w języku GC i segfault w C/C++ . Innymi słowy, GC wymienia zwisające wskaźniki dla zwisających zasobów, które pozostają na zawsze. Wymienia to, co może być rażącym wypadkiem w cichy wyciek, który może być koszmarem, który można odkryć (i może nawet pozostać niezauważonym długo po zwolnieniu produktu). Tak więc dla czegoś takiego jak gra, która tworzy masywne, dynamiczne światy, obiekty graficzne i fizyki i tak dalej i być może w każdej klatce, logiczne przecieki zasobów są wielką sprawą.
Zbieranie śmieci jest najlepsze, gdy wycieki zasobów nie stanowią wielkiego problemu.
Ten poprzedni scenariusz jest niestety zbyt powszechny w środowisku zespołowym na dużą skalę przy użyciu GC, zwłaszcza, jeśli każdy programista nie jest bardzo ostrożny wobec pułapek wyrzucania śmieci i silnej potrzeby słabych referencji. Więc GC niekoniecznie jest czymś, co można przytoczyć jako zaletę przy tworzeniu gier, chyba że mówisz tylko o logice ludzkiej najwyższego poziomu. Niższa, delikatna logika systemu, która musi nieustannie tworzyć i uzyskiwać dostęp do zasobów oraz niszczyć je, z reguły będzie lepsza, nawet jeśli chodzi o unikanie przecieków, bez niego.
Spróbuj spojrzeć na LWJGL, jego wspaniałą bibliotekę graficzną Java. Jest całkiem niedawno, jeśli pamięć służy. –