On-the-Fly Garbage Collection Algorytm odśmiecania jest wykonywany współbieżnie z danym programem On-the-Fly Garbage Collection Zwalnianie pamięci, do której nie ma już dostępu poprzez zmienne programu Agata Hejmej

Mark and Sweep Strategia odśmiecania: * raz na jakiś czas badane są wskaźniki w pamięci programu * zaznacza się wszystkie elementy bezpośrednio dostępne poprzez zmienne programu * rekurencyjnie zaznacza się wszystkie elementy z nich dostępne, aż nie ma żadnych nowych zaznaczeń * niezaznaczone elementy to śmieci, które się zwalnia

safety – dostępne z programu elementy pamięci nie mogą być zwalniane Najważniejsze własności odśmiecacza pamięci: safety – dostępne z programu elementy pamięci nie mogą być zwalniane liveness – wszystkie śmieci muszą być w końcu zwolnione

Algorytmy typu On-the-Fly Garbage Collector, które są bezpieczne i żywotne są trudne do zaprojektowania. Jeszcze trudniejsze jest udowodnienie poprawności ich działania! Pierwsze rozwiązanie – algorytm używający 3-kolorowego zaznaczania (Dijkstra i inni) Algorytm zbyt skomplikowany, żeby udowodnić jego bezpieczeństwo i żywotność! Główna motywacja dla Ben-Ari'ego do stworzenia algorytmu używającego 2-kolorowego zaznaczania.

mutator – reprezentuje operacje programu na pamięci Algorytm Ben-Ari'ego opisuje działanie dwóch współbieżnych procesów: mutator – reprezentuje operacje programu na pamięci collector – zajmuje się odśmiecaniem

Pamięć programu: * tablica elementów zwanych węzłami (nodes) * children – węzły na które wskazuje dany węzeł * roots – węzły, do których jest bezpośredni dostęp z programu * nil – węzeł który zawsze wskazuje na siebie (należy do roots) * free list – węzeł, który wskazuje na listę niezaalokowanych elementów (należy do roots) * marking – każdy węzeł jest oznaczony jako czarny (jest do niego dostęp) albo biały (nie ma dostępu)

Odśmiecanie jest niezależne od wartości jakie znajdują się w węzłach pamięci. Dlatego operacje mutatora na wskaźnikach mogą być zamodelowane jako pojedyncze abstrakcyjne operacje, które przekierowują wskaźnik z jednego dostępnego węzła na inny dostępny węzeł. Mutator 1. Przekierowuje wskaźnik z jednego dostępnego węzła na inny dostępny węzeł (target node). 2. Koloruje na czarno węzeł, na który teraz wskazuje wskaźnik (target node).

Collector 1. Koloruje na czarno wszystkie węzły root. 2. Bada każdy węzeł w pamięci. Jeżeli jest czarny, koloruje jego dzieci na czarno. 3. Zlicza czarne węzły. Jeśli ich ilość wzrosła od ostatniego cyklu propagacyjnego, wraca do kroku 1. 4. Bada każdy węzeł w pamięci. Jeżeli węzeł jest biały, dołącza go do free list. Jeśli jest czarny koloruje go na biało.

Po co krok drugi mutatora?

Jakie własności modelu chcemy sprawdzić? Modelowanie Algorytmu Ben-Ari'ego w CCS. Jakie własności modelu chcemy sprawdzić? Jakie akcje? Musimy wiedzieć czy węzeł jest dostępny (acc - accessible) oraz kiedy jest zwolniony (coll - collected). safety – akcja colli nie może nigdy wystąpić, jeśli akcja acci może wystąpić. liveness – akcja acci zawsze będzie mogła się wydarzyć.

Niestety! Rezultat analizy konkretnego modelu nie musi się przenosić na działanie algorytmu w ogólności. Nasza analiza może być traktowana jako dobry sposób na odkrycie możliwych problemów. Nie jest na pewno dowodem na bezpieczeństwo i żywotność Algorytmu Ben-Ari'ego!

Ze względu na ograniczenia CWB w analizie za model przyjęto: memory size = 4 roots = 2 (nil oraz free list) InitSons = (nil, 3, 4, nil) InitColors = (white, white, white, white) Otrzymany model to GC4.

GC4 Safety GC4 Liveness !

Liveness – dla każdego węzła i jest tak, że o ile collector będzie działał, to w końcu będzie mogła być wykonana akcja acci GC4 Liveness uff...!

Czy pokazanie bezpieczeństwa i żywotności naszego modelu mówi nam dużo na temat Algorytmu Ben-Ari'ego w ogólności?

Nie koniecznie! Jeśli zamieni się kolejność kroków Mutatora, nie powinna być spełniona własność Safety. A nasz model mówi, że jest! Jest tak dlatego, że rozmiar modelowanej pamięci jest za mały, co nie pozwala na uchwycenie problemu, który powstaje. (tylko 4 węzły, przy większej ich liczbie generuje się zbyt wiele stanów, by zamodelować to w CWB)