Artykuł ten jest częścią serii artykułów na temat Garbage Collector-a.
Sprawdzanie kiedy sąsiad wyrzuca śmieci.
„Prawdziwy programista sam” wyrzuca śmieci.
Może by tak jednak zostawić bajzel i wyjechać w Bieszczady…
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
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.
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:
Jest to post przygotowany na potrzeby konkursu „Daj Się Poznać 2017” organizowanym przez Macieja Aniserowicza.
| Blog | https://mrdev.pl |
| Projekt | https://mrdev.pl/pictogr-pomysl |
| GitHub | github.com/krzysztofowsiany/pictogr |
| Snapchat | www.snapchat.com/add/gocom7 |
| www.facebook.com/PictOgr-1729700930654225 | |
| twitter.com/gemu_gocom | |
| RSS | http://mrdev.pl/category/daj-sie-poznac-2017/feed |
