Macchina virtuale per un linguaggio di programmazione di alto livello rispetto a un sistema operativo

5

Mi è sembrato di recente che una macchina virtuale per un linguaggio di programmazione di alto livello sia molto simile a un sistema operativo. Gestisce le risorse, ad es. stack, heap, ecc. simile a come un sistema operativo gestisce le risorse e se il linguaggio di programmazione supporta i thread, la macchina virtuale fa anche il time-sharing e il cambio di contesto in modo simile a come funziona un sistema operativo.

Fino a dove può essere presa questa analogia? Perché non abbiamo un'implementazione bare metal della JVM? Sembra che tutti i pezzi ci siano, quindi qual è esattamente la ragione per cui tali cose non sono più prevalenti?

    
posta davidk01 08.03.2014 - 01:47
fonte

6 risposte

4

Quanto lontano può essere preso?

Abbastanza lontano. Potresti voler controllare jnode (Sforzo di progettazione del nuovo sistema operativo Java) ( github repo ) che è un'implementazione full metal della JVM. Solo circa 500k di assembly, come un "nano-kernel", utilizzato nel processo di avvio. Una volta che il sistema operativo è in esecuzione, tutto il codice in esecuzione è in realtà java.

Perché non abbiamo un'implementazione bare metal della JVM?

Un sacco di cose che gli sviluppatori JVM sono abituati a pensare come "appena là" sono effettivamente supportate dal sistema operativo sottostante e la JVM utilizza solo la risorsa del sistema operativo. Esempio: I driver di periferica. Se osservi il codice jnode sopra, scoprirai che è in corso un impegno costante nella creazione di driver di dispositivo. Devono essere scritti in java, che non vedrai mai da nessun'altra parte.

    
risposta data 08.03.2014 - 06:18
fonte
7

Esistono macchine "bare metal" basate su macchine virtuali. Più recentemente, ci sono stati vari tentativi in un Processore Java che avrebbe eseguito una JVM (beh, JM dal momento che non è virtuale) in hardware. Esse esistono, anche se non in macchine per uso generico che usiamo, sono più riconducibili all'idea incorporata originaria dalla quale è nato Java.

Questo richiama la macchina Lisp che si è avvicinata al design della CPU, invece con istruzioni di alto livello nella CPU stessa.

Il motivo è che ... non si ottiene molto dalla specializzazione a livello hardware ... e la direzione della ricerca è stata per insiemi di istruzioni più piccoli con più core piuttosto che cercare di formulare istruzioni complesse. È qui che il denaro è stato inseguito e questo è il motivo per cui le persone stanno esplorando quel percorso di più.

La domanda da prendere in considerazione - sta restringendo i programmi disponibili che il sistema può eseguire vale il costo dell'investimento per creare un tale sistema. Inoltre, man mano che i processori generici diventano più veloci, puoi tenere il passo con un'alternativa valida?

... cheaper desktop PCs soon were able to run Lisp programs even faster than Lisp machines, without the use of special purpose hardware. Their high profit margin hardware business eliminated, most Lisp Machine manufacturers went out of business by the early 90s ...

Da Wikipedia sulla macchina Lisp.

Si noti l'ultima sezione sugli altri computer ottimizzati per la lingua che include i suddetti processori Java. Semplicemente non sono stati commercialmente fattibili nella maggior parte delle situazioni (e nessuno di loro per una macchina generica).

    
risposta data 08.03.2014 - 03:00
fonte
3

Le JVM bare metal esistono (forse?) esistono, ma non sono mai state ridimensionate in termini di volume per finanziare abbastanza sviluppo R & D per tenere il passo con implementazioni di processori mainstream ad alto volume. Un x86 (in un processo di piccolo nanometro) o ARM finisce per far funzionare una JVM più veloce ed economica e usando meno energia di una JVM personalizzata di multi-Moores-law-generation-behind (quindi, in grande nanometro o micron). E attualmente ci vogliono da decine di milioni a miliardi per tenere il passo.

La stessa cosa è successa ad alcune architetture RISC non orientate al consumatore e ad alcuni DSP meno specializzati.

    
risposta data 08.03.2014 - 05:11
fonte
2

Le implementazioni hardware della JVM esistono e ci sono un numero tra cui scegliere. Tuttavia, non sono senza alcuni inconvenienti. Per uno, non è possibile aggiornare facilmente la macchina se è scritta in silicio.

    
risposta data 08.03.2014 - 03:05
fonte
1

Hai ragione che esiste una stretta relazione tra VM e sistemi operativi. C'è anche una stretta relazione tra questi due e Linguaggi di programmazione. In effetti, si potrebbe sostenere che sono più o meno la stessa cosa!

Esiste una famosa citazione di Daniel H. H. Ingalls dei Principi di design di Smalltalk: "un sistema operativo è una raccolta di routine mancante nella lingua, non dovrebbe essercene una."

Le macchine Smalltalk originali non avevano un sistema operativo, o piuttosto il sistema Smalltalk era il sistema operativo. Anche i driver video sono stati scritti in Smalltalk. Potresti anche voler esaminare il design dell'AS / 400, che è strettamente correlato a quello che stai chiedendo.

    
risposta data 08.03.2014 - 12:44
fonte
1

Solo superficialmente.

Il sistema operativo in genere non ha il lusso di eseguire analisi dettagliate statiche (compilatore o codice macchina) su qualsiasi codice eseguibile che l'utente sta per eseguire sul sistema operativo.

Mentre l'ambiente di esecuzione della lingua è in parte responsabile della compilazione del codice da una rappresentazione di livello superiore in istruzioni macchina eseguibili, quindi è in una posizione perfetta per eseguire analisi per prevenire determinati tipi di payload malformato, canaglia o jailbreaking.

D'altra parte, le soluzioni antivirus di fascia alta spesso promettono di fare questo tipo di analisi. Tuttavia, può farlo solo su una base molto selettiva.

    
risposta data 11.11.2016 - 22:42
fonte