Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Garbage Collector w ruby

Sponsored · Ship Features Fearlessly Turn features on and off without deploys. Used by thousands of Ruby developers. →

Garbage Collector w ruby

Presentation about garbage colector in Polish

Avatar for CucumisSativus

CucumisSativus

November 20, 2014

More Decks by CucumisSativus

Other Decks in Programming

Transcript

  1. Agenda • Pamięci w ruby • Różnice między wersjami •

    Garbage collector w ruby-2.1 • Garbage collector w ruby-2.2
  2. Pamięć w ruby • Każda struktura może zostać rzutowana (cast)

    na typ RBasic struct RClass { struct RBasic basic; struct st_table *iv_tbl; struct st_table *m_tbl; VALUE super; }; struct RFloat { struct RBasic basic; double value; };
  3. Pamięć w ruby typedef struct RVALUE { union { struct

    { VALUE flags; struct RVALUE *next; } free; struct RBasic basic; struct RObject object; struct RClass klass; (…) } https://github.com/ruby/ruby/blob/ruby_1_9_3/gc.c#L280 Podstawowa komórka pamięci w ruby można nią reprezentować dowolną strukturę Ruby struktura free GC::INTERNAL_CONSTANTS[:RVALUE_SIZE]
  4. static struct heaps_slot { void *membase; RVALUE *slot; int limit;

    } *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
  5. Ruby heap struct { VALUE flags; struct RVALUE *next; }

    free; http://izumi.plan99.net/blog/index.php/2007/10/12/ how-the-ruby-heap-is-implemented/
  6. Garbage Collector Mark and sweep • obiekty nie są usuwanie

    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
  7. Mark Obiekt 1 Obiekt 2 Obiekt 3 Obiekt 4 Przed

    fazą mark Obiekt 1 Obiekt 2 Obiekt 3 Obiekt 4 Po fazie mark potrzebne obiekty zaznaczone
  8. Problemy z mark and sweep • podczas fazy mark wykonywanie

    programu musi być zawieszone • GC przegląda całą zarezerwowaną pamięć - może to być czasochłonne
  9. ruby 1.8 • Klasyczny mark and sweep • GC jest

    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/
  10. ruby 1.9.3 LazySweepGC • Wykonywanie programu zatrzymywanie jest tylko podczas

    fazy mark • Faza sweep wykonywana jest w częściach, wraz ze wzrostem zapotrzebowania na miejsce http://tmm1.net/ruby21-rgengc/
  11. ruby 2.0 BitmapMarking GC • Faza mark została przepisana, nie

    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/
  12. ruby 2.1 założenia • obiekty zwykle żyją szybko i umierają

    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
  13. ruby 2.1 minor mark i major mark • major mark

    sprawdza wszystkie obiekty • minor mark sprawdza tylko młode obiekty • jeżeli obiekt zostaje zachowany po minor mark staje się „stary”
  14. ruby 2.1 minor mark i major mark - problemy •

    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
  15. ruby 2.1 write-barrier • Dookoła każdego obiektu tworzona jest write-barrier

    • 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
  16. ruby 2.1 write-barrier problemy • problem z kompatybilnością rozszerzeń napisanych

    C • jeżeli korzystają z bezpośredniego dostępu do pamięci, zamiast z makr przygotowanych przez twórców ruby
  17. ruby 2.1 write-barrier rozwiązanie problemu • obiekty klasyfikowane są jako

    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
  18. ruby 2.1 obiekty shady • wszystkie obiekty, które nie są

    otoczone przez write-barrier • obiekty sunny mogą stać się shady, kiedy Ruby Virtual Machine zauważy bezpośredni dostęp do pamieci
  19. ruby 2.1 podsumowanie • Podział fazy mark na minor i

    major mark • faza minor mark sprawdza tylko nowe obiekty • write barrier pozwala na zachowanie kompatybilności z rozszerzeniami napisanymi w c
  20. ruby 2.2 RincGC • Wszystko to samo co w ruby

    2.1 • Faza major mark podzielona na mniejsze części • Minor mark pozostawiona bez zmian • Łączny czas spędzony na fazie major mark zostaje taki sam
  21. ruby 2.2 Tri-color GC • Każdy z obiektów ma jeden

    z trzech kolorów • Czarny - obiekt zaznaczony • Szary - obiekty zaznaczające • Biały - obiekty niezaznaczone
  22. ruby 2.2 Symbol GC • Garbage collector nie usuwa wszystkich

    symboli • 2 rodzaje symboli immortal symbol, mortal symbol • immoral symbol nigdy nie jest usuwany przez garbage collector
  23. ruby 2.2 immortal symbol • ma własne ID • używany

    do metod, nazw zmiennych, nazw stałych itp. • nigdy nie zbierany przez garbage collector • nigdy nie zostanie mortal symbolem
  24. ruby 2.2 mortal symbol • nie ma ID • "bar".to_sym

    • zbierany przez garbage collector • może zostać immortal symbolem
  25. ruby 2.2 podsumowanie • faza major mark rozbita na mniejsze

    części • zmniejsza czas pauzy, ale nie zmniejsza łącznego czasu fazy • symbole podzielone na mortal i immortal • symbole mortal są usuwane przez garbage collector