Nouveauté Java 25 (15/18) - JEP 518 : JFR repense le sampling pour plus de stabilité JFR résout un dilemme vieux de vingt ans : comment profiler sans crash ? Cette refonte technique majeure abandonne les heuristiques risquées pour un sampling coopératif. La JEP 518: JFR Cooperative Sampling redesigne complètement le mécanisme d'échantillonnage des piles d'exécution pour éliminer les plantages JVM. Le problème fondamental ? JFR doit parser les piles de threads pour créer des profils, mais les métadonnées nécessaires ne sont valides qu'aux safepoints. Échantillonner uniquement aux safepoints introduit un biais statistique majeur - certains codes fréquents n'étant jamais près d'un safepoint. La solution actuelle échantillonne de manière asynchrone avec des heuristiques de parsing dangereuses. Ces heuristiques peuvent mal interpréter les piles et crasher la JVM, malgré des mécanismes de protection qui échouent parfois. Java 25 adopte une approche coopérative élégante. Le sampler suspend le thread cible, enregistre juste son program counter et stack pointer dans une requête d'échantillonnage, puis reprend le thread. Le thread continue normalement jusqu'au prochain safepoint, où il traite la requête en sécurité. Cette approche élimine les heuristiques risquées tout en minimisant le biais safepoint grâce à des ajustements statistiques. Le sampler a moins de travail, le parsing est plus simple, et la scalabilité s'améliore. Seule limitation : le code natif continue d'utiliser l'ancien mécanisme, mais JFR gagne en stabilité globale. #Java25 #JEP518 #Java #JFR #Profiling #Sampling #Stabilité #Safepoint #HotSpot #Oracle #OpenJDK #DéveloppeurJava #Monitoring