Model pamięci w Ruby

Question

Sposób zarządzania pamięcią w rubinie. Dla Ex: jeśli weźmiemy program C podczas wykonywania, poniższy jest model pamięci. Podobne do tego jak pamięć jest obsługiwana w ruby.

C: 
         __________________ 
         |    | 
         |  stack  | 
         |    | 
         ------------------ 
         |    | 
         | <Un Allocated| 
         |  space> | 
         ------------------ 
         |    | 
         |    | 
         |  Heap  | 
         |    | 
         |    | 
         __________________ 
         |    | 
         |  data  | 
         __________________ 
         |  text  | 
         __________________ 

Ruby: 

       ? 

Answer 1

W Ruby nie ma czegoś takiego jak "pamięć".

Class#allocate przydziela obiekt i zwraca ten obiekt. I to jest cały zakres interakcji, jaki może mieć programista z podsystemem przestrzeni obiektowej.

Gdzie ten obiekt jest alokowany, w jaki sposób jest przydzielany, jeśli pozostaje w tym samym miejscu w pamięci lub porusza się, nic z tego nie jest określone ani możliwe do zaobserwowania. Na przykład na MagLev, obiekt może w ogóle nie zostać przydzielony w pamięci, ale na dysku lub w pamięci innego komputera. JRuby, IronRuby, Opal, Cardinal, MacRuby, itp. "Zlecają" zarządzanie pamięcią na stronę trzecią, ponieważ nie wiedzą nawet, co dzieje się z ich pamięcią.

Implementacja Rubiego może używać osobnego stosu i sterty, może używać stosu alokowanego stertami, może nawet nie używać w ogóle stosu (np. Kardynał). UWAGA: Moduł ObjectSpace pozwala na ograniczoną ilość introspekcji i odbicia przestrzeni obiektu. Ogólnie mówiąc, kiedy mówię, że coś jest "niemożliwe" w Ruby, zawsze jest ukryte zastrzeżenie "chyba że używasz refleksji". Jednak nawet ObjectSpace nie wycieka żadnych informacji o organizacji pamięci.

W YARV znajduje się także biblioteka objspace oraz moduł GC, który zawiera wewnętrzne szczegóły implementacji YARV. Są one jednak prywatnymi wewnętrznymi szczegółami implementacji YARV, nie można ich nawet zagwarantować w innych implementacjach i mogą one ulec zmianie w dowolnym momencie bez powiadomienia, nawet w YARV.

Możesz zauważyć, że nie napisałem nic o zbieraniu śmieci! Właściwie Ruby określa tylko, kiedy obiekty są przywoływane, a kiedy nie. Co zrobić, gdy z obiektami nieodniesionymi, nie mówi. Sensowne jest, aby implementacja odzyskiwała przestrzeń używaną przez te obiekty bez żadnych odwołań, a wszystkie one w pewnym stopniu (np. Starsze wersje YARV nie byłyby odzyskiwane bez odwołań Symbol s), ale nie jest to wymagane ani określone. Wszystkie wdrożenia wykorzystują bardzo różne podejścia. Ponownie, JRuby, IronRuby, Opal, Cardinal, MacRuby, Topaz, MagLev itp. "Zlecają" ten problem na platformę bazową, Rubinius używa pokoleniowego, kopiującego, poruszającego się, śledzącego kolektora opartego na kolektorze Immix, YARV używa prostego znaku -i-zbieracz śledzenia.