Perché la cache JVM non ha compilato il codice JIT?

L'implementazione canonica di JVM di Sun applica un'ottimizzazione piuttosto sofisticata al bytecode per ottenere velocità di esecuzione quasi native dopo che il codice è stato eseguito alcune volte.

La domanda è: perché questo codice compilato non viene memorizzato nella cache su disco per essere utilizzato durante gli usi successivi della stessa funzione / classe?

Allo stato attuale, ogni volta che viene eseguito un programma, il compilatore JIT ricomincia da capo, invece di utilizzare una versione precompilata del codice. L'aggiunta di questa funzionalità non aggiungerebbe un aumento significativo al tempo di esecuzione iniziale del programma, quando il bytecode viene essenzialmente interpretato?

Senza ricorrere a cut'n'paste del collegamento che @MYYN ha pubblicato, sospetto che ciò sia dovuto al fatto che le ottimizzazioni eseguite dalla JVM non sono statiche, ma piuttosto dinamiche, basate sui modelli di dati e sui modelli di codice. È probabile che questi modelli di dati cambieranno durante la durata dell'applicazione, rendendo le ottimizzazioni memorizzate nella cache meno che ottimali.

Quindi avresti bisogno di un meccanismo per stabilire se le ottimizzazioni salvate erano ancora ottimali, a quel punto potresti anche riottimizzare al volo.

La JVM di Oracle è effettivamente documentata per farlo - citando Oracle,

il compilatore può trarre vantaggio dal modello di risoluzione delle classi di Oracle JVM per rendere eventualmente persistenti i metodi Java compilati tra le chiamate, le sessioni o le istanze del database. Tale persistenza evita il sovraccarico di ricompilazioni non necessarie tra sessioni o istanze, quando è noto che semanticamente il codice Java non è cambiato.

Non so perché tutte le implementazioni di VM sofisticate non offrono opzioni simili.

Un aggiornamento alle risposte esistenti - Java 8 ha un JEP dedicato a risolvere questo problema:

=> JEP 145: codice compilato nella cache . Nuovo collegamento .

Ad un livello molto alto, il suo obiettivo dichiarato è :

Salva e riutilizza il codice nativo compilato da esecuzioni precedenti per migliorare il tempo di avvio di grandi applicazioni Java.

Spero che questo ti aiuti.

Excelsior JET ha un compilatore JIT per la memorizzazione nella cache dalla versione 2.0, rilasciata nel 2001. Inoltre, il suo compilatore AOT può ricompilare la cache in un singolo oggetto DLL / condiviso utilizzando tutte le ottimizzazioni.

Non conosco le ragioni effettive, non essendo in alcun modo coinvolto nell'implementazione della JVM, ma posso pensare ad alcune plausibili:

• L'idea di Java è di essere un linguaggio che si scrive una sola volta e che si esegue ovunque, e inserire materiale precompilato nel file di classe è una specie di violazione (solo "un po '" perché ovviamente il codice byte effettivo sarebbe ancora lì)
• Aumenterebbe le dimensioni del file di classe perché avresti lo stesso codice lì più volte, specialmente se ti capita di eseguire lo stesso programma su più JVM diverse (il che non è davvero raro, se consideri versioni diverse come JVM diverse, che tu devo davvero fare)
• I file di classe stessi potrebbero non essere scrivibili (anche se sarebbe abbastanza facile verificarlo)
• Le ottimizzazioni JVM sono parzialmente basate su informazioni di runtime e su altre esecuzioni potrebbero non essere applicabili (sebbene dovrebbero comunque fornire qualche vantaggio)

Ma sto davvero indovinando, e come puoi vedere, non penso che nessuna delle mie ragioni sia un vero e proprio spettacolo. Immagino che Sun non consideri questo supporto come una priorità, e forse la mia prima ragione è vicina alla verità, poiché farlo abitualmente potrebbe anche portare le persone a pensare che i file di classe Java abbiano davvero bisogno di una versione separata per ogni VM invece di essere piattaforme.

Il mio modo preferito sarebbe effettivamente avere un traduttore da bytecode a nativo separato che potresti usare per fare qualcosa di simile esplicitamente in anticipo, creando file di classe che sono esplicitamente costruiti per una specifica VM, con possibilmente il bytecode originale in essi in modo che tu può essere eseguito anche con diverse VM. Ma probabilmente questo deriva dalla mia esperienza: ho principalmente fatto Java ME, dove fa davvero male che il compilatore Java non sia più intelligente della compilazione.