Machine virtuelle Java

Schéma de l'architecture générale d'un programme s'exécutant dans une machine virtuelle Java.

Une machine virtuelle Java (en anglais Java Virtual Machine , JVM ) est une machine virtuelle de processus natif , c'est-à-dire exécutable sur une plate-forme spécifique, capable d'interpréter et d'exécuter des instructions exprimées dans un code binaire spécial (le bytecode Java ), dont il est généré par le compilateur de langage Java .

Le code binaire Java n'est pas un langage de haut niveau , mais un véritable code machine de bas niveau , viable même comme langage d'entrée pour un microprocesseur physique . Comme toutes les pièces du puzzle Java, il a été développé à l'origine par Sun.

La JVM est l'une des pièces fondamentales de la plate-forme Java . Fondamentalement, il est situé à un niveau supérieur au matériel du système sur lequel l'application est destinée à être exécutée, et cela agit comme un pont qui comprend à la fois le bytecode et le système sur lequel il est destiné à être exécuté. Ainsi, lorsqu'une application Java est écrite, elle se fait en pensant qu'elle sera exécutée dans une machine virtuelle Java spécifique, celle-ci étant celle qui convertit in fine le bytecode en code natif de l'appareil final.

Le grand avantage de la machine virtuelle Java est de fournir une portabilité au langage, de sorte que Sun Microsystems a créé différentes machines virtuelles Java pour différentes architectures, et ainsi, un programme .class écrit en Windows peut être interprété dans un environnement Linux . Il suffit d'avoir ladite machine virtuelle pour ces environnements. D'où le fameux axiome qui suit Java : "write it once, run itwhere", ou "Write once, runwhere".

Mais les tentatives de la société propriétaire de Java et des produits dérivés pour construire des microprocesseurs qui acceptent le bytecode Java comme langage machine ont été largement infructueuses.

La machine virtuelle Java peut être implémentée dans un logiciel, du matériel, un outil de développement ou un navigateur Web ; lit et exécute le bytecode précompilé qui est indépendant de la plate-forme multiplateforme . La JVM fournit des définitions pour un jeu d' instructions , un jeu de registres, un format de fichier de classe, la pile, un tas avec un ramasse-miettes et une zone mémoire. Toute implémentation de la JVM approuvée par SUN doit pouvoir exécuter n'importe quelle classe conforme à la spécification.

Il existe plusieurs versions, par ordre chronologique, de la machine virtuelle Java. En général, la définition du bytecode Java ne change pas de manière significative entre les versions, et si c'est le cas, les développeurs du langage veillent à assurer la rétrocompatibilité avec les produits précédents.

Depuis J2SE 5.0, les modifications apportées à la spécification JVM ont été développées sous les auspices du Java Community Process (JCP) et spécifiées dans JSR 924. Depuis 2006, les modifications apportées à la spécification pour prendre en charge les modifications du format de fichier de classe (JSR 202 ​) sont en cours de réalisation dans une version de maintenance de la JSR 924. Les spécifications de la JVM sont publiées dans ce que l'on appelle "le livre bleu". ​ Ainsi, la préface se lit comme suit : Nous espérons que cette spécification documente suffisamment la machine virtuelle Java pour rendre les implémentations possibles à partir de zéro. Sun fournit des tests qui vérifient que les implémentations de machines virtuelles Java fonctionnent correctement.

Kaffe est un exemple d'implémentation JVM à partir de zéro. Sun est le propriétaire de la marque "Java", qu'il utilise pour certifier les implémentations conformes et entièrement conformes à ses spécifications. Sun a été acquis en 2010 par Oracle Corporation.

Environnement d'exécution

Afin d'exécuter une application sur une machine virtuelle Java, le code du programme doit être compilé dans un format binaire portable standardisé, généralement sous la forme de fichiers avec une extension .class. Un programme peut être composé de plusieurs classes, auquel cas chaque classe aura son propre fichier .class qui lui est associé. Pour faciliter la distribution des applications, les fichiers de classe peuvent être regroupés dans un fichier au format jar. Cette idée est apparue à l'époque des premières applets Java. Ces applications peuvent télécharger les fichiers de classe dont elles ont besoin au moment de l'exécution, ce qui exerce une pression considérable sur le réseau à une époque où la vitesse était un problème. L'emballage évite les frais généraux en ouvrant et en fermant continuellement les connexions pour chacun des fragments nécessaires.

Le code résultant de la compilation est exécuté par la JVM qui réalise l'émulation du jeu d'instructions, soit par un processus d'interprétation, soit plus communément par un compilateur JIT (Just In Time), tel que HotSpot de Sun. Cette dernière option convertit le bytecode en code natif de la plateforme cible, ce qui permet une exécution beaucoup plus rapide. L'inconvénient est le temps nécessaire au début de la compilation.

Au sens large, la machine virtuelle Java agit comme un pont entre la sortie de la compilation (le bytecode) et le système sur lequel l'application s'exécute. Pour chaque appareil, il doit y avoir une JVM spécifique, que ce soit un téléphone mobile, un PC Windows XP ou un micro-ondes. Dans tous les cas, chaque machine virtuelle connaît le jeu d'instructions de la plateforme cible, et traduit un code écrit en langage Java (commun à tous) en code natif que le matériel de la plateforme est capable de comprendre.

Le vérificateur de bytecode

La JVM "vérifie" ceci pour tout le bytecode avant de l'exécuter. Cela signifie que seul un nombre limité de séquences de bytecode forment des programmes valides ; par exemple, une instruction JUMP (branche) ne peut pointer que vers une seule instruction dans la même fonction. Pour cette raison, le fait que la JVM soit une architecture de pile n'implique pas une vitesse de chargement pour l'émulation sur les architectures basées sur les registres lors de l'utilisation d'un compilateur JIT : cela ne fait aucune différence pour un compilateur JIT si vous nommez des registres avec des noms ou des positions imaginaires de des piles imaginaires qu'il faut allouer aux registres de l'architecture cible. En fait, la vérification de code rend la JVM différente d'une architecture de pile classique dont l'émulation efficace avec un compilateur JIT est plus compliquée et généralement effectuée par un interpréteur plus lent.

La vérification du code garantit également que des modèles de bits arbitraires ne peuvent pas être utilisés comme adresses. La protection de la mémoire est réalisée sans avoir besoin d'une unité de gestion de la mémoire ( "MMU" ). Ainsi, JVM est un moyen efficace d'obtenir une protection de la mémoire sur les puces qui n'ont pas de MMU.

Bytecodes

La JVM contient des instructions pour les groupes de tâches suivants :

• chargement et stockage
• Arithmétique
• Conversion de type
• Création et manipulation d'objets
• Gestion de la pile ( push et pop )
• Transferts de contrôle ( branchement )
• Appel et retour aux méthodes
• exceptions

La clé est la compatibilité binaire. Chaque système d'exploitation sur un hôte particulier a besoin de sa propre implémentation de JVM et d'exécution. Ces JVM interprètent sémantiquement le bytecode de la même manière, mais l'implémentation réelle peut varier. Plus compliquée que la simple émulation de bytecode est la mise en œuvre compatible et efficace des API Java, qui doivent être mappées pour chaque système d'exploitation hôte.

Extension de code à distance sécurisée

Une architecture de machine virtuelle permet un contrôle précis des actions que le code peut effectuer à l'intérieur de la machine. Ceci est conçu pour permettre l'exécution en toute sécurité de code non fiable à partir de sources distantes ; un modèle utilisé très célèbre est les applets Java . Les applets s'exécutent dans une machine virtuelle intégrée au navigateur de l'utilisateur, exécutant le code téléchargé à partir d'un serveur HTTP distant. Le code distant s'exécute dans un « bac à sable » hautement restreint qui est conçu pour protéger l'utilisateur contre le code mauvais ou malveillant. Les éditeurs disposant de ressources financières suffisantes peuvent obtenir un certificat avec lequel créer des applets signés numériquement qui les caractérisent comme "sûrs", leur donnant ensuite l'autorisation de quitter le bac à sable et d'accéder au système de fichiers local et au système réseau, vraisemblablement sous le contrôle de l'utilisateur.

Implémentations de machines virtuelles

L'édition J2SE a deux implémentations de la machine virtuelle :

• Java HotSpot Client VM : La machine virtuelle par défaut, préparée pour obtenir les performances maximales dans l'exécution des applications dans l'environnement client, par exemple, en minimisant le temps de démarrage d'une application Java.
• Java HotSpot Server VM : Préparé pour obtenir les performances maximales dans l'exécution des applications dans l'environnement du serveur.

Voir aussi

• Java
• Processus communautaire Java
• machine à empiler
• langage de programmation orienté pile
• processeur Java

Liens externes

• Kaffe.org - le projet Kaffe
• Téléchargement de la machine virtuelle Java
• JamVM - La machine virtuelle Jam
• Une introduction à la structure et aux fonctionnalités de base de la machine virtuelle Java
• Testez votre JVM
• Site principal de Sun Microsystems (anglais)
• Téléchargement de Java SUN ( lien brisé disponible sur Internet Archive ; voir historique , première et dernière version ). (en anglais);

1. Les clarifications et modifications apportées à la spécification de la machine virtuelle Java, deuxième édition incluent une liste des modifications qui doivent être apportées pour prendre en charge J2SE 5.0 et JSR 45
2. JSR 45 - Spécifie les modifications apportées au format de fichier de classe pour prendre en charge le débogage au niveau source des langages tels que JSP et SQLJ qui sont traduits en Java