2009-09-05 48 views

risposta

10

Esistono già diverse implementazioni hardware del sistema Java (ad esempio una CPU che può eseguire bytecodes) ma non sono diventate mainstream. Ciò è probabilmente dovuto al fatto che le implementazioni del software funzionano altrettanto bene o addirittura meglio di quanto le CPU siano diventate sempre più veloci.

Come si troverà quando si studierà più approfonditamente, i dettagli delle implementazioni JVM non sono così importanti (e variano un po ') ma tutti eseguono il linguaggio macchina del codice JVM JAVA. Se rimani all'interno del mondo Java e non ti colleghi in "nativo", dovresti essere a posto con qualsiasi implementazione tu scelga.

Questa società fa una vita di fornire sistemi server sintonizzati per i programmi Java, che potrebbe interessarti: http://www.azulsystems.com/

+0

una domanda veloce, però, quale configurazione deve avere un dispositivo per eseguire la versione del software di jvm? – inquisitive

+1

@Inquisitive Qualcuno deve aver reso disponibile una JVM per quel dispositivo. La configurazione deve quindi soddisfare i requisiti per JVM. –

+1

Qui nel 2017 la CPU ha smesso di diventare sempre più veloce. Invece il software JVM usa molta più memoria per mantenere le informazioni di profilazione che il JIT può usare per creare codice macchina estremamente ottimizzato dove è importante. Le implementazioni hardware di solito non hanno quell'opzione, quindi non possono ottimizzare tanto. Dato l'hardware identico, la soluzione software quindi vince. –

3
  • Attuare la JVM in hardware ignora il vantaggio di esecuzione di codice gestito. Che differenza sarebbe allora da qualsiasi altro codice nativo. E sì, anche la neutralità della piattaforma è ostacolata. Indipendentemente da ciò, esistono tali implementazioni, date un'occhiata alla serie di processori aJile e alla Jazelle ARM. Questi sono mirati alle piattaforme incorporate però.
  • Compilatore di Sun, HotSpot utilizza JIT. Personalmente non ho usato altri, ma dovrebbe essere una tecnologia molto utilizzata.
  • JVM può essere considerata una VM con risorse limitate, indirizzata a una sola piattaforma specifica (il bytecode Java).
+0

che significa la virtualizzazione di java (o possiamo chiamarlo JRE?) È diversa dalla virtualizzazione del sistema operativo ... ho ragione? – paragjain

+0

La virtualizzazione, come ho capito, è la simulazione dell'hardware tramite software. L'applicazione guest (app java o sistemi operativi) vede la VM come un altro computer e usa il codice nativo per interagire con essa.La VM, d'altra parte, comprende il codice macchina nativo, interpreta ciò che l'app sta richiedendo e quindi esegue le azioni stesse, a condizione che siano in atto autorizzazioni e permessi necessari. Quindi, con questa definizione, la virtualizzazione delle app o del sistema operativo Java è simile, è la gamma di operazioni fornite al guest e la potenza della VM che differisce. La virtualizzazione – Chintan

+0

si riferisce alla modifica di una macchina fisica completa in un programma in esecuzione su un'altra macchina fisica. –

6

Sì, è possibile. Anche se sembra che sia bloccato nella fase delle specifiche (o che sia stato abbandonato), picoJava consente l'esecuzione nativa del bytecode Java. picoJava has a port available on a FPGA. C'è Jazelle, anche per processori ARM.

Dato che l'hardware eseguirà direttamente bytecode, tutte le ottimizzazioni dovrebbero essere eseguite anche nell'hardware. JIT non sarebbe richiesto, dal momento che il processore eseguirà direttamente bytecode. Dopotutto qualsiasi implementazione hardware comporterebbe l'implementazione del modello JVM come definito nello Java Virtual Machine Specification. Ottimizzazioni che possono essere eseguite, saranno sulla linea di ottimizzazioni hardware - pipeline di istruzioni, uso di cache ecc.

La neutralità dell'hardware non viene persa, poiché il bytecode in esecuzione su un'implementazione hardware continuerà a funzionare su un'implementazione software come bene. È lo standard bytecode che consente a Java di essere neutrale sull'hardware.

+0

Bello per aver sottolineato che "la neutralità dell'hardware non è persa, dal momento che il bytecode in esecuzione su un'implementazione hardware continuerà a funzionare anche su un'implementazione software: è lo standard bytecode che consente a Java di essere neutrale all'hardware". –

6

Sì, ci sono diverse implementazioni hardware Java. Tuttavia, non sempre ottengono risultati migliori rispetto a quelli in esecuzione su silicio più generico.

Mark Lam ha scritto several interesting blogs entries su questo argomento.

+0

Uno dei problemi sottostanti sarebbe che le ottimizzazioni del software possono essere "riparate". L'hardware non può. –

+1

Anche se l'esecuzione avviene in hardware, non c'è nulla che ostacoli l'hardware JVM a fare qualsiasi ottimizzazione voglia. La macchina ha RAM e tutto :) –

+4

In realtà, è letteralmente impossibile che il software sia più veloce dell'hardware. Se l'hardware è più lento, significa che è sottosviluppato. Ad esempio, se Hotspot JIT è più veloce di qualche implementazione hardware di Java, puoi semplicemente spostare il JIT Hotspot sull'hardware, che sarà sicuramente più veloce di quello esistente. In ogni caso, dubito che JIT sia il modo più veloce per implementare la JVM nell'hardware. @Vineet: 1. Tutto ciò che può essere fatto nel software può essere fatto in hardware. 2. x86 esegue rigorose ottimizzazioni a livello di hardware. –

Problemi correlati