In informatica la macchina virtuale Java (detta anche Java Virtual Machine o JVM) è il componente della piattaforma Java responsabile per l'esecuzione dei programmi in formato bytecode.

Tipicamente un programma in formato bytecode può essere ottenuto dalla compilazione di un programma equivalente in un linguaggio di programmazione di livello più alto. Tra i vari che possono essere tradotti in Java bytecode figurano Java, Groovy, Clojure, Scala, Kotlin.^[1]

La JVM è definita da una specifica, mantenuta da Oracle. Qualsiasi sistema che si comporti in modo coerente con tale specifica viene considerato come una particolare implementazione della JVM. Esistono implementazioni software per praticamente tutti i sistemi operativi moderni, sia gratuite che commerciali. Inoltre, esistono implementazioni speciali per particolari ambienti hardware/software, come telefoni cellulari e palmari), e persino implementazioni hardware come Jazelle.

La disponibilità di implementazioni della macchina virtuale Java per diversi ambienti operativi è la chiave della portabilità di Java, proclamata nello slogan write once, run everywhere ("scrivi una volta, esegui dappertutto"). La macchina virtuale realizza infatti un ambiente di esecuzione omogeneo, che nasconde al software Java (e quindi al programmatore) qualsiasi specificità del sistema operativo sottostante:

L'architettura di una JVM comprende in generale i seguenti elementi:

• Un set di istruzioni per i bytecode
• Un gruppo di registri
• Uno stack
• Un'area di heap su cui opera la routine di garbage collection
• Un'area per la memorizzazione dei metodi

Lo stesso argomento in dettaglio: Bytecode.

Il codice sorgente di Java viene compilato in bytecode e memorizzato in file con estensione .class. Per compilare tale codice viene fornito uno strumento che prende il nome di Javac. Questo strumento non viene considerato come un compilatore tradizionale proprio perché traduce il codice sorgente in bytecode. Il codice, a causa del formato, non può essere eseguito direttamente ma deve essere interpretato su ciascun computer. L'estrema portabilità e flessibilità del codice Java sono date, appunto, da questo passaggio intermedio.

Un'istruzione di bytecode è composta da un opcode di un byte, che serve per identificare l'istruzione in questione, e da zero o più operandi, ciascuno dei quali può essere più lungo di un byte. Quando gli operandi sono più lunghi di un byte, viene memorizzato per primo il big-endian (byte di ordine superiore), questi operandi vengono poi assemblati dal flusso di byte in fase di esecuzione. Ad esempio, un parametro a 16 bit viene rappresentato all'interno del flusso di istruzioni da due byte. Il set di istruzioni della macchina virtuale di Java interpreta i dati nelle aree di memoria di esecuzione come appartenenti a un insieme prefissato di tipi: i tipi primitivi, che sono rappresentati da diversi tipi interi con segno (byte, short, int, long), un tipo intero senza segno (char), due tipi in virgola mobile (float e double) e in più il tipo che fa riferimento a un oggetto (puntatore a 32 bit).

Lo stesso argomento in dettaglio: Registro (informatica).

I registri della JVM sono affini ai registri che si trovano in un computer reale, essi contengono lo stato in cui si trova la macchina durante le operazioni, influiscono sul funzionamento di quest'ultima e vengono aggiornati dopo l'esecuzione di ciascun bytecode.

La macchina virtuale Java include i seguenti registri:

• pc - il program counter, indica il bytecode che sta per essere eseguito.
• vars - un puntatore alla prima variabile locale del metodo attualmente in esecuzione.
• frame - un puntatore all'ambiente di esecuzione del metodo corrente in esecuzione.
• optop - un puntatore al vertice dello stack degli operandi, è utilizzato per valutare tutte le espressioni aritmetiche.

L'ampiezza con cui Java definisce questi registri è di 32 bit. Essendo basata sullo stack, la macchina virtuale non fa alcun uso di registri per il passaggio o l'acquisizione di argomenti; ciò che ha portato i programmatori ad optare per questa scelta è stata la semplicità e la compattezza dei bytecode che favoriscono l'implementazione della macchina virtuale su architetture con pochi registri.

Lo stack, che è alla base del funzionamento della macchina virtuale Java, viene utilizzato per passare i parametri alle istruzioni che vengono man mano eseguite e per ricevere i risultati da queste prodotti. Un frame dello stack di Java è affine a un frame dello stack di un convenzionale linguaggio di programmazione. Ogni frame contiene le informazioni associate ad una delle chiamate a metodo "impilate" sullo stack.

Ogni frame dello stack possiede tre aree (che potrebbero essere anche vuote):

• Le variabili locali per la chiamata al metodo
• L'ambiente di esecuzione del metodo stesso
• Lo stack degli operandi

Non si confonda lo stack delle chiamate a metodo con lo stack degli operandi. Quest'ultimo funziona in modo autonomo rispetto all'altro. L'unica correlazione che corre tra i due è che il secondo viene gestito in una area di memoria interna ai frames che sono presenti nel primo. Molto semplicisticamente, potremmo dire che abbiamo a che fare con uno stack nello stack.

Con il termine heap si fa riferimento a quel sito della memoria nella quale vengono allocati gli oggetti appena creati. Al momento dell'avvio della JVM, una certa area di memoria (più ampia o ridotta a seconda dell'implementazione della macchina virtuale) viene spesso assegnata allo heap. Alcune implementazioni assegnano fin dall'avvio una ampia quantità di memoria allo heap, tenendo tale quantità costante per tutta l'esecuzione del programma; altre permettono a quest'area di espandersi fin dove concesso dall'ambiente di esecuzione (tra i fattori che influenzano questa quantità ci sono le impostazioni del sistema operativo e la disponibilità effettiva di memoria sulla macchina che sta eseguendo il programma). Il Garbage collector è deputato alla rimozione degli oggetti non più utilizzati dal programma man mano che questo è in esecuzione. Ciò consente ai programmatori di svincolarsi dal compito di liberare "manualmente" (inserendo apposite istruzioni nel codice sorgente) la memoria allocata per un oggetto quando quest'ultimo ha esaurito la sua funzione nel programma. Tale compito è addirittura obbligatorio in linguaggi come il C++. In effetti, il garbage collector è stato progettato proprio per evitare a run-time quegli errori che derivano dalla mancata deallocazione di memoria non più utilizzata o dal tentativo di deallocare memoria ancora in uso dal programma.

L'area di memorizzazione dei metodi contiene le tabelle dei simboli necessari per il link dinamico, informazioni di debug aggiuntive, ambienti di sviluppo da associare all'implementazione di qualsiasi metodo e i bytecode di Java che implementano tutti i metodi presenti nel sistema. Poiché i bytecode vengono memorizzati come flusso di byte, l'area dei metodi è allineata per byte mentre le altre aree sono allineate a parole di 32 bit.

Lo stesso argomento in dettaglio: Compilatore just-in-time.

Le prime implementazioni della macchina virtuale Java erano interpreti. Questa soluzione si è però rivelata poco efficiente, in quanto i programmi interpretati erano comunque molto lenti. Per questo motivo, tutte le implementazioni recenti di macchine virtuali Java hanno incorporato un compilatore just-in-time (JIT compiler), cioè un compilatore interno, che al momento del lancio traduce al volo il programma bytecode Java in un normale programma nel linguaggio macchina del computer ospite^[2]. Inoltre, questa ricompilazione è dinamica, cioè la macchina virtuale analizza costantemente il modello di esecuzione del codice (profilattico), e ottimizza ulteriormente le parti più frequentemente eseguite, mentre il programma è in esecuzione.

Questi accorgimenti, a prezzo di una piccola attesa in fase di lancio del programma, permettono di avere delle applicazioni Java decisamente più veloci e leggere. Tuttavia, anche così Java resta un linguaggio meno efficiente dei linguaggi propriamente compilati come il C++, scontando il fatto di possedere degli strati di astrazione in più, e di implementare una serie di automatismi, come il garbage collector, che se da un lato fanno risparmiare tempo ed errori in fase di sviluppo dei programmi, dall'altro consumano memoria e tempo di CPU in fase di esecuzione del programma finito.

Lo stesso argomento in dettaglio: HotSpot.

HotSpot, ufficialmente nota come Java HotSpot Performance Engine^[3] è l'implementazione di riferimento della JVM, realizzata originariamente da Sun Microsystems e successivamente gestita da Oracle Corporation.

Dal 2006, con la creazione di OpenJDK, HotSpot è software libero.^[4]

Per sostituire le parti di OpenJDK che erano sotto licenza non open, è nato il progetto IcedTea.^[5] La macchina virtuale sviluppata in tale progetto si chiama HotSpot Zero Assembly, chiamata anche semplicemente Zero.^[6] Il progetto ha anche lo scopo di supportare un numero maggiore di famiglie di processori rispetto alla macchina virtuale di Oracle. Per fare ciò, tutto il codice assembly presente in HotSpot è stato riscritto in C++, in modo da poter essere compilato su più architetture.^[7]

Eclipse OpenJ9 (precedentemente conosciuta come IBM J9) è un'implementazione scalabile e ad alte performance della JVM, pienamente conforme alla Java Virtual Machine Specification.^[8]

È parte di varie distribuzioni di OpenJDK, tra cui IBM Semeru.^[9]

Rispetto a HotSpot, OpenJ9 presenta prestazioni migliori in fase di avvio e un minore utilizzo di memoria a livelli di produttività simili.^[10]

Numerose altre parti forniscono regolarmente implementazioni della macchina virtuale Java, in genere con l'intento di competere con l'implementazione Oracle in quanto a prestazioni; in alcuni casi si tratta di implementazioni commerciali. Sono disponibili anche altre implementazioni open source; fra le più note si può citare Waba^[11]. Le specifiche della JVM vengono dettate e aggiornate dalla Oracle in quanto iniziatore e mantenitore del progetto, ma vengono spesso disattese da molte delle implementazioni non-Oracle di JVM che sono in circolazione, soprattutto per quanto riguarda il framework che ogni JVM include. Di conseguenza, le diverse JVM non sono totalmente compatibili tra loro ed occorre fare attenzione nello scrivere i programmi, se si vuole che essi funzionino su ogni JVM. La cosa migliore da fare a tale scopo sarebbe non usare le ultime caratteristiche del linguaggio introdotte dalla Oracle nelle JVM più recenti e usare delle API "stabili", che cioè siano presenti nella JVM Oracle da varie versioni.

• Ensemble Modo Antiquo., La musica dei crociati., Amadeus DARP, 2000. URL consultato il 22 settembre 2022.
• (EN) Tim Lindholm, Frank Yellin, Gilad Bracha, Alex Buckley, Java Virtual Machine Specification, Java SE 8 Edition, 2014. URL consultato il 3 ottobre 2014.
• (EN) Seth Sachin, Understanding Java virtual machine^{[collegamento interrotto]}, Alpha Science International Ltd, 2013. URL consultato il 3 ottobre 2014.

• Piattaforma Java
• Macchina virtuale
• NanoVM
• IJVM

• Wikimedia Commons contiene immagini o altri file sulla macchina virtuale Java

• (EN) Denis Howe, Java Virtual Machine, in Free On-line Dictionary of Computing. Disponibile con licenza GFDL

Portale Informatica: accedi alle voci di Teknopedia che trattano di Informatica