Macchina virtuale Java

componente della piattaforma Java responsabile per l'esecuzione dei programmi in formato bytecode
Versione del 22 lug 2006 alle 10:51 di Thijs!bot (discussione | contributi) (robot Aggiungo: he:JVM)

La macchina virtuale Java, detta anche Java Virtual Machine o JVM, è la macchina virtuale che esegue i programmi in linguaggio bytecode, ovvero i prodotti della compilazione dei sorgenti Java. La JVM è formalmente una specifica, mantenuta da Sun Microsystems. Qualsiasi sistema che si comporti in modo coerente con tale specifica sarà quindi da considerarsi una particolare implementazione della JVM. Esistono implementazioni software per praticamente tutti i sistemi operativi moderni, sia gratuite che commerciali. Inoltre, esistono implementazioni che operano in contesti hardware/software particolari, per esempio telefoni cellulari, e persino implementazioni hardware.

Le specifiche della JVM vengono dettate e aggiornate dalla Sun Microsystems in quanto iniziatore e mantenitore del progetto, ma vengono spesso disattese dalla maggioranza delle implementazioni non-sun 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 SUN nelle JVM più recenti e usare delle API "stabili" , che cioe' siano presenti nella JVM SUN da varie versioni.

Le ultime JVM Sun, così come alcune altre implementazioni reperibili, hanno metodi efficaci per ridurre il consumo di CPU, tra i quali l'HotSpot(tm), un metodo di precompilazione del bytecode in maniera tale da avere alcune parti già tradotte in linguaggio macchina, pronte per essere eseguite quando necessario.

La JVM ufficiale Sun implementa due tipi di HotSpot, che si differenziano essenzialmente per la quantità di bytecode già tradotto e per il momento in cui avviene la traduzione: la modalità Server HotSpot compila la maggior parte del codice al momento dell'avvio, e imposta il Garbage Collector per un comportamento "aggressivo", mentre la modalità Client HotSpot (quella usata di standard dalla JVM Sun), interpreta da subito il bytecode e ne compila in seguito alcune porzioni di frequente uso.

Di conseguenza la Server HotSpot avrà risposta minore all'avvio, in confronto alla Client HotSpot che inizia subito con l'esecuzione, ma sarà tendenzialmente più efficiente durante tutta l'esecuzione. Per questi motivi si usa la Server HotSpot per programmi server appunto, o in generale per programmi che resteranno in esecuzione a lungo e per i quali il tempo di avvio non è importante. Un altro approccio possibile (anche se più problematico, per i motivi visti sopra) potrebbe essere compilare il programma java in un codice nativo anziche' in bytecode, usando ad esempio il compilatore gcj della FSF (anche se ne esistono molti altri. )