Do You Really Get Memory ? – Jevgeni Kabanov

Cette présentation a été faite à Paris lors de la What’s Next 2011 par Jevgeni Kabanov qui est fondateur et directeur technique de ZeroTurnaround.

C’est aussi l’homme qui parle plus vite que son ombre ce qui rendait la présentation assez difficile à suivre 🙂

Derrière la JVM dans l’architecture même de nos ordinateurs, le problème vient des données et notamment de la mémoire. La gestion de la mémoire par la JVM est bien plus complexe que ce que le développeur voit. C’est pour cette raison que beaucoup de hacks intelligents ne fonctionne pas.

Il présente le cœur (core)  d’un processeur qui se partagerait la mémoire sous forme d’une classe Java. Un core est une boucle infinie qui prend les instructions, les executent et gére les interruptions. Il utilise de même une classe Java pour représenter un processeur i5, les registres et la mémoire. Les fonctions de cette dernière sont synchronisées.

Ceci veut dire qu’avec nos architectures multicoeurs actuelles tout est synchronisé.

Il présente aussi les caches qui sont associés à un coeur, bien plus performant que la mémoire mais aussi bien plus petit.

Comment le cache fonctionne s’il y a plusieurs coeurs ?

Si la récupération des données en cache est basique (le get), il faut se poser la question du set : doit on écrire directement en mémoire ou non ?

Soit le cache attend un ordre direct avant de reporter ses données en mémoire, soit il place les écritures en mémoire dans une liste d’attente. Il y a différents protocoles qui essayent de trouver la meilleur solution pour associer ce choix et la cohérence des caches.

Malgré ça, il n’est pas sur qu’un thread sur un cœur voit la même chose qu’un autre thread sur un autre cœur. De plus les accès en mémoire sont trop lents.

Au niveau du système d’opération, il y a le paging qui permet d’augmenter la mémoire en mettant une partie de celle-ci sur le disque en fonction de son utilisation. Cependant la lecture sur disque étant extrêmement lente et le garbage collector parcourant très régulièrement l’ensemble des données (heap) du programme, il est parfois préférable en terme de performance de désactiver ce paging système même si on doit être à court de mémoire vive.

Il explique le mot clé Volatile qui garantie la synchronisation d’une variable dans plusieurs threads.  En indiquant que la variable est volatile, on oblige la JVM à rafraîchir son contenu à chaque fois qu’elle est utilisée. Il garantit que les caches sont cohérents. Ainsi chaque thread a accès à la valeur la plus récente de la variable.

D’où la complexité de la mise en place de Volatile au niveau JVM.  La JVM génère la synchronisation par des barrières mémoires.

Il parle ensuite la gestion de la mémoire par la JVM (heap) dont le principal objectif est de gérer les objets vivants (accessible de la « racine ») des objets morts (qui ne sont plus référencés par aucun objet vivant). Les principaux problèmes sont la complexité O(heap) et le fait de devoir stopper l’application.

Il présente différents algorithmes ( Mark and Sweep, Mark Compact, Parallel MC, Concurrent MS ).

Avec Java 7 apparait Garbage First qui sépare la heap en régions ().

Il présente enfin l’algorithme de Garbage Collector encore plus novateur de Azul Zing qui est sans pause.

Une présentation clairement très technique 😀

2 réflexions au sujet de « Do You Really Get Memory ? – Jevgeni Kabanov »

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *