Depuis la sortie de Java 7 Update 40, Mission Control et Flight Recorder sont fournis avec le JDK, comme l'annonçait InfoQ il y a quelques semaines. Mission Control est le point d'entrée pour la supervision, la gestion et la détection des anomalies alors que Flight Recorder permet de collecter et d'étudier les données issues du profiling. Les deux outils étaient disponibles pour JRockit et sont maintenant compatibles avec HotSpot après avoir été insinué par Mark Reinhold dans un webcast en 2010 et annoncé officiellement par le chef de projet de l'équipe Mission Control, Marcus Hirt, à JavaOne 2011. Lors de plusieurs présentations à la JavaOne de cette année, Marcus Hirt et Staffan Larsen ont présenté leur fonctionement et leurs utilisations. La version de Mission Control est la 5.2.0 mais comme c'est la première version disponible pour HotSpot, Marcus Hirt préfère le terme de version 1.0.0.
Mission Control
Mission Control propose les mêmes fonctionnalités que JVisual VM. Les deux outils permettent de se connecter à des processus Java locaux ou distants pour collecter les données JMX. Mission Control supporte la détection automatique de processus JVM distants à travers le protocole Java Discovery Protocol. Pour l'utiliser, la JVM doit être démarrée avec les options -Dcom.sun.management.jmxremote.autodiscovery=true -Dcom.sun.management.jdp.name=JVM_Name.
Comme JVisual VM, Mission Control a un mécanisme de plugins afin de le personnaliser. Mais contrairement à VisualVM, Mission Control peut créer de nouvelles vues des données collectées. Deux plugins expérimentaux sont disponibles aujourd'hui, JOverflow Heap Analyzer pour détecter les usages inefficaces des Collections et DTrace Recorder pour mettre en corrélation les profiles DTrace. Mission Control a un navigateur JMX intégré dans ses fonctionnalités de base et offre des fonctionnalités légèrement plus puissantes dans tous les domaines. Mission Control est construit sur la plate-forme Eclipse et n'est donc pas uniquement disponible en tant qu'outil autonome, mais peut être obtenu en tant que plugin Eclipse sur l'Update Site d'Oracle Mission Control.
Flight Recorder
Les outils souhaitant collecter des informations de débug et de performance hors de la JVM doivent implémenter les interfaces JVMPI/JVMTI. Alors que la majorité des profilers fonctionnent correctement lors de la phase de développement, il est difficiele de les faire fonctionner en production avec un coût sur les performances très faible.
Flight Recorder apporte des fonctionnalités telles que le profiling de temps CPU ou d'allocation d'objets avec un coût minimal en implémentant ses propres événements basés sur les interfaces de monitoring directement dans la JVM. Ces nouvelles interfaces permettent l'échantillonnage des threads sans être à un safepoints, réduisant ainsi la perte de performance et sans fausser les mesures. Il n'y a que quelques événements qui utilisent une instrumentation du bytecode et qui ont donc un impact sur le code en cours d'exécution. La plupart des technologies de capture sont nouvelles et pas accessibles à des tiers. Flight Recorder enregistre les données dans la JVM mais hors de la heap, il est donc sans incidence sur la mémoire ou le garbage collector. Quand il est configuré pour conserver les données, elles sont périodiquement enregistrées dans un fichier.
Les données collectées sont principalement classées en 4 types d'événements : "instant", qui sont enregistrés quand ils se produisent, "requestable", qui sont interrogés, "duration", qui représente une métrique d'un timespan et "time", qui est identique à "duration" mais qui applique des seuils pour filtrer les données. Il y a deux configurations prédéfinies : "continous", qui est destinée à toujours fonctionner et "profiling", qui collecte plus de données et est destinée à une analyse à court terme. La surcharge est cependant toujours très faible à moins qu'un événement ne le stipule explicitement.
Outre les événements générés par la JVM, les frameworks et les serveurs d'applications sont encouragés à fournir leurs propres événements. L'interface n'est pas supportée actuellement, mais Weblogic et Glassfish proposent déjà des événements, qui, fondamentalement, finalisent l'interface. Marcus Hirt fournit des instructions sur la façon d'utiliser l'API sur son billet de blog Utiliser l'API Java Flight Recorder. Les principales étapes consistent à étendre la classe Event, l'annoter pour indiquer les valeurs et l'appeler à partir du code qui produit l'événement. Les événements personnalisés ne sont pas différents des autres événements et peuvent être utilisés dans la création de tableaux de bord et parallèlement à d'autres événements. Plus d'informations sur les principaux points de cette version peuvent être trouvées dans un autre billet de blog de Marcus Hirt.
Licence
Pour utiliser Flight Recorder, la VM doit être démarrée avec l'option -XX:+UnlockCommercialFeatures -XX:+FlightRecorder. Cela indique que ces nouvelles fonctionnalités nécessitent une licence. Techniquement, il n'y a cependant pas de contrôle et un fichier de licence ne doit pas exister. Au contraire, la licence est un accord contractuel, qui nécessite Java SE Advanced ou Java SE Suite, qui sont au tarif de 5k/10k USD par processeur pour une utilisation en production. Les systèmes de tests ou de développement n'ont pas besoin de licence, mais ont cependant toujours besoin du flag UnlockCommercialFeatures. Il n'est pas certain que Mission Control nécessite une licence. La documentation suggère qu'il peut aussi être librement utilisé avec les VM OpenJDK tant que Mission Control n'est pas en fonctionnement sur un système en production qui nécessite une licence par processeur. Espérons que Oracle va clarifier la situation.
L'avenir
Maintenant que Mission Control et Flight Recorder sont dans HotSpot, le développement se concentre sur l'ajout de plugins tel que le détecteur de fuites mémoires et de la construction d'heuristiques dans les outils, afin qu'ils puissent automatiquement signaler des problèmes de performance. Il y a eu des échanges sur l'avenir de JConsole et VisualVM, qui empiètent tous les deux sur Mission Control. Ils sont susceptibles de rester, car ils font partie de OpenJDK, contrairement à Mission Control. Si Oracle suit le même chemin qui a été pris lorsque VisualVM pouvait rendre obsolète JConsole, on peut supposer que JConsole et JVisual VM vont rester et que le développement se concentrera sur Mission Control. Jack Shirazi spécule dans sa newsletter Java Performance Tuning que JConsole pourrait être retiré, tandis que Kirk Pepperdine croit que Mission Control va migrer vers la plate-forme NetBeans, comme VisualVM. Marcus Hirt a déclaré à InfoQ que ces projets n'existaient pas.