Modello di memoria in Ruby

Question

Modalità di gestione della memoria in ruby. Ad esempio: se prendiamo il programma C durante l'esecuzione, quanto segue è il modello di memoria. Simile a questo come viene gestita la memoria in ruby.

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

Ruby: 

       ? 

Answer 1

Non esiste una cosa come "memoria" in Ruby.

Class#allocate alloca un oggetto e restituisce quell'oggetto. E questa è l'intera estensione dell'interazione che un programmatore può avere con il sottosistema dello spazio degli oggetti.

Laddove l'oggetto è allocato, come viene assegnato, se rimane nello stesso posto in memoria o si muove, nessuno di questi è specificato o osservabile. Ad esempio, su MagLev, un oggetto potrebbe non essere effettivamente allocato in memoria, ma su disco o nella memoria di un altro computer. JRuby, IronRuby, Opal, Cardinal, MacRuby, ecc. "Esternalizzano" la loro gestione della memoria a terzi, loro letteralmente non sanno nemmeno cosa sta succedendo alla loro memoria.

Un'implementazione di Ruby può utilizzare uno stack e un heap separati, può utilizzare uno stack allocato all'heap, non può nemmeno utilizzare uno stack (ad esempio, Cardinal).

Nota: il modulo ObjectSpace consente una quantità limitata di introspezione e riflessione dello spazio dell'oggetto. In generale, quando dico che qualcosa è "impossibile" in Ruby, c'è sempre un avvertimento implicito "a meno che non si usi il riflesso". Tuttavia, anche ObjectSpace non perde alcuna informazione sull'organizzazione della memoria.

In YARV, c'è anche la libreria objspace e il modulo GC, che forniscono dettagli di implementazione interni su YARV. Tuttavia, sono dettagli di implementazione interna privata di YARV, non sono nemmeno garantiti per esistere in altre implementazioni e possono cambiare in qualsiasi momento senza preavviso anche all'interno di YARV.

Si noti che non ho scritto nulla sulla garbage collection! Beh, in realtà, Ruby specifica solo quando gli oggetti sono referenziati e quando non lo sono. Cosa fare con oggetti non referenziati, non dice. Ha senso che un'implementazione recuperi lo spazio utilizzato da quegli oggetti senza riferimento e tutti lo fanno in una certa misura (ad esempio versioni precedenti di YARV non reclamerebbero senza riferimento Symbol s), ma non sono richieste né specificate. E tutte le implementazioni usano approcci molto diversi. Ancora una volta, JRuby, IronRuby, Opal, Cardinal, MacRuby, Topaz, MagLev, ecc. "Esternalizzano" quel problema alla piattaforma sottostante, Rubinius utilizza un collettore generazionale, di copia, di spostamento e di tracciamento basato sul collezionista Immix, YARV usa un semplice segno - Raccoglitore di tracciatura.