concetto di macchina astratto di jvm

Question

Sto cercando di capire il vero vantaggio di implementare java come una macchina astratta o virtuale o in altre parole il vantaggio di compilare una lingua in una lingua per una macchina astratta. Per quanto riguarda l'indipendenza dalla piattaforma è interessato pensavo seguenti due implementazioni alternative:

• solo avere un interprete che traduce Java direttamente in codice macchina della macchina è in esecuzione su e avere più implementazioni di tale interprete per diversi tipi di macchina.

• la prima opzione non è efficiente nello spazio, quindi come compilare il codice sorgente in una lingua intermedia che non è una lingua per una macchina astratta ma solo un linguaggio che può essere interpretato come codice macchina e quindi con più implementazioni di tali interpreti.

Se le prestazioni non vengono considerate come confrontare una macchina astratta con queste opzioni. In altre parole, cosa succede se il codice byte java non è un linguaggio per una macchina virtuale ma solo un linguaggio intermedio. Quali caratteristiche e vantaggi andrebbero persi (tranne che per le prestazioni)?

Answer 1

Il codice byte è solo una lingua intermedia.

Al contrario: l'implementazione di una lingua intermedia è una macchina virtuale.

Answer 2

Se Java è stato tradotto direttamente nel codice macchina mentre viene eseguito, si perderebbero le caratteristiche di sicurezza del tipo fornite dal compilatore. Il fatto che il compilatore non segnali errori garantisce che determinati tipi di errori non possano verificarsi in runtime; se rimuovi la fase del compilatore vedresti questi errori in runtime.

D'altra parte, il bytecode Java è un linguaggio intermedio, anche se è un po 'più alto di altri. JVM lo esegue in parte interpretando e in parte compilando codice macchina.

Answer 3

Quello che descrivi è essenzialmente ciò che Java e JVM fanno attualmente. Java è compilato per qualcosa chiamato bytecode, che è un linguaggio intermedio (che sembra assomigliare molto all'assemblaggio di una macchina basata sullo stack). La JVM quindi interpreta questo codice, traducendone parti al codice macchina al volo in un processo chiamato Just In Time (JIT) compilation. La JVM fa altre cose (come gestire la concorrenza e la struttura/gestione della memoria) che aiutano nella portabilità.

Answer 4

Tutte le varianti sono effettivamente in uso nella pratica, si tratta di scegliere compromessi appropriati.

per Java - comodo per molti la distribuzione della piattaforma, tempi di avvio più lento:

• sorgente Java compilato in bytecode
• bytecode interpretato e/o
• bytecode JIT compilato in codice macchina

per JavaScript - il più conveniente per la distribuzione/molto lavoro da fare per velocizzarlo):

fonte

• JavaScript analizzato + interpretato o JIT compilato in codice macchina

per NET - AOT ha tutti i vantaggi del linguaggio VM mantenendo il tempo di avvio veloce, ma in gran parte bloccato per un obiettivo tipo di sistema:

• C#/F #/VB/... compilato IL (Intermediate Language/un'altra bytecode) codice
• .NET IL interpretato e/o
• .NET IL JIT compilato in codice macchina o
• .NET L'AOT compilato (in anticipo) (a x86 per lo più) e distribuito compilato

questo è proprio quello che è in gran parte utilizzato, ma si può compilare javascript per bytecode, java precompilare in codice macchina, puoi anche compilare Java in JavaScript come GWT, ecc. (solo che c'è molto da fare per renderlo utilizzabile)