JDK, JRE, JVM

Comme le montre le schéma d'architecture ci-dessus, la JVM est

divisée en trois sous-systèmes principaux :
1- Class Loader Sub-System
2- Memory Area of JVM
3- Execution Engine
A- Class Loader :
Il s'agit du premier composant de la JVM et le chargeur Class Loader
est chargé d'exécuter de nombreuses fonctions sur le fichier de classe
(.class), notamment le chargement, la liaison et l'initialisation
(Loading, Linking, Initialization) au moment de l’exécution.
i) Loading :
Ce composant gère le chargement des .class fichiers du
système matériel dans la mémoire JVM.
Lors de la phase de chargement, le chargeur de classe lit
chaque fichier .class et stocke les données binaires
correspondantes dans Method Area. 
Les données ci-dessous sont stockées dans « method area »:
a) Nom qualifié complet de la classe chargée et de sa classe
parent immédiate.
b) Informations sur le fichier .class telles que le fichier est lié
à la classe ou à l'interface ou à l'énumération, les
informations sur les méthodes, les informations sur les
variables, les informations sur le constructeur, les
informations sur les modificateurs, les informations sur le
pool de constantes, etc.
- Après le chargement du fichier .class, immédiatement JVM
crée un objet pour cette classe chargée sur le heap memory
de type java.lang.class.
- Ces "objets de classe" chargés peuvent être utilisés par les
programmeurs pour obtenir des informations au niveau de la
classe telles que des informations sur la méthode ou des
informations sur les variables, des informations sur le
constructeur, etc.
Pour chaque type chargé, un seul objet de classe sera créé
même si nous utilisons la classe plusieurs fois dans notre
programme, comme indiqué dans l'image ci-dessous.
Toutes les classes ne sont pas chargées par un seul ClassLoader.
Selon le type de classe et le chemin de la classe, le ClassLoader
qui charge cette classe particulière est décidé. Pour connaître le
ClassLoader qui charge une classe, la méthode getClassLoader
() est utilisée. Toutes les classes sont chargées en fonction de
leurs noms et si l’une de ces classes n’est pas trouvée, elle
renvoie une NoClassDefFoundError ou
une ClassNotFoundException . Un ClassLoader Java est de trois
types :
a) Bootstrap ClassLoader :
 Il est chargé de charger les classes d'API Java principales (String class,
String buffer etc.) c'est-à-dire les classes présentes dans rt.jar. Le
chemin de rt.jar est jdk/jre/lib/rt.jar. Ce chemin (jdk/jre/lib/) est
appelé Bootstrap classpath.  Il est disponible par défaut avec chaque
JVM et est écrit dans les langages natifs C/C++.La priorité la plus
élevée sera donnée à ce chargeur.
 b) Extension ClassLoader :
Il s'agit de la classe enfant du chargeur de classe Bootstrap.
Ce chargeur de classe est chargé de charger les classes à partir du
chemin de classe d'extension (jdk/jre/lib/ext/ .jar), etc. Le chargeur de
classe d'extension est implémenté en Java et le fichier .class
correspondant est sun.misc.Launcher$ExtClassLoader.class.
c) Application ClassLoader :
 Il s'agit de la classe enfant du chargeur de classe d'extension. Ce
chargeur de classe est chargé de charger les classes à partir du chemin
de classe de l'application. Il utilise en interne la variable
d'environnement classpath, l’option de ligne de commande -classpath ou -cp.
Le chargeur de classe d'application est implémenté en Java et le
fichier .class correspondant est sun.misc.Launcher$AppClassLoader.

ii) Linking :
La liaison consiste en 3 activités Vérifier, Préparer, Résoudre
(Verify,Prepare,Resolve) :
 a) Verify
 C'est le processus qui consiste à s'assurer que la représentation binaire
d'une classe est structurellement correcte ou non, c'est-à-dire qu'à
l'intérieur de la JVM, le vérificateur de byte-code vérifiera si le fichier
.class est généré par un compilateur valide ou non. , si le fichier .class est
correctement formaté ou non. C'est l'une des raisons pour lesquelles Java
est un langage sécurisé. Si la vérification échoue, nous obtiendrons une
exception d'exécution indiquant java.lang.VerifyError.
b) Prepare
 il s'agit d'un processus d'attribution de la mémoire pour les variables
statiques au niveau de la classe ou au niveau de l'interface et
d'attribution des valeurs par défaut

c) Resolve <-----Prob
C'est le processus de remplacement des références/noms de mémoire
symboliques dans notre programme par les références de mémoire
d'origine de Method area.
iii) Initialization :
Dans ce cas, toutes les variables statiques sont affectées avec des valeurs
d'origine et les blocs statiques seront exécutés du parent vers l'enfant et de
haut en bas.

Remarque : lors du chargement, de la liaison et de l'initialisation, si une

erreur se produit, nous obtiendrons une exception d'exécution indiquant
java.lang.linkageError

B- Memory Area :
La division de la zone mémoire totale de la JVM est en 5 parties :

i) Method Area
La zone de méthode est également appelée zone de classe. La zone de
méthode stocke les données de chaque classe, telles que les champs, les
pools de constantes et les données et informations de méthode. Toutes les
données au niveau de la classe seront stockées ici, y compris les variables
statiques. Il n'y a qu'une seule zone de méthode par JVM et c'est une
 ressource partagée (La zone de méthode est accessible par plusieurs
threads simultanément)
ii) Heap Area
Pour chaque JVM, une zone de tas est disponible. La zone de tas sera créée
au démarrage de la JVM. Les objets et les variables d'instance
correspondantes seront stockés dans la zone de tas. La zone Heap est
accessible par plusieurs threads, par conséquent, les données stockées dans
la mémoire de tas ne sont pas thread-safe.

iii) Stack Area

Pour chaque thread, une pile d'exécution distincte sera créée. Pour chaque
appel de méthode, une entrée sera créée dans la mémoire de la pile
appelée Stack Frame. Toutes les variables locales, tous les paramètres et
toutes les adresses de retour seront créés dans la mémoire de la pile. Stack
ne stocke jamais d'objets, mais ils stockent des références d'objets. Après
avoir terminé une méthode, l'entrée correspondante sera supprimée. Après
avoir terminé tous les appels de méthode, la pile deviendra vide. La pile vide
sera détruite par JVM juste avant de terminer le thread. La zone de pile est
thread-safe car ce n'est pas une ressource partagée. Le Stack Frame est
divisé en trois sous-entités :
• Local Variable Array – Lié à la méthode, combien de variables locales
sont impliquées et les valeurs correspondantes seront stockées ici.
• Pile d'opérandes - Si une opération intermédiaire doit être effectuée, la
pile d'opérandes agit comme espace de travail d'exécution pour effectuer
l'opération.
• Données de trame- Tous les symboles correspondant à la méthode sont
stockés ici. En cas d'exception, les informations du bloc catch seront
conservées dans les données de trame.
iv) Pc Registers
Pour chaque thread, des registres PC (compteur de programme) distincts
seront créés au moment de la création du thread. Les registres PC
contiennent l'adresse de l'instruction en cours d'exécution, une fois
l'exécution de l'instruction terminée automatiquement, le registre PC sera
incrémenté pour contenir l'adresse de l'instruction suivante.
v) Native Method Area Prob

C- Execution Engine :
C'est le composant central de JVM et il est responsable de l'exécution des fichiers
de classe Java. Il contient principalement trois composants :
i) Interpreter
Le travail de ce composant est de lire et de convertir le bytecode en
code lisible par machine et d'exécuter chaque instruction une par
une. Par conséquent, cela peut interpréter rapidement la ligne de
bytecode mais prend beaucoup de temps pour l'exécuter.
L'inconvénient de l'interpréteur est qu'il interprète à chaque fois,
même si la même méthode est invoquée plusieurs fois, ce qui réduit les
performances du système.
ii) JIT Compiler
iii) Garbage Collector