JProfiler がヒープダンプを AI エージェントにとって有用なものにする
JProfiler 16.3 では、MCP サーバーを通じて、JProfiler の主要なすべてのサブシステムを AI エージェントから利用できるようになりました。その中で最も有用な追加機能のひとつがヒープダンプ分析です。エージェントはヒープ内のオブジェクトを調べ、その参照をたどり、ガベージコレクションされなかった理由を突き止められるようになりました。
ランタイムデータがなければ、AI エージェントはどのオブジェクトが生存しているのか、何がそれらを到達可能な状態に保っているのかを知ることができません。JProfiler がそのギャップを埋めることで、エージェントは実際の証拠から分析を始め、それを手がかりに関連するソースコードを見つけられるようになります。
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倍以上に高速化した経緯と、プロファイリングを開始する理由がもはや必要なくなった理由を解説します。
Claudeがコードを読むだけでは決して見つけられなかったホットスポット
CommaFeedは私が日々使っているRSSリーダーです。オープンソースとして公開されており、作者自身がcommafeed.comで無料の公開インスタンスを運営しています。フィードを更新するたびに、処理を行ってくれているのは他人のサーバーです。そこで、その処理は実際にはどこに費やされているのだろうと考え、Claude CodeとJProfiler MCPをCommaFeedに向けてみました。
その結果、データベースの最適化がCommaFeedにマージされました。修正自体は複雑なものではありませんでしたが、ソースコードだけからClaudeがこの解決策に辿り着くことは決してなかったでしょう。後から尋ねてみたところ、Claude自身もそう認めました。自然な最初の試みでは、間違った箇所を修正してしまったはずだというのです。以下では、JProfiler MCPサーバーに接続したClaude Codeが、好奇心の段階からマージされたPRまで私をどのように導いたかを読み進めてください。
JProfiler 16.1: AIエージェントがJavaアプリケーションをプロファイリングできるようになりました
JProfiler 1.0以来、プロファイリングは開発者がGUIで行う作業でした。セッションを開始し、ビューを操作し、データを解釈します。実際には、パフォーマンス分析が行われるのは、コンテキストの切り替えに見合うほど問題が深刻な場合だけでした。その結果、多くの問題は一度もプロファイリングされないまま本番環境にリリースされていました。
JProfiler 16.1では、プロファイリングの仕組みを変えます。AIコーディングエージェントが、Javaアプリケーションのプロファイリング、結果の分析、そしてそれに基づく対処を行えるようになるのです。これは、私たちが開発を始めて以来、開発者によるプロファイリングの使い方における最大の変化です。
新しいJProfiler MCPサーバーは、@ej-technologies/jprofiler-mcp npmパッケージとして提供され、Model Context Protocolを通じてJProfilerのプロファイリング機能とヒープ分析機能を公開します。Claude Code、Cursor、Codex、Gemini CLI、およびその他のMCP互換のAIコーディングツールで利用できます。