Speichermodell in Ruby

Question

Wie Speicher in Ruby verwaltet wird. Für Beispiel: wenn wir das C-Programm während der Ausführung nehmen, ist das folgende das Speichermodell. Ähnlich wie wie Speicher in Ruby behandelt wird.

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

Ruby: 

       ? 

Answer 1

Es gibt keine "Speicher" in Ruby.

Class#allocate weist ein Objekt zu und gibt das Objekt zurück. Und das ist das ganze Ausmaß der Interaktion, die ein Programmierer mit dem Objektraum-Subsystem haben kann.

Wo das Objekt zugeordnet ist, wie es zugewiesen wird, wenn es an der gleichen Stelle im Speicher bleibt oder sich bewegt, ist nichts davon spezifiziert oder beobachtbar. Zum Beispiel kann in MagLev ein Objekt tatsächlich nicht im Speicher, sondern auf der Festplatte oder im Speicher eines anderen Computers zugewiesen werden. JRuby, IronRuby, Opal, Cardinal, MacRuby, etc. "outsourcen" ihre Speicherverwaltung an eine dritte Partei, sie wörtlich nicht einmal wissen, was mit ihrem Speicher passiert.

Eine Ruby-Implementierung kann einen separaten Stack und Heap verwenden, sie kann einen Heap-allokierten Stack verwenden, sie kann gar keinen Stack verwenden (z. B. Cardinal).

Hinweis: Das Modul ermöglicht eine eingeschränkte Introspektion und Reflexion des Objektraums. Im Allgemeinen, wenn ich sage, dass etwas in Ruby "unmöglich" ist, gibt es immer einen impliziten Vorbehalt "es sei denn, Sie verwenden Reflexion". Jedoch gibt auch ObjectSpace keine Informationen über die Organisation von Speicher. In YARV gibt es auch die objspace Bibliothek und das GC Modul, die interne Implementierungsdetails über YARV bereitstellen. Es handelt sich jedoch um private interne Implementierungsdetails von YARV, deren Existenz in anderen Implementierungen nicht einmal garantiert ist, und sie können sich jederzeit innerhalb von YARV ohne vorherige Ankündigung ändern.

Sie können feststellen, dass ich nichts über Garbage Collection geschrieben habe! Eigentlich spezifiziert Ruby nur, wann Objekte referenziert werden und wann nicht. Was zu tun ist mit nicht referenzierten Objekten, es wird nicht gesagt. Es ist sinnvoll, dass eine Implementierung den von diesen nicht referenzierten Objekten belegten Speicherplatz zurückfordert, und alle tun dies bis zu einem gewissen Grad (z. B. ältere Versionen von YARV würden nicht referenzierte Symbol s zurückfordern), aber es ist weder erforderlich noch spezifiziert. Und alle Implementierungen verwenden sehr unterschiedliche Ansätze. JRuby, IronRuby, Opal, Cardinal, MacRuby, Topaz, MagLev usw. "outsourcen" dieses Problem auf die zugrunde liegende Plattform, Rubinius verwendet einen generationellen, kopierenden, bewegten Tracing-Kollektor basierend auf dem Immix-Collector, YARV verwendet eine einfache Marke -und-funce Ablaufverfolgungssammelpunkt.