quando java jvm compila bytecode, dove viene inserito quel codice nello spazio di elaborazione?

Question

Quando jvm (hotspot nel mio caso) compila permanentemente determinati percorsi di codice in codice macchina, dove viene memorizzato il codice macchina? nel segmento .text della memoria di processo? nel mucchio del processo ??

Non sto parlando di JITing. Da quanto ho capito, JIT compilerà ed eseguirà bytecode senza mai salvare il codice compilato da nessuna parte. Ma che dire quando jvm è salvando quel codice - dove nello spazio di processo lo salva? ... come sottolineano i commenti e le risposte, tutto quello che stavo chiedendo è, in effetti, una parte di JIT.

EDIT:

come per il mio commento qui sotto, la situazione Sono in particolare riferendosi al è documentato qui come "ottimizzazione Adaptive": http://www.oracle.com/technetwork/java/whitepaper-135217.html#hotspot

Answer 1

In primo luogo, ciò che si sta descrivendo è JIT - in particolare come opere in Hotspot

per rispondere alla tua domanda su dove il codice è salvato in fase di esecuzione - è nel mucchio dei processi e dei puntatori al codice di metodo nel file di Klass dell'oggetto viene aggiornato per puntare ad esso. C'è anche qualcosa chiamato OSR (sulla sostituzione dello stack) per compilare lunghi loop in esecuzione direttamente sullo stack.

Answer 2

Non ho lavorato con macchine virtuali di qualità di produzione, ma qui ci sono i miei cinque centesimi.

.text sezioni in eseguibili Unix appartengono al file che memorizza il codice eseguibile; in fase di esecuzione questa sezione file viene mappata su un'area di memoria allocata dal linker di sistema durante l'inizializzazione del programma, tutto qui (su Linux, è possibile vedere il layout delle sezioni in memoria in /proc/$PID/maps).

Per quanto riguarda la compilazione JIT su sistemi Unix, posso solo pensare alle aree di memoria assegnate da mmap system call con il flag PROT_EXEC abilitato. Questa chiamata è specificata dagli standard POSIX e utilizzata dal linker del sistema Linux, ld.so, per caricare qualsiasi file eseguibile nativo in memoria. Questa chiamata può essere utilizzata allo stesso modo per allocare nuove aree di memoria eseguibili in fase di esecuzione.

Il mucchio solito è spesso protetto da OS/MMU venga eseguito, come un qualsiasi file /proc/$PID/maps suggerisce:

00dd4000-01292000 rw-p 00000000 00:00 0     [heap] 

qui rw-p significa che non ci sono dati a [heap] possono essere eseguiti (anche se, ad esempio, non è il caso con CPU x86 a 32 bit senza PAE, non hanno la capacità hardware per impedire l'esecuzione di alcuni dati di memoria come codice), ma può essere letto/scritto.

Quindi una VM ha bisogno di un'area di memoria dedicata con permesso di esecuzione codice. Infatti, esaminiamo per rwx aree di memoria in alcuni layout della memoria processo java:

# cat /proc/12929/maps | grep rwx  # I run a Java VM with PID 12929 
f3700000-f3940000 rwxp 00000000 00:00 0 # - an unnamed executable & writable region 

Poi esecuzione di codice nativo è una questione di assemblaggio codice entrambe le posizioni-indipendente nativo JIT-compilato (come oggetti condivisi è compilato codice, con gcc opzione -fPIC) o utilizzando l'indirizzo restituito da mmap().