} *heaps; static int heaps_length = 0; static int heaps_used = 0; Layout pamięci w ruby heap lists http://izumi.plan99.net/blog/index.php/2007/10/12/ how-the-ruby-heap-is-implemented/ Miejsce w pamięci pierwszy obiekt RVALUE ile obiektów tu wejdzie liczba obiektów na liście liczba zajętych obietków
z pamięci zaraz po zakończeniu ich życia • mark - GC identyfikuje obiekty, które są w użyciu (inne obiekty odwołują się do nich) i ustawia na nich odpowiednią flagę • sweep - GC usuwa nieużywane obiekty
odpalany kiedy ilość pamięci zajętej przez ruby osiągnie GC_MALLOC_LIMIT, domyślnie 8000000 bajtów ok. 8 mega bajtów lub kiedy liczba wolnych slotów spada do 0 http://tmm1.net/ruby21-rgengc/
jest już rekurencyjna • Zamiast bitów w każdym obiekcie występuje jedna mapa bitowa pozwala to na lepszą wymianę danych między procesami dziećmi http://tmm1.net/ruby21-rgengc/
młodo • istnieje większa szansa, że młody obiekt posiada referencję do starego niż odwrotnie • tylko niewielka liczba nowych obiektów musi być zachowana
Rozszerzenia w C mają bezpośredni dostęp do pamięci • Kiedy przychodzi minor mark nowy obiekt nie jest zaznaczany i podczas fazy sweep usuwany old_array[0] = &new_object
• Jeżeli między fazami minor mark stary obiekt dostaję referencję do nowego obiektu ustawiany jest bit w remember set • Bez tego nowy obiekt zostałby skasowany! • Schodząc na niższy poziom ( do C) - wszystkie wywołania pamięci powinny odbywać się przez zestaw makr
sunny i shady • sunny obiekty, do których nie było bezpośredniego dostępu przez wskaźniki • shady reszta • obiekty shady nigdy nie zostają promowane na stare obiekty (oldgen) - będą sprawdzane podczas każdej fazy mark
części • zmniejsza czas pauzy, ale nie zmniejsza łącznego czasu fazy • symbole podzielone na mortal i immortal • symbole mortal są usuwane przez garbage collector