Ciò che dà a Smalltalk la capacità di persistenza dell'immagine, e perché le lingue come Ruby/Python non possono essere serializzate?

Question

In smalltalk, è possibile salvare lo stato del mondo in un file immagine. Presumo che questo abbia a che fare con l'abilità di Smalltalk di "serializzare" se stessa - cioè, gli oggetti possono produrre il proprio codice sorgente.

1) È una comprensione accurata?

2) Qual è la sfida nell'aggiungere questa capacità ai linguaggi moderni (non chiaro, ovviamente)?

3) La "serializzazione" è la parola giusta? Qual è il gergo corretto?

Answer 1

È molto più semplice della "serializzazione". Un'immagine Smalltalk è semplicemente un'istantanea della memoria dell'oggetto. Prende l'intero contenuto della RAM (dopo la raccolta dei dati inutili) e lo riversa in un file. All'avvio, carica quell'istantanea dal disco nella RAM e continua l'elaborazione da dove era stata interrotta. Ci sono alcuni ganci per eseguire azioni speciali su istantanee e quando si riprende, ma in pratica è così che funziona.

(aggiunto: vedi il commento di Lukas Renggli sotto per una scelta progettuale fondamentale che lo rende così semplice rispetto ad altri ambienti)

Answer 2

Questo accade già in un modo quando si mette il computer in stop, giusto? Il kernel scrive i programmi in esecuzione sul disco e li carica di nuovo in seguito? Presumibilmente il kernel potrebbe spostare un programma in esecuzione su una nuova macchina su una rete, assumendo la stessa architettura dall'altra parte? Java può serializzare tutti gli oggetti anche a causa della JVM, giusto? Forse l'ostacolo è solo l'architettura che implica vari layout di memoria?

Modifica: Ma suppongo che tu sia interessato a utilizzare questa funzionalità dal programma stesso. Quindi penso che sia solo questione di implementare la funzione nell'interprete Python/Ruby e stdlib, e di avere una sorta di macchina virtuale se si vuole essere in grado di spostarsi su una diversa architettura hardware.

Answer 3

Estendere l'eccellente risposta di Bert Freudenberg.

1) È questa (cioè la capacità dell'oggetto di serializzare il proprio codice sorgente) una comprensione accurata?

No. Come ha sottolineato Bert, un'immagine di Smalltalk è semplicemente un'istantanea di memoria. La singola fonte di verità di entrambi gli oggetti Smalltalk e Smalltalk è la loro rappresentazione in memoria. Questa è un'enorme differenza rispetto ad altre lingue, dove i programmi sono rappresentati come file di testo.

2) Qual è la sfida nell'aggiungere questa capacità ai linguaggi moderni (non chiaro, ovviamente)?

Tecnicamente, il bootstrap di un'applicazione da un'istantanea di memoria dovrebbe essere possibile per la maggior parte delle lingue. Se non sbaglio ci sono soluzioni che utilizzano questo approccio per accelerare i tempi di avvio per le applicazioni Java. Dovresti essere d'accordo su una rappresentazione di memoria canonica e avresti bisogno di fare attenzione a reinizializzare le risorse native al riavvio del programma. Ad esempio, in Smalltalk, vengono riaperti i file aperti e la connessione di rete. E inoltre, c'è un hook di avvio per correggere l'endianità dei numeri.

3) La "serializzazione" è la parola giusta? Qual è il gergo corretto?

Hibernation è il termine.

Answer 4

La differenza fondamentale è che Smalltalk tratta il programma come un mucchio di oggetti. E IDE è solo un gruppo di editor che modifica quegli oggetti, quindi quando salvi, carica l'immagine, tutto il tuo codice è lì come quando te ne sei andato.

Per altri linguaggi potrebbe essere possibile farlo, ma suppongo che ci sarebbe più giocherellando, a seconda di quanta riflessione ci sia. Nella maggior parte degli altri linguaggi, la riflessione arriva come add-on, o anche ripensata, ma in Smalltalk è nel cuore del sistema.