Structure de la JVM Java
La JVM est le composant qui caractérise le plus Java. Ceci est notamment dû à sa caractéristique Write Once Run Anywhere. En effet un programme écrit en Java est d’abord compilé et traité dans une machine virtuelle et ensuite envoyé vers l’OS. Il n’existe donc aucune dépendance entre l’OS et le programme initial Java, ce qui fait que n’importe quelle machine équipée d’une JVM peut exécuter du code Java.
Voici une représentation de la structure de la JVM :
Le loader :
Une fois que les fichiers .java sont compilé en code binaire .class le loader intervient avec ses trois tâches majeurs :
Le loading :
Pour chaque fichier .class le loader écrit dans la zone des méthodes (method area) : le nom de la classe, son parent direct, la nature de la classe (Interface, Classe ou Classe abstraite) et enfin toutes les méthodes et variables de la classe. Une fois que cela est fait un objet de type Classe est créé dans la Heap memory, c’est ce qui est utilisé pour la fameuse fonction .getClass()
Le linking :
est fait en trois étapes :
- Vérification de la cohérence des fichiers .class
- Allocation de la mémoire suffisante pour les variables/ méthodes
- Résolution des références symboliques (c’est comme les pointeurs en C/ADA)
L’initialisation:
C’est l’étape durant laquelle toutes les variables statiques prennent une valeur, ceci est fait en partant du haut vers le bas et en respectant la hiérarchie des classes
La mémoire de la JVM :
La mémoire de la JVM est divisée en 5 :
- Method area : qui contient les informations relatives aux classes (nom, parents, variables et méthodes ..) Il n’y a qu’une seule Method area par JVM (ressource partagée)
- Heap area : Contient toutes les informations relatives aux objets créés. Il n’y a qu’une seul Heap par JVM => ressource partagée
- Stack area : chaque thread a son propre stack contenant toutes les variables et les méthodes utilisées. Une fois que le process effectué est terminé la JVM détruit le stack créé. Si on a trop de données pour la stack créée on aura une erreur de type stackOverflow. Si on a plus mémoire pour allouer un stack à un nouveau thread on a l’erreur OutOfMemorry
- Register PC : se charge de garder une trace de ce que chaque thread fait, on aurait donc un register par thread
- Native methods stack : il garde les méthodes natives, c-à-d des méthodes qui utilisent des apis d’un autre langage comme C/C++
Le Execution Engine:
Le moteur d’exécution exécute les fichiers .class ligne par ligne en utilisant des données présentes dans plusieurs sources. Il est composé de trois parties :
- L’interpréteur : interprète le byte code ligne par ligne et l’exécute. Si on se base seulement sur l’interpréteur on risque de devoir refaire la même opération plusieurs fois (à chaque fois qu’on voit l’appel vers une méthode)
- JIT (Just In Time) : Il est là pour augmenter l’efficacité de l’interpréteur, il compile le byte code en code natif, de façon à ce qu’à chaque fois que l’interpréteur rencontre un appel vers une méthode qui se répète, le JIT propose directement un moyen de le traiter. Pour plus de détails sur comment fonctionne la JIT voir ce lien.
- Garbage Collector : Il se charge de détruire tout objet non référencé.
