È possibile implementare un compilatore nativo per un "linguaggio gestito" come Java?

1

Nella maggior parte dei casi, è possibile creare sia un compilatore nativo che un interprete per un linguaggio di programmazione. Il compilatore convertiva semplicemente il codice sorgente in codice macchina, e l'interprete eseguiva semplicemente il codice sorgente (o qualche IL prodotto da un compilatore).

Tuttavia, non sono sicuro delle lingue con Garbage Collection. Prendiamo Java per esempio.

Quando è stato progettato Java, era chiaro che i programmi Java sarebbero stati sempre eseguiti sulla JVM. E la JVM doveva contenere un meccanismo di garbage collection. Quindi, mentre progettava il linguaggio Java stesso, non c'era bisogno di distruttori e simili.

Se si implementasse un compilatore Java nativo , ciò significherebbe che il codice sorgente Java sarebbe stato compilato in codice macchina per essere eseguito sulla macchina stessa, non su una VM. E la macchina stessa non ha un meccanismo per la garbage collection.

In che modo qualcuno che implementa un compilatore nativo Java si occupa di questa situazione? È possibile creare un compilatore nativo per Java, dal momento che il design Java "conta" sulla raccolta automatica dei dati inutili? (E forse su alcune cose aggiuntive che la VM fa per il programma?)

    
posta Aviv Cohn 23.04.2014 - 11:30
fonte

2 risposte

10

Poiché i compilatori nativi per Java, C # ecc. esistono, è ovviamente possibile.

Se una lingua è o meno "gestita" è una questione di semantica del linguaggio, non di implementazione. Non importa se si tratta di un compilatore, un interprete o un'implementazione in modalità mista. Ogni lingua può essere implementata con un compilatore e ogni lingua può essere implementata con un interprete. Dopo tutto, la maggior parte delle implementazioni real-world di Java sono comunque compilatori statici.

Anche C e C ++ hanno bisogno di una libreria runtime. Per un compilatore Java-to-x86, quella libreria di runtime dovrebbe includere un po 'più di quanto farebbe per un compilatore C-to-x86 (il GC, il sistema di riflessione, ma anche il linker dinamico e il caricatore dinamico perché il codice Java può essere aggiunto al programma in qualsiasi momento), ma il principio è lo stesso.

A proposito, dovresti stare attento con termini come "codice nativo" o "compilatore nativo": ci sono CPU che eseguono JVM codice byte , e ci sono interpreti x86 per la JVM . Immaginate quindi un programma JVM in esecuzione su una CPU JVM e un programma x86 in esecuzione su un interprete in esecuzione su una JVM in esecuzione su una CPU Sparc emulata tramite QEmu in esecuzione su un PowerPC. Quale è "nativo"?

    
risposta data 23.04.2014 - 11:51
fonte
1

Certo, è possibile. Significa semplicemente che per mantenere la semantica completa di java come specificato, devi includere parte del codice che costituisce la JVM in ogni file binario che crei.

In particolare, devono essere inclusi il conteggio dei riferimenti, la raccolta dei dati inutili, il codice delle informazioni sul tipo di esecuzione ecc. (a meno che tu non abbia un compilatore molto intelligente che può provare che alcune funzioni non verranno utilizzate da questo programma). Nel complesso si salva parte del codice di interpretazione del codice JIT e byte nella JVM, ma si paga per questo aumentando la dimensione di ciascun programma compilato in modo nativo.

Questo di solito non è un buon compromesso, motivo per cui è raramente fatto, ma non esiste una ragione tecnica fondamentale per cui le cose che la JVM fa per te non possano essere fatte da un'applicazione autonoma per se stessa. Non è diverso dal raggruppamento ad es. un interprete Perl con un copione interessante per risparmiare alla gente la necessità di installare Perl.

    
risposta data 23.04.2014 - 11:40
fonte

Leggi altre domande sui tag