InfoQでも以前に報告したように，Java 7 Update 40以降のリリースでは，Mission ControlとFlight RecorderがJDKに同梱される。Mission Controlはモニタ，管理，トラブル対応といった作業の出発点であり，Flight Recorderはプロファイリングデータの収集や評価を行う機能である。いずれもJRockitが提供していたツールだ。Mark Reinhold氏が2010年のWebキャストでHotSpotへの移植について言及していたが，それが実現したということになる。またJavaOne 2011では，Mission ControlチームのリーダであるMarcus Hirt氏からも発表されていた。今年のJavaOneではMarcus Hirt氏とStaffan Larsen氏が，複数のセッションで各ツールの機能と使用方法を紹介していた。Mission Controlのバージョンは5.2.0だが，HotSpot用としては初めてのリリースなので，Hirt氏としては事実上の1.0.0リリースだと考えている。
Mission Control
Mission Controlは，機能的にはJVisual VMとほぼ同等である。どちらのツールもローカルあるいはリモートのJavaプロセスに接続して，JMXデータを収集する。Mission ControlはJava Discovery Protocolを使用して実行中のリモートJVMの自動検出をサポートするが，その機能を利用するためには，JVM起動時に "-Dcom.sun.management.jmxremote.autodiscovery=true -Dcom.sun.management.jdp.name=JVM_Name" というオプション指定が必要だ。
Mission ControlにはJVisual VMと同様のプラグイン機構があり，カスタマイズが可能だ。ただし，収集されるデータ毎に新たなビューを作成できる点がVisualVMとは違う。現時点では，Collectionの非効率な利用を検出するJOverflow Heap Analyzeと，DTraceプロファイルを収集するDTrace Recorderという２つのプラグインが試験的に提供されている。Mission Controlには，コア機能としてJMXブラウザが用意されているなど，全体としてJVisual VMよりも少し強力な機能が用意されている。例えばスレッドモニタによって，スレッド毎のアロケーション情報やオン・ザ・フライのスタックトレースなどが取得できる。Mission ControlはEclipseプラットフォームがベースなので，JDK内でのスタンドアロンのツールとしてのみでなく，Oracle Mission Control Update Site からEclipseプラグインの形で入手することも可能だ。
Flight Recorder
JVMのデバッグ情報，特にパフォーマンスデータを収集しようとするツールは，JVMPI/JVMTIインターフェースの実装が必要だった。さらにほとんどのプロファイラは，開発時には有効に機能しても，実運用時の評価に十分な低オーバーヘッドで動作させることは難しかった。
Flight Recorderは，CPU時間やオブジェクト割り当てのプロファイルなどの機能を，JVM内にイベントベースで直接実装した独自の監視インターフェースを利用して，最小限のオーバーヘッドで提供する。この新しいインターフェースによって，例えばスレッドをセーフポイントにする必要のないサンプリングが可能になり，計測に伴うオーバーヘッドやスキューの低減を実現している。ただし少数ではあるが，BCI(Byte Code Instrumentation)を使用するイベントが存在するため，実行コードへの影響は皆無ではない。このキャプチャ技術の大部分は新たに開発されたもので，サードパーティは利用できない。Flight RecorderはJVM内でローカルにデータを記録するが，オフ・ヒープであるため，メモリ特性あるいはガベージコレクションには影響しない。またデータの永続的な保持を設定した場合には，定期的にファイルへのダンプが行われる。
収集データはおもに４種類のイベントで構成される:発生時に記録される "instant"，プールされる "requestable"，時間間隔を表現する "duration"，そして "duration" と同じだがデータをフィルタする際のしきい値として使用される "timed" である。さらに，前もって定義された２タイプの設定が用意されている：常時実行を意図した "continuous" と，より多くのデータを短期間収集する "profiling" である。いずれにおいても，イベントによる明示的なものを除けば，オーバーヘッドは極めて低く抑えられている。
JVMが生成するイベント以外に，フレームワークやアプリケーションサーバも独自のイベントを提供することが推奨されている。現時点でインターフェースのサポートはないが，WeblogicとGlassfishがすでにイベントの実装を提供しているので，基本的にはこれがインターフェースのデファクトということになる。Marcus Hirt氏が Using the (Very Unsupported) Java Flight Recorder API と題した自身のブログで，そのAPIの使用方法に関するインストラクションを提供している。基本的な手順は，該当するEventクラスを拡張して，値を示すようにアノテートし，イベントを生成するコードからそれを呼び出す，というものだ。カスタムイベントも他のイベントと変わることはなく，ダッシュボードの生成に使用したり，他のイベントとともにグラフ化したりすることができる。今回のリリースの重要部分についての詳細は，氏の別のブログに紹介されている。
ライセンス
Flight Recorderを使用するには，サーバVMを -XX:+UnlockCommercialFeatures -XX:+FlightRecorder というオプションで起動することが必要だが，このことがすでに，新機能にライセンスが必要であることを示している。ただし技術的なチェックはされていないので，ライセンスファイルが動作上必須という訳ではなく，ライセンスとしてJava SE AdvancedあるいはJava SE Suiteが必要だという，どちらかと言えば契約上の合意というべき性質のものだ。Oracle Price Listによれば，これらは実運用システムにおいて，プロセッサあたりそれぞれ5,000/15,000米ドルである。テストあるいは開発システムにはライセンスは不要だが，UnlockCommercialFeaturesフラグの指定は依然として必要だ。Mission Controlについては，ライセンスの要否は明らかではない。プロセッサ単位のライセンスが問題になるような実運用システムで実行するものではないので，OpenJDK VM上での無償使用が可能になるかも知れない。いずれにせよ，Oracleが状況を明確にしてくれることを願いたい。
今後について
Mission ControlとFlight RecorderがHotSpotに提供された今，開発の中心はMemory Leak Detectorなどのプラグイン開発や，ツールによるパフォーマンス問題の自動検出を実現するヒューリスティックスの構築へと移行している。Mission Controlと機能的に重複するJConsoleやVisualVMの今後についても議論されている。それらのツールがOpenJDKの一部である一方で，Mission Controlがそうではないことが議論の中心になりそうだ。VisualVMによってJConsoleが棚上げになった時と同じ手法をOracleが選択するならば，JConsoleとJVisual VMはそのままに置かれて，開発の中心がMission Controlに移るということかも知れない。Jack Shirazi氏は，自身の執筆するJava Performance Tuningニュースレターで，JConsoleは破棄されることになるかもしれない，と推測している。またKirk Pepperdine氏はMission Controlについて，VisualVMのようにNetbeansプラットフォームに移行するだろう，とコメントしているが，MarcusがInfoQに語ったところでは，そのような計画はないということだ。