La machine virtuelle fait du JIT, donc combine le gros de la complexité d'un compilateur et celui d'une machine virtuelle traditionnelle (genre Perl), mais en pire (il y a des processus de décision assez complexes pour décider quoi compiler en natif à la volée et quand ce n'est pas possible ou non rentable).
C'est une façon de voir les choses. Par contre je ne sais pas ce qui est plus complexe entre interpréter un byte-code et compiler un byte-code vers du natif et exécuter ce natif (ce que font les JIT).
Pour la compilation native, je connais pas bien les détails, mais j'imagine que ça met un sous-ensemble de la JVM (a priori plus simple) et le programme dans un même exécutable.
Globalement tu as la bibliothèque standard de java, le garbage collector et ton code.
Si c'est le garbage collector qui te fais peur pour certains usages, il faut savoir que java a toujours pu traiter des données hors de la heap, c'est à dire non géré par le gc. Tu ne peux pas totalement le retirer évidement.
Par contre évidement tu n'a plus les même garanties sur la mémoire. Je ne crois pas qu'on puisse avoir toutes les garanties sur la mémoire à coût 0 sauf à prouver son programme ou à en générer le code par des automates qui vérifies certaines propriétés (mais ce qui revient au même tu dois démontrer à ton automate que tu gère correctement ta mémoire).
Peut être que la solution jadis envisagée par sun de prouver la JVM puis de l'implémenter en hardware permettrait d'avoir à la fois de grandes garanties tout en ayant une performance très correcte.
[^] # Re: Quelques remarques
Posté par barmic 🦦 . En réponse au lien Linux et la sécurité, tel un désert et un oasis ?. Évalué à 2.
C'est une façon de voir les choses. Par contre je ne sais pas ce qui est plus complexe entre interpréter un byte-code et compiler un byte-code vers du natif et exécuter ce natif (ce que font les JIT).
Globalement tu as la bibliothèque standard de java, le garbage collector et ton code.
Si c'est le garbage collector qui te fais peur pour certains usages, il faut savoir que java a toujours pu traiter des données hors de la heap, c'est à dire non géré par le gc. Tu ne peux pas totalement le retirer évidement.
Par contre évidement tu n'a plus les même garanties sur la mémoire. Je ne crois pas qu'on puisse avoir toutes les garanties sur la mémoire à coût 0 sauf à prouver son programme ou à en générer le code par des automates qui vérifies certaines propriétés (mais ce qui revient au même tu dois démontrer à ton automate que tu gère correctement ta mémoire).
Peut être que la solution jadis envisagée par sun de prouver la JVM puis de l'implémenter en hardware permettrait d'avoir à la fois de grandes garanties tout en ayant une performance très correcte.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll