La Java Virtual Machine (abrégé JVM, en français machine virtuelle Java), bien connu des développeurs Java, permet d’interpréter et d’exécuter le bytecode. L’intérêt de la JVM est de permettre la portabilité des langages qu’elle supporte, c’est à dire qu’elle permet leur fonctionnement sur n’importe quelle plateforme.

Comment elle fonctionne précisément ?

Les différentes zones mémoires

Voici l’aperçu d’un JVM (HotSpot de Sun):

On peut constater que la JVM est composées de différentes zones. Celle-ci peuvent se regrouper en 2 grandes catégorie: la PERM et la HEAP:



PERM

Au chargement de l’application, l’ensemble des classes (.class) sont chargées dans cet espace mémoire. La JVM utilisera ensuite les classes chargées dans cet espace pour créer les instances leurs instances dans la HEAP.

HEAP

La HEAP est composée de 2 générations d’objets:

1. YOUNG GENERATION: Cette catégorie représente les nouveaux objets, elle se s’organise en 3 zones:

• TO: cette zone accueille les objets déplacés de la FROM. Lorsqu’un GC  a lieu et que cette zone est pleine, les objets en vie sont déplacés dans la zone OLD.
• FROM: cette zone accueille les objets déplacés de la EDEN. Lorsqu’un GC a lieu et que cette zone est pleine, les objets en vie sont déplacés dans la zone TO.
• EDEN: les nouveaux objets sont créés dans cette zone. Lorsque celle-ci atteint sa taille maximum, un premier Garbage Collector (GC) (minor GC) déplace les objets en vie (liés à d’autre objets) dans la zone FROM.

2. OLD GENERATION: Cette catégorie accueille les objets toujours en vie après les garbage successifs.

Fonctionnement du Garbage Collector

La JVM est composée de différentes zone mémoires et son fonctionnement peut s’apparenter à un système de vases communicants. Les objets, créés une première zone, sont déplacés au fur et à mesure dans les zone suivantes lorsque une des zone atteint son seuil maximum. Ce système est appelé le Garbage Collector. On peut distinguer 2 types de garbages collector le majeur et mineur.

Minor garbage collector

Quand un nouvel objet est alloué sur le tas, la JVM le créee dans la zone EDEN. Lorsque cet espace atteint sa taille maximum, la JVM lance un Garbage Collector appelé minor collection. Cette opération consiste à parcourir tous les objets de l’EDEN et les flager selon 2 critères:

Objets vivants (live objects): les objets vivants sont ceux ayant des références vers d’autres objets.

Objets orphelins (orpheans): les objets orphelins (ceux n’ayant aucune référence).

Le minor garbage collector, supprime alors les orphelins et déplace les objets en vie de la zone Eden vers la zone From.

Cette opération est répétée à chaque fois que la zone Eden est pleine. Si la zone From est pleine, les objets sont  déplacés vers la zone To.

L’avantage majeur de cet algorithme réside dans sa vitesse d’exécution ( de 1/100 à 1/10 de seconde) car il n’y a pas de libération de la mémoire à proprement parler. En pratique la JVM change juste un pointeur sur les objets en vie. Après une minor collection, l’EDEN et un survivor space sont considérés comme libres. Le travail de copie est pour sa part favorisé par une caractéristique des JVM actuelles qui implique que l’ensemble du HEAP ne forme qu’un seul segment continu de mémoire. Au fil des minor collections, les objets restés en vie passent d’un survivor space à l’autre.

Major garbage collector (Full GC)

Nous avons vu plus haut que les minor garbage collections, réorganisait l’espaces mémoire de la YOUNG GENERATION qui se remplie au fur et à mesure. Lorsque celle-ci sature, la JVM a besoin de libérer de la mémoire. Elle va alors invoquer un major garbage collector appelé Full GC. Cette opération est très coûteuse, nous allons voir pourquoi.

La JVM va stopper l’ensemble des threads courant pour faire l’analyse complète de la mémoire. Elle détermine les objects à supprimé (orpheans) et ceux qui doivent subsister. Elle opère ensuite une recopie de ces objets de la zone Young à la zone Old (ou tenured).

Cette opération est appelée un « stop the word collection » pour son besoin de tout arrêter. Elle est très coûteuse (jusqu’à plusieurs secondes) également en processeur car pour faire ces opération de coup de balai (suppression/copie). ON comprends qu’il faut essayer de la minimiser au maximum..

Nous verrons dans un prochaine article comment optimiser la JVM et (surtout) notre code pour éviter ces recopie couteuses.

Pour obtenir des performances idéales, il est préférable de configurer la JVM pour éviter des copies inutiles du young space au tenured.