Zbieranie śmieci

Image
Animacja automatycznego wyrzucania śmieci. Obszar pamięci jest wypełniony różnymi obiektami (przedstawionymi kolorami), z których niektóre są również ponownie niszczone i pozostawiają luki w obszarze pamięci. Jeśli (jak w tym przykładzie) nie ma wystarczającej ilości wolnego miejsca „na końcu” lub jeśli zdecyduje automatyczny garbage collector, pamięć jest „skompresowana”, a wszystkie nadal używane obiekty są umieszczane na początku, a wszystkie luki w pamięci są konsolidowane na koniec. Dzięki temu duży obszar pamięci jest ponownie dostępny do przyszłego tworzenia obiektów.

Zbieranie śmieci , krótka GC ( English do zbierania śmieci , a nawet zbierania śmieci lub gromadzenia sterty nazwie) w wyznaczonym oprogramowania i technologii informatycznych , automatyczne zarządzanie pamięcią , co pozwala uniknąć problemów z pamięcią; korzyść jest kupowana przy zwiększonym zużyciu zasobów. Między innymi, wymóg pamięci na program komputerowy jest zminimalizowane . W czasie wykonywania podejmowana jest próba automatycznej identyfikacji obszarów pamięci, które nie są już potrzebne, aby następnie je zwolnić. Niektóre automatyczne czyszczenie pamięci również scalają obszary pamięci, które są nadal używane ( defragmentacja ).

motywacja

W wielu systemach oprogramowania wymagana (robocza) pamięć jest rezerwowana dynamicznie (w razie potrzeby) . Jeśli nie jest już używany po przetworzeniu części programu, pamięć powinna zostać ponownie zwolniona, aby umożliwić ponowne wykorzystanie tego zasobu. W przypadku jawnego, ręcznego zarządzania pamięcią odbywa się to poprzez określenie rezerwacji i zwolnienia pamięci w programie przez programistę , procedura, która szybko staje się skomplikowana, a przez to potencjalnie podatna na błędy . Oprócz zapominania o wydaniu, co może prowadzić do niedoboru pamięci w dłuższej perspektywie, zbyt wczesne zwolnienie wciąż wymaganej (w innym miejscu) pamięci zwykle prowadzi do awarii programu. Zapomniane wydania pamięci często nie prowadzą od razu do nieprawidłowości w przepływie programu — przynajmniej nie podczas typowo krótkich uruchomień programu podczas opracowywania, ale tylko wtedy, gdy gotowy program jest obsługiwany przez użytkownika końcowego bez przerw przez wiele godzin i dni.

Przy ręcznym zarządzaniu pamięcią defragmentacja pamięci jest często niemożliwa lub bardzo czasochłonna. Znacznie pofragmentowana pamięć może spowodować, że program nie przydzieli pamięci, ponieważ nie jest dostępny wystarczająco duży ciągły obszar.

opis

Ideą automatycznego zbierania śmieci jest to, aby rutyna zwana garbage collector wykonywała tę pracę automatycznie, bez konieczności robienia czegokolwiek przez programistę. TJ. zarządzanie pamięcią zostało przesunięte z jednoznacznej definicji czasu tworzenia programu ( czas kompilacji ) do dynamicznej analizy wymagań pamięci w czasie wykonywania programu.

Takie automatyczne usuwanie elementów bezużytecznych zwykle działa w tle (lub równolegle ) w mniej lub bardziej regularnych odstępach czasu (np. podczas przerw w przepływie programu) i nie jest jawnie wyzwalane przez program. Jednak GC często może być również wyzwalany bezpośrednio, aby dać programowi pewną kontrolę nad czyszczeniem, np. B. w sytuacji niewystarczającej pamięci ( out-of-memory ).

podejścia

Istnieje kilka podejść do implementacji automatycznego zbierania elementów bezużytecznych. Pożądanymi wymaganiami mogą być jak najmniejszy przekrój pamięci , maksymalna szybkość alokacji , zmniejszenie fragmentacji pamięci i wiele innych, które mogą również być ze sobą sprzeczne i prowadzić do sprzecznych celów . TJ. W zależności od aplikacji automatyczne odśmiecanie może wyglądać bardzo różnie i na pewno spełniać wiele wymagań, ale niektóre nie.

Zazwyczaj jednak wszystkie te warianty są związane z dwoma podstawowymi typami śmieci: konserwatywną i niekonserwatywną.

Konserwatywna automatyczna zbiórka śmieci

Konserwatywny automatyczny odśmiecacz pamięci to taki, który nie może niezawodnie wykryć wszystkich obiektów, do których nie ma odniesień. Zwykle nie ma informacji o tym, gdzie w pamięci znajdują się odniesienia do innych obiektów. Aby wyczyścić pamięć, musi przeszukać pamięć pod kątem możliwych odniesień. Każda sekwencja bitów, która może być prawidłowym odniesieniem w pamięci, jest traktowana jako odwołanie. Nie można określić, czy nie jest to jednak losowy wzór. Dlatego konserwatywni kolekcjonerzy czasami rozpoznają obiekty jako odniesienia, gdy w rzeczywistości tak nie jest. Ponieważ automatyczny garbage collector nie może usunąć obiekty, które mogą być nadal używane, to muszą konserwatywnie zakładamy, że rozpoznał sekwencja bitowa jest odwołaniem.

Konserwatywny kolektor może stanowić ryzyko, zwłaszcza gdy automatyczny zbieracz elementów bezużytecznych musi również zwolnić pilniejsze zasoby niż pamięć (patrz finalizacja ). Ogólnie rzecz biorąc, konserwatywne GC można znaleźć tam, gdzie dozwolone są wskaźniki wewnętrzne (tj. wskaźniki do różnych części obiektu), co utrudnia wdrożenie automatycznego zarządzania pamięcią. Przykładem tego są języki C i C++. Należy w tym miejscu zaznaczyć, że nie dotyczy to „typów zarządzanych” w C++/CLI , ponieważ wprowadzono tam ich własne typy referencyjne do automatycznego odśmiecania pamięci, które nie pozwalają na odczytanie adresu obiektu bezpośrednio.

Niekonserwatywne automatyczne zbieranie śmieci

W niekonserwatywnym automatycznym usuwaniu śmieci (czasami nazywanym „dokładnym śmieciem” w dalszej części) rozumie się, że jest to jedna z metadanych, za pomocą których mogą zlokalizować wszystkie odniesienia w obiektach i ramkach stosu . W przypadku niekonserwatywnego zbierania śmieci rozróżnia się śledzenie śmieciarzy i liczenie referencyjne .

Algorytmy śledzenia

Algorytm mark-and-sweep

Dzięki tej metodzie wyrzucania elementów bezużytecznych po obiektach, o których wiadomo, że są nadal używane, następują wszystkie odwołania do innych obiektów. Każdy osiągnięty w ten sposób obiekt jest oznaczony. Wszystkie nieoznaczone obiekty są następnie udostępniane do ponownego użycia.

Wydanie może prowadzić do fragmentacji pamięci. Problem jest tutaj nieco mniejszy niż w przypadku ręcznego zarządzania pamięcią. Podczas gdy przy ręcznym zarządzaniu pamięcią cofanie alokacji zawsze odbywa się natychmiast, przy funkcji znakowania i przeciągania kilka obiektów jest prawie zawsze usuwanych jednocześnie, co uwalnia większe, ciągłe obszary pamięci.

Algorytm znakowania i kompaktowania

Algorytm mark-and-kompaktowy , jak mark-and-sweep, wykorzystuje zasadę osiągalności na wykresach w celu rozpoznawania obiektów, które są nadal odwołuje. Kopiuje to do innej lokalizacji w pamięci. Cały obszar, z którego wciąż się odwołuje (mówi się również o „żywych”) obiektach, jest teraz uważany za wolny obszar pamięci.

Wadą tej metody jest to, że same „żywe” obiekty są przesuwane, ponieważ wskaźniki do nich stają się nieaktualne i muszą być dostosowane. Są na to zasadniczo co najmniej dwie metody:

  1. Każdy obiekt jest adresowany za pomocą dwóch kierunków pośrednich (obrót) (poprzez wskaźnik do wskaźnika do obiektu ), tak że podczas ruchu należy dostosować tylko wskaźnik, który wskazuje bezpośrednio na obiekt.
  2. Wszystkie odniesienia odnoszą się bezpośrednio do obiektu, aby uniknąć czasochłonnego wyłuskiwania i są odpowiednio dostosowywane po przeprowadzce.

Przenoszenie obiektów ma jednak tę zaletę, że te, które „przeżyły” czyszczenie, są teraz wszystkie kompaktowane, a pamięć jest praktycznie defragmentowana. Możliwe jest również bardzo szybkie przydzielenie, ponieważ wolne miejsce do przechowywania nie jest poszukiwane w czasochłonny sposób. Wyczyść: Jeśli obiekty odniesienia zostaną przeniesione na „początek” pamięci, nowa pamięć może zostać po prostu przydzielona na „końcu”, za ostatnim żywym obiektem. Alokacja działa stosunkowo łatwo, podobnie jak stos .

Pokoleniowy

Generacyjne GC skracają czas zwalniania pamięci. W tym celu wykorzystuje się sytuację, w której w praktyce żywotność obiektów jest zwykle bardzo różna: Z jednej strony istnieją obiekty, które przetrwają cały czas działania aplikacji. Z drugiej strony istnieje duża liczba obiektów, które są potrzebne tylko tymczasowo do wykonania pojedynczego zadania. W generacyjnych GC pamięć jest podzielona na kilka podobszarów (generacji). Długość życia jest określana ilościowo przez licznik, który jest zwiększany z każdym wyrzucaniem śmieci. Z każdym zastosowaniem algorytmu zwalniania (np. Mark-and-Compact lub Stop-And-Copy) obiekty długowieczne są przenoszone do wyższej generacji. Zaletą jest to, że odśmiecanie może być wykonywane częściej i szybciej dla niższych pokoleń, ponieważ tylko niektóre obiekty muszą zostać przeniesione, a ich wskaźniki zmienione. Istnieje duże prawdopodobieństwo, że wyższe pokolenia zawierają tylko żywe (lub bardzo niewiele martwych) obiektów i dlatego wymagają rzadszego sprzątania.

Image
Pokolenia GC w Java HotSpot

Liczba pokoleń jest określana heurystycznie (na przykład trzy w .NET, dwa dla młodych obiektów (zwanych również młodą generacją) i jedno dla starych obiektów (tenured generation) w Java VM firmy Sun). Ponadto dla każdego pokolenia można zastosować różne algorytmy. Na przykład w Javie zmodyfikowany algorytm stop-and-copy jest używany dla najniższej generacji i mark-and-compact dla wyższej generacji.

Liczba referencji

Dzięki tej metodzie każdy obiekt przechowuje licznik z liczbą wszystkich odwołań, które wskazują na ten obiekt. Jeśli licznik referencyjny obiektu spadnie do zera, można go zwolnić.

Szczególnym problemem związanym z kolekcją sterty z liczeniem referencji jest tak zwana referencja cykliczna , w której obiekty przechowują referencje do siebie, ale poza tym nie są już używane przez żadnego konsumenta w systemie. Załóżmy na przykład, że obiekt A zawiera referencję do obiektu B i odwrotnie, podczas gdy reszta systemu nie potrzebuje już jego usług. W ten sposób oba obiekty odwołują się do siebie (cyklicznie) , dlatego automatyczne usuwanie śmieci nie jest w stanie łatwo rozpoznać, że nie są już używane. Konsekwencją tego jest to, że pamięć pozostaje zajęta przez czas wykonywania programu. Istnieją różne algorytmy, które potrafią rozpoznać i rozwiązać takie sytuacje, głównie zgodnie z zasadą dostępności w grafach .

nieruchomości

Dzięki wyrzucaniu elementów bezużytecznych można całkowicie lub przynajmniej częściowo uniknąć niektórych typowych błędów programistycznych, które są często popełniane w przypadku dynamicznego zarządzania pamięcią . Na szczególną uwagę zasługują wycieki pamięci , podwójne zwolnienie zasobów oraz dereferencja zasobów przypadkowo zwolnionych zbyt wcześnie ( zawieszone wskaźniki ). Zwolnienie obiektów, do których istnieją odniesienia, prowadzi do zawieszania się wskaźników , co często prowadzi do awarii programu i niedeterministycznego zachowania.

W konsekwencji twierdzenia Rice'a nie można ustalić, czy obiekty, do których się odwołuje, będą kiedykolwiek ponownie użyte. Dlatego automatyczne usuwanie elementów bezużytecznych zwalnia tylko obiekty, do których program nie odwołuje się już; nie zapobiega „ przeciekom pamięci ” w rodzaju, że program nadal przechowuje odniesienie do obszaru pamięci, ale nigdy więcej nie używa zawartości. Takie wycieki pamięci zwykle reprezentują błędy logiczne lub błędy projektowe (błędy w podstawowej koncepcji, nieprawidłowe wymagania dotyczące oprogramowania, błędy projektowe oprogramowania) i mogą również wystąpić przy nieautomatycznym zarządzaniu pamięcią.

Ponadto garbage collection rozwiązuje problem fragmentacji pamięci , co nie jest błędem programistycznym w ścisłym tego słowa znaczeniu, ale może opierać się na słabym projekcie programu. Ten problem może prowadzić do awarii programu, które są trudne do odtworzenia. Problem fragmentacji pamięci generalnie nie jest rozwiązywany przez jawne/ręczne zarządzanie pamięcią.

Efektywność

To, czy automatyczne usuwanie śmieci przyspiesza, czy spowalnia programy jako całość, jest kontrowersyjne. W niektórych kontekstach, takich jak Na przykład, jeśli pamięć jest zwalniana tylko wtedy, gdy wymagania systemowe są obecnie niskie lub jeśli zarządzanie pamięcią systemu jest zwalniane przez defragmentację, może to prowadzić do zwiększenia wydajności. Istnieją mikrobenchmarki, które pokazują, że w językach programowania z automatycznym czyszczeniem pamięci tworzenie / uwalnianie obiektów jest ogólnie szybsze niż bez, ale także mikrobenchmarki, które widzą głównie negatywny wpływ na ogólną wydajność. Publikacja z 2005 r. stwierdza, że ​​odśmiecanie jest tylko tak dobre lub nieco lepsze niż jawne zarządzanie pamięcią, jeśli odśmiecanie ma prawo do pięciokrotnie większej ilości pamięci, niż jest faktycznie potrzebne. Przy trzykrotnie większej ilości pamięci wyrzucanie elementów bezużytecznych działałoby średnio o 17% wolniej, przy dwukrotnie większej ilości pamięci o 70% wolniej niż w przypadku jawnego zarządzania pamięcią.

Zużycie pamięci

Jeśli chodzi o zużycie pamięci, automatyczne zarządzanie pamięcią i jej czyszczenie prowadzi do narzutu w porównaniu z jawnym, ręcznym zarządzaniem pamięcią ze względu na opóźnione w czasie czyszczenie. Publikacja naukowa z 1993 r. szacuje koszty utrzymania konserwatywnego zbierania śmieci (dostępne na przykład dla języka C) na zazwyczaj 30–150%. Z drugiej strony, prawidłowa implementacja ręcznego zwalniania pamięci w nietrywialnych programach jest skomplikowana do zaimplementowania, co tworzy źródła błędów dla wycieków pamięci w ręcznym zwalnianiu pamięci . Na przykład, często stosowana metoda liczenia referencji , nie jest w stanie rozpoznać referencji cyklicznych i prowadzi do wycieków pamięci, jeśli nie jest uzupełniona złożonymi algorytmami.

determinizm

Nie definiując jednoznacznie decyzji o czasie zwolnienia, programista zrzeka się również części kontroli nad przebiegiem programu. Od czasu automatycznego zbierania śmieci ja. D. R. jednocześnie ma miejsce, sam program nie ma informacji o tym, kiedy obszary pamięci zostały faktycznie zwolnione, a kiedy obiekty sfinalizowane . W rezultacie przepływ programu potencjalnie nie jest już deterministyczny .

W szczególności mogą wystąpić następujące formy niedeterministycznego zachowania:

  • Czas finalizacji jest nieokreślony: nawet jeśli obiekt zostanie uznany za niepotrzebny i został wybrany do czyszczenia, czas finalizacji jest nieokreślony, co oznacza, że ​​przebieg programu nie jest już deterministyczny. Jest to szczególnie problem, gdy obiekt korzysta ze współdzielonych zasobów lub wykonuje końcowe obliczenia. Robienie tego w trakcie finalizacji jest uważane za anty-wzorzec w programowaniu .
  • Runtime - zarówno całego programu, jak i tylko poszczególnych sekcji - może stać się niedeterministyczny z powodu przerw przez garbage collector. Jest to problem szczególnie w przypadku systemów czasu rzeczywistego.Na przykład w systemach czasu rzeczywistego niedopuszczalne jest, aby wykonywanie programu było przerywane w nieprzewidywalnych momentach przez wykonywanie odśmiecania pamięci. W przypadku systemów czasu rzeczywistego, tak jak w przypadku Real-Time Java , na przykład automatyczne usuwanie śmieci działa zapobiegawczo (na przykład w procesie bezczynności ) i przyrostowo. Proste metody przyrostowe działają na przykład z tak zwanym trójkolorowym znakowaniem.

Defragmentacja

Korzystając z algorytmów kompaktowania, wyrzucanie elementów bezużytecznych może zapobiegać fragmentacji pamięci . Zobacz Oznaczanie i kompaktowanie . Pozwala to uniknąć luk w pamięci, których nie można było wypełnić z powodu nowych obiektów, które są zbyt duże. Defragmentacja prowadzi do dłuższego opóźnienia w zwalnianiu pamięci, ale skraca czas alokacji. Aby móc jak najszybciej wykonać zwolnienie pamięci, zapewniono, że duże obszary pamięci muszą być czyszczone tak rzadko, jak to możliwe. Dlatego te algorytmy są najlepiej stosowane w połączeniu z metodami generacyjnymi .

Defragmentacja pamięci ma następujące zalety:

  • Używana jest cała dostępna pamięć.
  • Alokacja pamięci zajmuje mniej czasu, ponieważ struktury danych zarządzające stertą stają się mniej złożone. Znalezienie wolnego miejsca w pamięci o odpowiednim rozmiarze jest łatwiejsze.
  • Obiekty alokowane jeden po drugim znajdują się zwykle obok siebie w pamięci (nazywa się to dobrą lokalizacją pamięci ). Badania wykazały, że obiekty tworzone jeden po drugim są często wykorzystywane jednocześnie do określonej operacji. Jeśli są wystarczająco blisko siebie, dostęp do szybkiej pamięci podręcznej jest dostępny, a nie do wolniejszej pamięci znajdującej się za nią.

Finalizacja

Jak finalizacji ( English finalizacja ) jest znany w językach programowania obiektowego, specjalna metoda, która jest wywoływana, gdy obiekt przez śmieciarza jest zwolniony.

W przeciwieństwie do destruktorów metody finalizacji nie są deterministyczne: destruktor jest wywoływany, gdy obiekt jest jawnie zwolniony przez program. Jednak metoda finalizacji nie jest wywoływana, dopóki garbage collector nie zdecyduje się zwolnić obiektu. W zależności od modułu odśmiecania pamięci, może się to zdarzyć w dowolnym momencie, gdy zostanie ustalone, że program nie używa już obiektu — prawdopodobnie nigdy lub pod koniec środowiska wykonawczego (zob. też rozdział Determinizm ).

Finalizacja może prowadzić do problemów w praktyce, jeśli odpowiada za uwolnienie zasobów:

  • Obiekty zarządzające zasobami powinny nie tylko je zwalniać w trakcie finalizacji. W przeciwnym razie może to prowadzić do zablokowanych stanów w przepływie programu, ponieważ nie można przewidzieć czasu finalizacji.
  • Finalizacja tworzy dodatkowe obciążenie obliczeniowe dla automatycznego usuwania śmieci, które należy przeprowadzić tak szybko, jak to możliwe i bez zakłócania pozostałej części programu.
  • Nie ma określonej kolejności finalizacji. Może się zatem zdarzyć, że podczas finalizacji zostaną udostępnione inne obiekty, które również podlegają finalizacji, ale w tym momencie już nie istnieją.
  • W zależności od implementacji (na przykład w języku programowania Java ) nie ma gwarancji, że procedura finalizacji zostanie w ogóle wywołana przez automatyczny garbage collector.

W języku programowania Java obiekty mają specjalną metodę, finalize()którą można w tym celu przesłonić . Z powodów wymienionych powyżej zaleca się, aby Java całkowicie zrezygnowała z finalizacji i zamiast tego używała wyraźnej metody zakończenia. Automatyczne czyszczenie pamięci należy wtedy wyłącznie do zadania zarządzania pamięcią.

dystrybucja

Niektóre starsze ( APL , LISP , BASIC ) i wiele nowszych języków programowania ma wbudowane automatyczne usuwanie śmieci.

W przypadku języków programowania takich jak C , w których programista musi ręcznie zarządzać pamięcią, istnieją biblioteki, które zapewniają automatyczne usuwanie śmieci, które można łatwo obejść podczas programowania lub nawet trzeba ominąć w programowaniu na poziomie systemu . Z tego powodu w niektórych językach programowania moduły programowane na poziomie systemu można wykluczyć z automatycznego wyrzucania elementów bezużytecznych przez wyraźne ich oznaczenie (na przykład w C# z opcją /unsafe lub w Component Pascal z obowiązkową instrukcją IMPORT SYSTEM ).

Kolejne przykłady języków programowania z automatycznym zarządzaniem pamięcią to Smalltalk , Haskell , Oberon , Python , Ruby , OCaml , Perl , Visual Objects , ABAP , Objective-C (od wersji 2.0), D oraz wszystkie języki oparte na wirtualna maszyna Javy (JVM) ( Java , Groovy , Clojure , Scala , ...), jak również, które zostały opracowane dla plików wykonywalnych języka wspólnego z .NET (na przykład C # lub VB.NET ).

Ekosystem Apple

Firma Apple wprowadziła Garbage Collection w 2007 roku wraz z wydaniem Mac OS X Leopard (10.5) jako „najważniejszej zmiany” w Objective-C 2.0, która według Apple przyniosła „Objective-C taką samą łatwość zarządzania pamięcią, jak inne nowoczesne Języki". 2012 OS X Mountain Lion , jednak odśmiecanie zostało uznane (10.8) za przestarzałe, a użycie z Mac OS X Lion wprowadziło (10.7) automatyczny mechanizm zliczania referencji (ang. Automatic reference counting, ARC) w czasie kompilacji na podstawie tylko wprowadzone kompilatory CLANG / LLVM 3.0 wymuszone. Dzięki temu automatycznemu zliczaniu referencji kompilator zawiera kod do rozpoznawania i usuwania obiektów, które nie są już potrzebne, za pomocą zliczania referencji w odpowiednich punktach. W przeciwieństwie do GC ze zliczaniem referencji, automatyczne zliczanie referencji przebiega seryjnie iw godzinach określonych w czasie kompilacji, a zatem jest deterministyczne. ARC nie zawiera jednak żadnych środków rozpoznawania odniesień cyklicznych; Dlatego programiści muszą wyraźnie zarządzać żywotnością swoich obiektów i ręcznie rozwiązywać cykle lub pracować ze słabymi lub niepewnymi odniesieniami.

Według Apple aplikacje mobilne bez GC mają lepszą i bardziej przewidywalną wydajność. iOS bez GC jako podstawa umożliwia Apple budowanie urządzeń mobilnych z mniejszą ilością pamięci niż konkurencja oparta na GC, które nadal mają taką samą lub lepszą wydajność i żywotność baterii; podejście, które zostało również opisane w prasie branżowej jako zaleta architektoniczna.

literatura

  • Richard Jones, Rafael Lins: Zbieranie śmieci. Algorytmy do automatycznego dynamicznego zarządzania pamięcią. John Wiley, Chichester 1996, ISBN 0-471-94148-4 .
  • Richard Jones, Anthony Hosking, Eliot Moss: Podręcznik zbierania śmieci. Sztuka automatycznego zarządzania pamięcią. (Chapman & Hall Applied algorytmy i serie struktur danych). Prasa CRC, Boca Raton, Floryda. 2011, ISBN 978-1-4200-8279-1 .

linki internetowe

Indywidualne dowody

  1. ↑ Satish Chandra Gupta, Rajeev Palanki: Wycieki pamięci Java — złap mnie, jeśli potrafisz. IBM DeveloperWorks, 16 sierpnia 2005, zarchiwizowane od oryginału z 22 lipca 2012 ; udostępniono 2 kwietnia 2015 r .
  2. ↑ Jak naprawić wycieki pamięci w Javie ( Memento z 5 lutego 2014 w archiwum internetowym ) Veljko Krunic (10 marca 2009)
  3. ↑ Tworzenie wycieku pamięci w Javie na stackoverflow.com (angielski)
  4. ↑ Microbenchmarking C++, C# i Java: tworzenie/niszczenie obiektów i wywoływanie metod. Dr. Dobb's Journal , 1 lipca 2005, dostęp 11 kwietnia 2014 .
  5. ↑ Arne Schäpers, Rudolf Huttary: Daniel Düsentrieb - C#, Java, C++ i Delphi w teście wydajności, część 2. c't , grudzień 2003, s. 222-227 , dostęp 26 października 2009 : "" Wyniki pokazują, po pierwsze, że garbage collector (podczas niszczenia) nie wydaje się przynosić żadnych zauważalnych wad w zakresie zachowania środowiska uruchomieniowego „i” Czasem prawie dwukrotnie wymaganym przez C++ do budowy w porównaniu z innymi kandydatami… ""
  6. ^ Robert Hundt: Rozpoznawanie pętli w C++ / Java / Go / Scala. (PDF; 318 kB) Scala Days 2011, 27 kwietnia 2011, dostęp 17 listopada 2012 (angielski, Stanford, Kalifornia): „ Java pokazuje duży komponent GC, ale dobrą wydajność kodu. [...] Uważamy, że pod względem wydajności C++ wygrywa z dużym marginesem. [...] Wersja Java była prawdopodobnie najprostsza do zaimplementowania, ale najtrudniejsza do przeanalizowania pod kątem wydajności. W szczególności efekty związane ze zbieraniem śmieci były skomplikowane i bardzo trudne do dostrojenia ”
  7. ^ Matthew Hertz, Emery D. Berger: Ilościowa wydajność zbierania śmieci vs. jawne zarządzanie pamięcią. OOPSLA 2005, 2005, dostęp 15 marca 2015 r. (w języku angielskim): „ W szczególności, gdy wyrzucanie elementów bezużytecznych ma pięć razy więcej pamięci niż jest to wymagane, jego wydajność w czasie wykonywania jest równa lub nieznacznie większa niż w przypadku jawnego zarządzania pamięcią. Jednak wydajność wyrzucania elementów bezużytecznych znacznie spada, gdy musi używać mniejszych stert. Przy trzykrotnie większej ilości pamięci działa średnio o 17% wolniej, a przy dwukrotnie większej ilości pamięci działa o 70% wolniej. "
  8. ↑ Benjamin Zorn: Zmierzony koszt konserwatywnego zbierania śmieci. Department of Computer Science, University of Colorado Boulder , 22 stycznia 1993, dostęp 18 listopada 2012 : „ Konserwatywne wywóz śmieci nie jest bez kosztów. W mierzonych programach algorytm zbierania śmieci wykorzystywał o 30–150 procent więcej przestrzeni adresowej niż najbardziej wydajny algorytm zarządzania jawnego. Ponadto konserwatywny algorytm zbierania elementów bezużytecznych znacznie ograniczył lokalizację referencyjną programów, znacznie zwiększając współczynnik błędów strony i współczynnik chybienia pamięci podręcznej aplikacji dla szerokiego zakresu wielkości pamięci podręcznej i pamięci. Wynik ten sugeruje, że konserwatywny algorytm zbierania śmieci nie tylko zwiększa rozmiar przestrzeni adresowej, ale także często odwołuje się do całej wymaganej przestrzeni. "
  9. ↑ Skanowanie root w czasie stałym w celu deterministycznego zbierania śmieci (PDF; 375 kB): Odśmiecanie [...] zazwyczaj wnosi wysoki stopień niedeterminizmu do środowiska wykonawczego.
  10. ^ Zbieranie śmieci dla systemów równoległych i rozproszonych , Frank Joachim Frey, 7 maja 2002
  11. ↑ Josuah Bloch: Skuteczna Java, s. 31: Unikaj finalizatorów
  12. ↑ Przegląd Objective-C 2.0 ( Pamiątka z 24 lipca 2010 w Internet Archive )
  13. ↑ Mac OS X 10.7 Lion: recenzja Ars Technica John Siracusa (20 lipca 2011)
  14. ↑ Rob Napier, Mugunth Kumar: Programowanie iOS 6 przekraczające granice . John Wiley & Sons, 20 listopada 2012, dostęp 30 marca 2015 (w języku angielskim): " " ARC nie jest garbage collection [...] to sprawia, że ​​kod zachowuje się tak, jak chciał tego programista, ale bez dodatkowego garbage collection Pamięć jest odzyskiwana szybciej niż w przypadku wyrzucania elementów bezużytecznych, a decyzje są podejmowane w czasie kompilacji, a nie w czasie wykonywania, co ogólnie poprawia ogólną wydajność. "
  15. ↑ Zarządzanie pamięcią
  16. ^ ARC kontra GC
  17. ^ Zespół Clang: AutomaticReferenceCounting. W: Klang 3.7. Dokumentacja. Źródło 31 maja 2015 : „Nie zapewnia kolektora cykli; Użytkownicy muszą jawnie zarządzać czasem życia swoich obiektów, przerywając cykle ręcznie lub za pomocą słabych lub niebezpiecznych odwołań.”
  18. ↑ Developer Tools Kickoff – sesja 300. In: WWDC 2011. Apple, Inc. , 24 czerwca 2011 r., dostęp 27 marca 2015 r. (w języku angielskim): „” Na szczycie listy życzeń, co możemy dla Ciebie zrobić, jest przyniesienie zbieranie śmieci na iOS. I to jest dokładnie to, czego nie zamierzamy robić... Niestety odśmiecanie ma nieoptymalny wpływ na wydajność. Śmieci mogą gromadzić się w twoich aplikacjach i zwiększać wysoki wskaźnik zużycia pamięci. Kolekcjoner ma tendencję do włączania się w nieokreślonych momentach, co może prowadzić do bardzo wysokiego użycia procesora i zacinania się w doświadczeniu użytkownika. I właśnie dlatego GC nie jest dla nas akceptowana na naszych platformach mobilnych. Dla porównania, ręczne zarządzanie pamięcią z zachowaniem / zwolnieniem jest trudniejsze do nauczenia i szczerze mówiąc jest to trochę upierdliwe. Ale zapewnia lepszą i bardziej przewidywalną wydajność, dlatego wybraliśmy ją jako podstawę naszej strategii zarządzania pamięcią. Ponieważ w prawdziwym świecie dla naszych użytkowników liczy się wysoka wydajność i niezacinające się wrażenia użytkowników.”
  19. ↑ José RC Cruz: Automatyczne liczenie referencji w systemie iOS. (Nie jest już dostępny online.) Dr. Dobbs 22 maja 2012 roku; zarchiwizowane z oryginałem na 16 sierpnia 2012 roku ; uzyskano dostęp 30 marca 2015 r. (w języku angielskim): „” Wreszcie, usługa [Zbieranie śmieci] nadal ponosi spadek wydajności, mimo że jest konserwatywna. To jeden z powodów, dla których garbage collection jest nieobecne w iOS […] ARC to innowacyjne podejście, które ma wiele zalet garbage collection, ale bez kosztów wydajności. Wewnętrznie ARC nie jest usługą uruchomieniową. W rzeczywistości jest to deterministyczna dwuczęściowa faza zapewniana przez nowy interfejs clang. ”” Informacje: Link do archiwum został automatycznie wstawiony i nie został jeszcze sprawdzony. Sprawdź link do oryginału i archiwum zgodnie z instrukcjami, a następnie usuń to powiadomienie. @1@2Szablon: Webachiv / IABot / www.drdobbs.com
  20. ↑ Felix Disselhoff: Tylko 1 GB RAM?! Dlaczego iPhone 6 zostawia w tyle androidy. curved.de, 17 listopada 2014 r., dostęp 22 września 2018 r .: „Dlaczego iPhone z tylko 1 GB pamięci RAM jest szybszy niż konkurencja z Androidem z 2 lub 3 GB pamięci RAM? Wyjaśnienie jest proste i dotyczy „śmieci”. [...] Android potrzebuje wielokrotności używanej pamięci”
  21. ↑ Oliver Haslam: Dlaczego iPhone z 1 GB pamięci RAM działa lepiej niż urządzenia z Androidem z 2 GB lub więcej pamięci RAM? redmondpie.com, 16 listopada 2014, dostęp 25 marca 2015 .
  22. ↑ Precious Silva: iOS 8 kontra Android 5.0 Lollipop: Apple zabija Google wydajnością pamięci. (Nie jest już dostępny online.) International Business Times , 18 listopada 2014, zarchiwizowane od oryginału 3 kwietnia 2015 ; udostępniono 7 kwietnia 2015 r . Info: Link do archiwum został wstawiony automatycznie i nie został jeszcze sprawdzony. Sprawdź link do oryginału i archiwum zgodnie z instrukcjami, a następnie usuń to powiadomienie. @1@2Szablon: Webachiv / IABot / au.ibtimes.com