JProfiler がヒープダンプを AI エージェントにとって有用なものにする
JProfiler 16.3 では、MCP サーバーを通じて、JProfiler の主要なすべてのサブシステムを AI エージェントから利用できるようになりました。その中で最も有用な追加機能のひとつがヒープダンプ分析です。エージェントはヒープ内のオブジェクトを調べ、その参照をたどり、ガベージコレクションされなかった理由を突き止められるようになりました。
ランタイムデータがなければ、AI エージェントはどのオブジェクトが生存しているのか、何がそれらを到達可能な状態に保っているのかを知ることができません。JProfiler がそのギャップを埋めることで、エージェントは実際の証拠から分析を始め、それを手がかりに関連するソースコードを見つけられるようになります。
HotSpotの反撃:JEP 544はGraalVMの起動時間独占を終わらせるのか?
HotSpot JVMにとってエキサイティングな時代が来ました。JEP 544: Ahead-of-Time Code CompilationがJava 28向けに提案されたばかりです。これにより、GraalVMの厄介な制約を一切伴わずに、HotSpotのAOTキャッシュがGraalVMに匹敵する起動パフォーマンスを得られることが約束されます。ただし、AOTキャッシュのトレーニングはGraalVMによる事前コンパイルとは異なるものです。では、両者は実際のところどのように比較できるのでしょうか?SBOMの義務化まであと15か月。あなたのSBOMはおそらく正しくない。
2027年12月11日から、EUサイバーレジリエンス法（Cyber Resilience Act）におけるSBOMの義務が適用されます。つまり、EUでソフトウェアをリリースしたいなら、間もなくSBOMが必要になります。これはEUに限った話ではなく、この宣言型のアプローチによってサプライチェーンセキュリティを強化する世界的な潮流です。米国では2021年から連邦政府向けソフトウェアベンダーにSBOMが義務付けられており、CISA/NSA/FBIは今年7月にSBOM最小要素の改訂版を公表しました。
SBOMを正しく作成するのは容易ではありませんし、ソフトウェアにインストーラーを付けて出荷する場合には、その難易度はさらに上がります。今、何をすべきでしょうか。見ていきましょう。
Apache Fory JSON を 4.5 倍高速化した方法
最近、Java シリアライゼーションフレームワークの比較を行っています。バイナリペイロードについては、ウェブサイトで「blazingly-fast(圧倒的に速い)」をうたっており、実際にその通りである Apache Fory の大ファンになりました。比較では、JSON とバイナリペイロードを区別しています。JSON シリアライゼーションの王者は Jackson でした(Kotlin においても同様)。一方で、バイナリペイロードでは Apache Fory が支配的でした。
最近の Apache Fory 1.7.0 リリースでは、主要な新機能として JSON サポートが追加されました。当然、興味をそそられ、シリアライゼーションのデモに Fory JSON を追加しました。自分のペイロードでの数値を見たときは、にわかには信じられませんでした。Fory は実際に Jackson より 2.8 倍遅かったのです。何かがおかしい。そこで、根本原因を突き止めることにしました。
Java vs. Kotlin: どちらが(デ)シリアライズをより高速に行えるのか?
前回の記事では、Javaのシリアライズフレームワークをプロファイリングし、Apache ForyがJavaシリアライズおよび他の競合を大きく引き離していることを確認しました。これを受けて、Kotlinのフレームワーク同士を比較するとどうなるのかという問いに関心が集まりました。Kotlinエコシステムには独自のシリアライズライブラリがあり、とりわけコンパイル時コード生成を行うJetBrains公式ライブラリのkotlinx.serializationと、KSPベースのアダプタ生成を行うMoshiが有名です。生成されたコードなら、Jacksonのようなリフレクション中心のJava陣営を確実に上回るのではないでしょうか?
それを確かめるために、比較プロジェクトに同等のKotlinデータモデルを追加し、JProfilerでラウンドトリップをプロファイリングしました。その答えは、モデルクラスの言語はそれほど大きな影響を与えないというものです。ただし、実に驚くべき発見もいくつかあります。
なぜApache Foryはこれほど高速なのか? 5つのJavaシリアライズフレームワークをプロファイリング
JDKの設計者たちがJavaシリアライズをひどく嫌っているのは、周知の事実です。シリアライズはセキュリティ上の悪夢であり、新しい言語機能が追加されるたびにその実装を大幅に複雑にしたうえで、動作も非常に遅い。だからこそ、他のシリアライズフレームワークが存在するのです。そんな中、印象的なパフォーマンスを謳う新顔が登場しました。Apache Foryです。このブログ記事では、旧名(かつては「Fury」)にふさわしい性能を持つのかを確かめ、既存のフレームワークと比較します。
比較にあたっては、現実的なオブジェクトグラフのシリアライズとデシリアライズのラウンドトリップを、5つの異なるフレームワークでプロファイリングしました。
- Javaのシリアライズ
- Kryo
- Apache Fory
- JSONとCBORの両方のバックエンドを備えたJackson
このプロファイリングデータは、Apache Foryがなぜ首位に立つのかを説明するとともに、Javaシリアライズが行っていることの大半はシリアライズではないことも明らかにしています。
jvmguard 登場:本番環境での自動プロファイリング
JProfiler の開発チームから新しいオープンソースツールが登場しました。jvmguard は、組織における本番環境の JVM プロファイリングを支援します。
本番環境でのプロファイリングはリスクを伴いますが、それが問題を理解するための唯一の手段であることも少なくありません。jvmguard を使えば、プロファイリングによるキャプチャは承認と監査の対象となり、人間、自動トリガー、AI エージェントのいずれからでも開始できます。
jvmguard は JProfiler と連携しますが、その統合に限定されるわけではありません。JFR スナップショット、HPROF ヒープダンプ、スレッドダンプも記録でき、それらは他のツールで分析できます。jvmguard の基本的な考え方は、軽量シグナルは常にオンであり、ディープキャプチャは特定の条件下でのみ実行される、というものです。
JProfiler MCPサーバーを弱いモデルに対して堅牢にする
フラッグシップモデルは、すべてのコーディングタスクに理想的というわけではありません。この種のモデルは低速で、コストも非常に高くつきます。そのため、多くのタスク、特に雑務は、より機敏に動いてわずかなコストでタスクをこなす下位ティアのモデルの方が適しています。ただし、こうしたモデルのツール呼び出しの挙動は、最上位モデルのそれよりも不安定になりがちです。
JProfiler 16.1では、AIコーディングエージェントがJavaアプリケーションのプロファイリングとその結果の分析を行えるようにするためのMCPサーバーを追加しました。お客様からは多くの好意的なフィードバックをいただいており、今後のリリースでこの分野をさらに拡充していく予定です。
初回リリースでは、テストは主にClaude Codeを用いて行われていました。JProfiler 16.2では、MCPサーバーを他のAIモデルに対してはるかに堅牢なものにしました。他のモデルがどのような間違った動作をしたのか、そしてプロファイリングのワークフローをそれらの弱点に対してどのように堅牢化したのか、以下で解説します。
JProfiler 16.2: コマンドラインからのプロファイリング
JProfiler 16.2では、オフラインプロファイリングがはるかに便利になりました。「オフラインプロファイリング」とは、JProfilerのGUIを使わずにプロファイリングを行うモードです。CIサーバー、コンテナ、本番システムで役立ちます。以前のJProfilerのバージョンでは、プロファイリング設定は、JProfilerのGUIからエクスポートした設定ファイルを使って、コマンドライン経由でエージェントに伝える必要がありました。その後、記録コマンドはController API、JProfiler MBean、または「jpcontroller」コマンドラインユーティリティを経由して実行する必要がありました。
多くの場合、このワークフローは不必要に複雑です。そこで今回、最も一般的なプロファイリング設定と単純な自動記録シーケンスをコマンドラインで直接設定できる実用的なアプローチを導入しました。-agentpath VMパラメータ、jpenableアタッチツール、およびGradleとAntのプロファイリングタスクで利用できます。これは自動化タスクにとって大きな簡素化であるだけでなく、コマンドラインに新たに加わった住人であるAIエージェントにも大きなメリットをもたらします。
JProfiler MCPでjclasslibのパフォーマンスを2倍にした方法
最近、私はオープンソースのJVMバイトコードビューアであるjclasslibのパフォーマンスを、Codexとプロファイリングエージェントを使って改善しました。特定の痛みの種があったからではなく、JProfiler 16.1に搭載された私たちのMCPサーバーを試してみたことがきっかけです。以下では、エージェントがクラスファイルの読み込みを2倍以上に高速化した経緯と、プロファイリングを開始する理由がもはや必要なくなった理由を解説します。