GoDev

Blog programisty.

Garbage Collector - Wysypisko śmieci.


Artykuł ten jest częścią serii arykułów na temat Garbage Collector-a.

Wysypisko śmieci. Wysypisko śmieci.

Sprawdzanie kiedy sąsiad wyrzuca śmieci. Sprawdzanie kiedy sąsiad wyrzuca śmieci.

„Prawdziwy programista sam” wyrzuca śmieci. „Prawdziwy programista sam” wyrzuca śmieci.

Może by tak jednak zostawić bajzel i wyjechać w Bieszczady. Może by tak jednak zostawić bajzel i wyjechać w Bieszczady…


Garbage Collector

Nasz wspaniały język C#, znosi z nas prawie pełną odpowiedzialność za sprzątanie po sobie.

Można by rzec, iż mamy zatrudnioną sprzątaczkę i nawet nie wiemy, kiedy magicznie bałagan znika. Oczywiści mowa tutaj o Garbage Collector.

Jeszcze dzisiaj pamiętam trudność, i obowiązek kontrolowania wycieków pamięci, gdy pisałem oprogramowanie z wykorzystaniem języka C++.

Z drugiej strony człowiek był bardziej odpowiedzialny za to co się działo w kodzie.

Teraz w dobie ogromnych pamięci RAM, GC, często można  zapomnieć o wyciekach pamięci.

Działanie

Garbage Collector Alokowanie pamięci odbywa się niejako w dwóch miejscach:

  • na stosie (Stack) - zarządzaniem zajmuje się CLR (Common Language Runtime), i zawiera referencje do faktycznie utworzonych obiektów na stercie,
  • na sterta (Heap) -  zarządzaniem zajmuje się GC.

Śmietnik działa  bardzo sprytnie, w pierwszej fazie (Mark) znakuje obiekty jakie są używane -> istnieją powiązane z obiektem referencje (Stack -> Heap),  po czym  zaznacza je.

Tak oznaczone obiekty nie zostaną usunięte w fazie drugiej (Sweep).

Tym sposobem dochodzimy do nazwy stosowanego w GC algorytmu -> Mark & Sweep.

Aplikacje składają  się z wielu obiektów, i proces czyszczenia może trwać dość długo, zależnie od ilości obiektów. Dlatego nie jest on często uruchamiany.

Automatyczne wyzwoleni GC następuje w sytuacji gdy zostanie przekroczony pewien zakres pamięci.

Generacje

GC kategoryzuje obiekty według ich wieku powstania, tym samym przydzielane są do odpowiednich pokoleń oznaczanych odpowiednio 0, 1, 2.

Zmiana pokolenia następuje podczas uruchomienia GC, awans w pokoleniu następuje gdy obiekt nie nadaje się do zniszczenia.

Garbage Collector Jeżeli obiekt jest potrzebny i są do niego powiązane referencje ze stosu na stertę to wówczas jest on ważny i podbijana jest jego ranka od 0 do 2.

Do generacji przydzielany jest budżet, dla 0 przyjmuje się wielkość 256 KB, w przypadku przekroczenia podczas  alokowanie nowego obiektu następuje uruchomienie czyszczenia na generacji 0, w tym czasie istnieje duża szansa, iż część obiektów nadaje się do zniszczenia lub awansu na wyższe pokolenie.

Po przeczyszczeniu następuje ponowna próba alokacji jeżeli się nie powiedzie to automatycznie obiekt awansuje do wyższej generacji.

Generacja zerowa jest miejscem gdzie obiekty są najczęściej tworzone i niszczone, dlatego też jej wielkość 256 KB, jest obszarem, który powinien z łatwością zmieścić się w pamięci  L2 - cache procesora.

C.D.N.


UWAGA ZABAWA Z GARBAGE COLLECTORem NIESIE ZE SOBĄ POWAŻNE SKUTKI.

ZWŁASZCZA GDY SIĘ TO ROBI W ZŁY SPOSÓB! NIE JEST TO SILVER-BULLET NA KAŻDY PROBLEM.

I NALEŻY UWAŻAĆ. GDYŻ MOŻNA WIĘCEJ NAPSUĆ NIŻ NAPRAWIĆ;).


Referencje:


Daj Się Poznać 2017

Jest to post przygotowany na potrzeby konkursu „Daj Się Poznać 2017” organizowanym przez Macieja Aniserowicza.

Blog http://godev.gemustudio.com
Projekt http://godev.gemustudio.com/pictogr-pomysl
GitHub github.com/krzysztofowsiany/pictogr
Snapchat www.snapchat.com/add/gocom7
Facebook www.facebook.com/PictOgr-1729700930654225
Twitter twitter.com/gemu_gocom
RSS http://godev.gemustudio.com/category/daj-sie-poznac-2017/feed