Scrittura di un gestore di memoria in una lingua gestita?

Question

Jikes RVM, un runtime java metacircolare, sembra avere il suo Allocator/Collector scritto in Java (MMTK).

Come funziona, quindi, quando il garbage collector richiede l'esecuzione di un garbage collector? Dall'osservazione del codice, non ho visto MMTK limitarsi ad alcun sottoinsieme particolare di Java, ma mi sembra che se il codice che è destinato ad allocare la memoria gestita è necessario allocare la memoria gestita per l'esecuzione, sta andando in un rotazione ricorsiva fino a quando non esplode.

Ma chiaramente MMTK funziona, e sembra che anche altri progetti lo utilizzino. Come è possibile scrivere un allocatore di memoria e GC in un linguaggio gestito come Java?

Answer 1

Ci sono parecchi casi in cui questo viene fatto. Non ho familiarità con l'implementazione di Jikes, ma ho letto sia su progetti basati su Java che su PyPy. La cosa che la maggior parte di loro ha in comune è la separazione delle cose in due livelli: livello runtime/interprete e livello applicazione. Ogni livello ha i propri oggetti, eccezioni, flusso di esecuzione, ecc.

Quando ci si pensa in modo astratto, in realtà è più facile da capire. Il livello di runtime potrebbe essere stato scritto in memoria o meno, a basso livello o ad alto livello, imperativo o funzionale. Questo non importa. Ciò che conta è la sua funzione, quello che fa. Alla fine viene tradotto in codice macchina e tutto il codice macchina è lo stesso di una macchina. Tale codice accetta opcode e dati come input, esegue azioni predefinite basate su tale, gestisce le risorse, ecc.

Il livello applicazione è contenuto in questi codici opzionali. Il livello dell'applicazione rappresenta un'altra funzione complessiva che accetta l'input, lo elabora ed esegue l'output. Questi passaggi potrebbero anche incorporare una routine di gestione della memoria. Il runtime non si preoccupa di ciò che fanno gli opcode finché sono validi e li esegue semplicemente. In teoria, puoi scrivere una lingua GC che contiene un linguaggio GC che contiene un linguaggio GC ... e così via fino a quando non raggiungi velocità ENIAC. ;)

Direi che il differenziatore in design come Jikes è la loro efficienza (e talvolta flessibilità). Non è sufficiente scrivere un GC, un interprete o un runtime in un linguaggio GC. Il risultato deve essere utilizzabile, il che significa spesso velocità. Potrebbe anche essere necessario adottare disposizioni per gestire l'integrazione del codice nativo a livello di applicazione. La maggior parte del vero lavoro va in quella roba. L'esecuzione di un GC in un linguaggio GC è la parte più semplice: fondamentalmente basta etichettare e gestire gli oggetti a diversi livelli di astrazione.

Nota: se si codifica il linguaggio GC e il runtime basato su GC, è possibile sfruttare questo vantaggio per prestazioni e semplicità. Ad esempio, invece di avere due interi garbage collector in esecuzione, uno sopra l'altro, puoi avere un GC più intelligente in basso con un GC sottile in cima. Il GC più intelligente conosce la differenza tra il runtime e il livello di applicazione, assicurandosi di operare su di essi separatamente e di non eseguire una miscelazione impropria. Il thin top GC essenzialmente fa semplicemente chiamate di routine al GC principale o etichetta oggetti in un modo che il GC principale comprende, ma questo non aggiunge un sacco di overhead.

La cosa su questo tipo di progetti è che ognuno è un po 'diverso. La natura del target e i linguaggi di implementazione dettano molto le scelte progettuali. Ti offre molte opportunità per essere creativo con il modo in cui risolvi il problema.

Answer 2

Quale risposta si desidera:
- "È solo un processo di bootstrap, qual è il problema?"
o
- "È magico! (Vale a dire, una tecnologia più avanzata di quella che attualmente comprende.)"

Il primo C compilatori erano scritti in, ottenere questo, C. Come è stato il primo sistema operativo scritto? Per uno che ha trascorso un pomeriggio faticosamente la creazione di una carta-tape bootstrap un tedious- bit dopo l'altro utilizzando interruttori a levetta e luci per console (su un DEC PDP-15 a 18 bit), nessuno di questi è più un mistero: uno inizia semplicemente con i pezzi più avanzati che possono essere riutilizzati e gli strumenti di costruzione di crescente complessità fino a quando il kit di strumenti è adeguato per costruire l'applicazione