II-A. G�n�ralit�s sur la JVM▲
Avant de nous int�resser au bytecode Java, il est n�cessaire de comprendre comment fonctionne dans les grandes lignes la JVM.
Tous les articles d�j� publi�s de la s�rie portent le tag jvmhardcore.
Le JRE est compos� de l'API Java et de la JVM. Le r�le de la JVM est de lire une application compos�e de fichiers .class sous diff�rentes formes (zip, jar, war, un simple tableau d'octets, etc.) � l'aide d'un chargeur de classes et de l'ex�cuter, ainsi que l'API Java.
D'une mani�re g�n�rale, une Machine Virtuelle (VM) est une impl�mentation logicielle d'une architecture physique ou hypoth�tique. Il existe deux types de machines virtuelles, les VM syst�me et les VM applicatives. La JVM fait partie de la seconde cat�gorie. Elle est ex�cut�e comme n'importe quelle application sur un syst�me d'exploitation h�te et est associ�e � un seul processus. Son but est de fournir un environnement de programmation ind�pendant de la plate-forme qui fait abstraction du mat�riel sous-jacent et/ou du syst�me d'exploitation, et permet � un programme de s'ex�cuter de la m�me mani�re sur n'importe quelle plate-forme. La JVM utilise un bytecode, un langage interm�diaire entre Java (le langage utilisateur) et le langage machine (Virtual machine en anglais).
Bien que dans JVM, le ��J�� signifie Java, il est th�oriquement possible d'impl�menter un compilateur compilant n'importe quel langage en bytecode pour la JVM. Mais en pratique certains langages sont tr�s difficiles � impl�menter de mani�re efficiente.
Quelques particularit�s de la JVM
- Machine virtuelle bas�e sur le mod�le de la pile�: les architectures d'ordinateurs les plus populaires telles que l'architecture Intel x86 et l'architecture ARM sont bas�es sur des registres. Cependant la JVM est bas�e sur le mod�le de la pile (LIFO, stack-based). Dalvik, la machine virtuelle d'Android ne suit pas la JVMS, puisqu'elle est bas�e sur des registres.
- R�f�rences symboliques�: tous les types (classes et interfaces), � l'exception des primitifs (boolean, int, float, etc.), sont d�sign�s par une r�f�rence symbolique et non une r�f�rence explicite d'une adresse m�moire.
- Ramasse-miettes�: l'instance d'une classe est cr��e explicitement par le code du d�veloppeur et est d�truite automatiquement par le ramasse-miettes.
- Garantie de l'ind�pendance de la plate-forme en d�finissant clairement les types primitifs�: la taille des types primitifs est fix�e par la JVMS.
- Ordre des octets du r�seau�: toujours dans un souci de maintenir l'ind�pendance de la plate-forme, la repr�sentation des donn�es doit �tre fix�e. L'ordre des octets du r�seau a �t� choisi. Il s'agit en r�alit� de l'orientation big-endian (l'octet de poids le plus fort se trouve � gauche et est stock� en premier en m�moire).
II-B. Zones de donn�es d'ex�cution (Runtime Data Areas)▲
Le code Java est ex�cut� en suivant le processus ci-dessous�:
Pour l'instant, seule l'�tude des zones de donn�es d'ex�cution nous sera utile pour comprendre le format d'un fichier .class.
La JVM d�finit diff�rentes zones de donn�es d'ex�cution qui sont utilis�es durant l'ex�cution d'un programme. Certaines de ces zones de donn�es sont cr��es lorsque la JVM est lanc�e et sont d�truites lorsqu'elle s'arr�te. Les autres zones sont propres � chaque fil d'ex�cution (thread). Les zones de donn�es par fils d'ex�cution sont cr��es lorsque le fil d'ex�cution est cr�� et sont d�truites lorsqu'il se termine.
II-B-1. Le tas (HEAP)▲
La JVM a un tas partag� par tous les fils d'ex�cution. Le tas est une zone de donn�es d'ex�cution dans laquelle toutes les instances de classes et les tableaux sont stock�s. Le tas est cr�� au d�marrage de la JVM. Les objets n'�tant pas explicitement d�sallou�s de la m�moire, lorsqu'ils ne sont plus r�f�renc�s le ramasse-miettes les supprime du tas.
II-B-2. Zone de m�thodes (METHOD AREA)▲
Lorsque le chargeur de classes charge une classe, il stocke sa structure (le pool de constantes, les donn�es des champs et des m�thodes, et le code des m�thodes et des constructeurs) dans la Zone de M�thodes. Il s'agit d'un espace m�moire partag� par tous les fils d'ex�cution et la JVMS n'impose pas qu'il soit lib�r� par le ramasse-miettes et donc qu'il fasse partie du tas (heap).
II-B-3. Pool de constantes d'ex�cution (RUNTIME CONSTANT POOL)▲
Le pool de constantes est une repr�sentation d'ex�cution par classe ou par interface du pool de constantes d�fini dans un fichier .class, sur lequel nous reviendrons dans quelques semaines.
Il contient plusieurs sortes de constantes, des litt�rales num�riques connues lors de la compilation aux r�f�rences de champs ou de m�thodes devant �tre r�solues lors de l'ex�cution. Le pool de constantes d'ex�cution est comparable � une table de symboles utilis�e par un langage de programmation conventionnel, bien qu'il contienne plus de types de donn�es qu'une table de symboles standard.
Chaque pool de constantes d'ex�cution est allou� � partir de la zone de m�thodes. Le pool de constantes d'ex�cution pour une classe ou une interface est construit lorsque la classe ou l'interface est cr��e par la JVM.
II-C. Fils d'ex�cution (THREADS)▲
Il existe deux types de fils d'ex�cution Java�:
- les fils d'ex�cution de type d�mon�;
- et les fils d'ex�cution de type non-d�mon.
Les fils d'ex�cution de type d�mon s'arr�tent lorsqu'il n'y a plus de fils d'ex�cution de type non-d�mon. M�me si une application ne cr�e pas de fils d'ex�cution, la JVM en cr�e plusieurs, dont la plupart sont des fils d'ex�cution de type d�mon.
Le fil d'ex�cution principal d'une application est celui ex�cutant la m�thode main(). Il est le premier et le dernier fil d'ex�cution de type non-d�mon � s'ex�cuter. Lorsque l'on atteint la fin de la m�thode main() -�et de tous les fils d'ex�cution de type non-d�mon lanc�s lors de son ex�cution�- le fil d'ex�cution se termine, mettant fin aux fils d'ex�cution de type d�mon et par cons�quent � l'ex�cution de la JVM.
� noter qu'un fil d'ex�cution de type d�mon peut �tre cr�� au sein d'une application.
II-D. Pointeur d'instruction (PROGRAM COUNTER)▲
La JVM peut supporter l'ex�cution de plusieurs fils d'ex�cution en parall�le. Chaque fil d'ex�cution a son propre pointeur d'instruction (PC Program Counter). � tout moment, chaque fil d'ex�cution ex�cute le code d'une seule m�thode, la m�thode courante pour ce fil d'ex�cution. Si cette m�thode n'est pas native, le pointeur d'instructions contient l'adresse de l'instruction de la JVM en cours d'ex�cution. Si la m�thode en cours d'ex�cution par le fil d'ex�cution est native, le pointeur d'instructions est ind�fini.
II-E. Piles Java (JAVA VIRTUAL MACHINE STACKS)▲
Chaque fil d'ex�cution de la JVM a une pile qui lui est propre, cr��e en m�me temps que le fil d'ex�cution. Une pile stocke des cadres (identifi�s par C0, C1, etc. dans l'illustration ci-dessous).
II-F. Piles de m�thodes natives (NATIVE METHOD STACKS)▲
� l'instar des m�thodes Java qui sont ex�cut�es dans les piles Java, les m�thodes natives (g�n�ralement en C/C++) sont ex�cut�es dans les piles de m�thodes natives. Les piles de m�thodes natives sont g�n�ralement allou�es par fil d'ex�cution lorsqu'il est cr��.
II-G. Cadres (FRAMES)▲
Un cadre est utilis� pour stocker des donn�es et des r�sultats partiels, ainsi que pour effectuer des liaisons dynamiquement, retourner des valeurs de m�thodes et transmettre des exceptions.
Un nouveau cadre est cr�� � chaque fois qu'une m�thode est appel�e. Un cadre est d�truit lorsque l'ex�cution de la m�thode est termin�e, que ce soit normalement ou non (si une exception est lev�e). Les cadres sont allou�s dans la pile Java du fil d'ex�cution cr�ant le cadre. Chaque cadre a son propre tableau de variables locales, sa pile d'op�randes et une r�f�rence vers le pool de constantes d'ex�cution de la classe de la m�thode courante.
Seulement un cadre est actif � la fois par fil d'ex�cution, le cadre de la m�thode en cours d'ex�cution. Ce cadre est appel� le cadre courant, et sa m�thode, la m�thode courante. La classe dans laquelle la m�thode courante est d�finie est la classe courante.
Un cadre n'est plus courant si sa m�thode appelle une autre m�thode ou si sa m�thode se termine. Quand une m�thode est appel�e, un nouveau cadre est cr�� et devient le cadre courant lorsque le contr�le est transf�r� � la nouvelle m�thode. Au retour de la m�thode, le cadre courant retransmet le r�sultat de sa m�thode au cadre pr�c�dent '-�s'il existe�-. Le cadre courant est alors supprim� et le cadre pr�c�dent redevient le cadre courant.
II-G-1. Variables locales▲
Chaque cadre contient un tableau de variables nomm� variables locales. La taille du tableau est d�termin�e lors de la compilation (nous y reviendrons dans une partie ult�rieure).
Les variables locales sont adress�es par index comme n'importe quel tableau d'un langage de programmation standard. L'index de la premi�re variable locale est z�ro et celui de la derni�re est �gal � la taille du tableau moins un.
La JVM utilise les variables locales pour passer des param�tres � la m�thode appel�e. Lorsqu'une m�thode de classe (statique) est appel�e, tous les param�tres sont stock�s dans les variables locales de mani�re cons�cutive � partir de l'index z�ro. Lorsqu'une m�thode d'instance est appel�e, la variable � l'index z�ro est toujours une r�f�rence de l'objet (this) sur laquelle la m�thode a �t� appel�e. Les param�tres sont quant � eux stock�s de mani�re cons�cutive � partir de l'index un.
Les variables locales sont aussi utilis�es pour stocker des r�sultats partiels.
II-G-2. Pile d'op�randes▲
Chaque cadre contient une pile Last In First Out (LIFO) nomm�e pile d'op�randes. La taille maximum de la pile est d�termin�e lors de la compilation (nous y reviendrons aussi dans une partie ult�rieure). La pile d'op�randes est vide lorsque le cadre la contenant est cr��.
Chaque entr�e de la pile peut contenir une valeur de n'importe quel type connu de la JVM.
II-G-3. Liaison dynamique▲
Chaque cadre contient une r�f�rence pointant vers le pool de constantes d'ex�cution pour que le type de la m�thode courante supporte la liaison dynamique du code de la m�thode. En d'autres termes lorsqu'une m�thode d'une classe A fait r�f�rence � une classe B, dans un fichier .class le lien entre A et B est symbolique. La liaison dynamique traduit cette r�f�rence symbolique en une r�f�rence concr�te, chargeant si n�cessaire la classe B et traduisant les diff�rents acc�s � cette classe (champs, m�thodes d'instance, etc.) par des offsets permettant de localiser leur position en m�moire.
Notes�:
Dans le cadre correspondant � la m�thode main(), la variable � l'index 0 (ra) correspond � une r�f�rence au tableau pass� en param�tre (nomm� ��a�� ici).
vl0 et vl1 correspondent aux variables locales d'index 0 et 1.
Si certains points vous semblent encore obscurs, normalement tout devrait devenir plus clair dans les prochaines parties. Nous aborderons notamment le cas de la surcharge/red�finition d'une m�thode.
II-H. What's next�?▲
Dans la prochaine partie, nous nous int�resserons � un outil nomm� Plume que nous utiliserons au cours des prochains articles. Plume est un assembleur/d�sassembleur de bytecode, qui -�comme Jasmin�-permet d'�crire un fichier au format texte en utilisant une syntaxe proche de celle d�crite dans la sp�cification de la machine virtuelle Java pour le transformer en un fichier .class. Plume peut aussi �tre utilis� comme ASM pour cr�er du bytecode � la vol�e en Java, le charger � l'aide d'un chargeur de classes et l'ex�cuter.
Plume ayant un objectif �ducatif, pour son impl�mentation -�que nous �tudierons�- la simplicit� du code a �t� privil�gi�e face aux performances.
