La communauté Java francophone s’est une nouvelle fois donné rendez-vous au sommet de la tour MARGO pour une édition exceptionnelle du Paris JUG. Une soirée placée sous le signe de la performance, des entrailles de la JVM et du plaisir de se retrouver entre passionnés.
En tant que partenaire Platinum, nous avons eu le plaisir d'accueillir plus de 50 participants au sein de nos locaux pour explorer les mécanismes de gestion mémoire qui feront le Java de demain.
Replay 1
G1, ZGC, Shenandoah : Quel GC choisir ?
Replay bientôt disponible →
Replay 2
Projet Lilliput & Object Headers
Replay bientôt disponible →
Une soirée d'expertise au cœur de la JVM
Dès 19h, les échanges ont débuté autour des enjeux de performance et d'optimisation des infrastructures Java modernes. La soirée a été rythmée par deux talks de haut vol décryptant le présent et le futur du langage.
La jungle des Garbage Collectors – Antoine Dessaigne
Antoine nous a plongés dans les mécanismes internes de G1, ZGC et Shenandoah. Loin d'être une simple affaire de configuration, le choix du GC est aujourd'hui un levier stratégique dans des environnements Cloud où le coût de la mémoire est roi.
Il a notamment détaillé les spécificités du ZGC générationnel, conçu pour réduire les temps de pause (Stop-The-World) à moins d'une milliseconde, même sur des heaps de plusieurs téraoctets. L'enjeu exposé est clair : trouver l'équilibre parfait entre latency (réactivité) et throughput (capacité de traitement) selon vos contextes d'exécution.
Projet Lilliput : Optimiser l'en-tête des objets – Achraf Hasbi
Achraf a analysé l'organisation physique des objets dans la heap. Chaque objet Java possède un "en-tête" (Object Header) contenant des métadonnées indispensables (lock, hashcode, GC state), mais dont la taille impacte directement l'empreinte mémoire globale.
À travers une démonstration de la bibliothèque JOL (Java Object Layout), il a illustré l'apport du Projet Lilliput (JEP 450 et 519). L'objectif est de réduire cet en-tête de 128 à 64 bits. Sur des applications manipulant des millions d'objets, ce gain peut représenter une réduction de 10% à 20% de l'occupation de la heap, sans modifier une seule ligne de code métier. Un levier massif pour la scalabilité des infrastructures Java.
Un carrefour d'échanges pour la communauté Java
Au-delà de la technique, cette soirée a été marquée par une convivialité propre au Paris JUG. Entre les deux sessions, les participants ont pu profiter d’un moment de networking autour de pizzas , favorisant des échanges passionnés entre experts et curieux. Nous avons eu l'honneur de compter parmi nous des figures majeures de l'écosystème, telles qu'Antoine Dessaigne et Rémi Forax, contributeur historique au langage Java. Pour MARGO, recevoir de tels profils est une occasion précieuse de confronter nos pratiques aux évolutions profondes du standard et de nourrir notre culture d'excellence.
La soirée s'est conclue sur une note ludique : Achraf a mis au défi l'assemblée avec un quiz technique. Félicitations aux trois gagnants qui sont repartis avec leurs cadeaux, et mention spéciale à nos deux consultants MARGO qui ont réussi à se hisser sur le podium dans ce contexte de haute compétition !
MARGO et la communauté Java : une passion partagée
Accueillir le Paris JUG est pour MARGO l’opportunité de soutenir l'écosystème Java et de favoriser l'excellence technique au sein de notre communauté de consultants.
- Valoriser l'expertise R&D de nos consultants (Practice Java) ;
- Contribuer activement aux échanges de la communauté open source ;
- Offrir un lieu d'échange unique pour les ingénieurs passionnés.
Cette édition confirme notre engagement : l'innovation technologique passe par le partage de connaissances.
Merci à Mathieu et toute l'équipe du Paris JUG pour leur confiance. Ces moments de partage font vivre notre culture d’excellence.
Vous êtes expert Java ou passionné par la JVM ? Rejoignez l'aventure.
Découvrez nos opportunités !
Aller plus loin : (re)découvrez nos articles techniques
L'expertise Java chez MARGO s'inscrit dans la durée. Retrouvez l'analyse complète d'Achraf Hasbi sur le blog pour approfondir les sujets abordés lors du meetup et découvrir nos retours d'expérience en production.
Pourquoi existe-t-il autant de Garbage Collectors (GC) différents en Java ?
Il n'existe pas de "meilleur" GC universel car chaque application a des besoins différents. Le choix d'un GC est un arbitrage entre trois facteurs : la latence (réduire les pauses "Stop-The-World"), le débit (quantité de travail utile par seconde) et l'empreinte mémoire. Par exemple, le ZGC est idéal pour les très faibles latences, tandis que G1 est un excellent compromis pour la plupart des usages serveurs.
Qu'est-ce que le "ZGC Générationnel" et quel est son avantage ?
Le ZGC (Z Garbage Collector) est conçu pour des pauses quasi-nulles. Sa version "générationnelle" sépare les objets jeunes (qui meurent vite) des objets vieux. Cela permet au GC de nettoyer la "jeune génération" plus souvent et plus rapidement, ce qui réduit considérablement la consommation de ressources CPU et améliore l'efficacité globale par rapport à un ZGC non-générationnel.
En quoi consiste concrètement le Projet Lilliput ?
Lilliput vise à réduire la taille de l'en-tête des objets Java (le Object Header). Actuellement, chaque objet possède un en-tête de 128 bits pour stocker des métadonnées (verrous, hashcode, état du GC). Lilliput, via les JEP 450 et 519, parvient à compacter ces informations pour tenir sur 64 bits, divisant ainsi par deux la place "perdue" par chaque objet.
Quel gain de mémoire peut-on réellement espérer avec le Projet Lilliput ?
Le gain dépend de la taille moyenne de vos objets. Pour des applications qui manipulent un très grand nombre de petits objets (comme des microservices traitant beaucoup de data en mémoire), on peut observer une réduction de 10 % à 20 % de l'occupation totale de la heap. Cela permet soit de réduire ses coûts d'infrastructure Cloud, soit de faire tourner plus de processus sur la même machine.
Faut-il modifier son code métier pour profiter de ces optimisations ?
C'est l'un des grands points forts de Java : non. Ces évolutions se situent au niveau de la machine virtuelle (JVM). Il suffit de mettre à jour sa version de Java et d'activer les bons flags au lancement pour en bénéficier immédiatement, sans aucune modification du code source.
Comment puis-je mesurer précisément l'impact de ces changements sur mes objets ?
La bibliothèque recommandée est JOL (Java Object Layout). Elle permet d'inspecter l'organisation interne de n'importe quel objet en mémoire et de voir précisément l'espace occupé par l'en-tête, les champs de données et l'alignement (padding). C’est l'outil indispensable pour valider concrètement les gains de Lilliput.
