JVM: 内部情報をお伝えします

[[361071]]

ほとんどのユーザーは、Java リフレクションの使用に精通しています。特にオープンソースフレームワークでは広く使用されています。リフレクションを通じて、Java クラスの情報を取得できます。ヒープやスレッドの使用状況、作成されたオブジェクトのメモリアドレスやロードされたクラスの内容など、JVM の内部情報についてはどうでしょうか。

実際、JVM には、上記のような、人生における内部メッセージに似た内部情報が多数存在します。一部の大規模なアプリケーションでは、API 認証を通じてのみ一部のユーザーデータを取得できることが想像できます。一般ユーザーが通常の使用方法でこれらのコンテンツを入手することは不可能です。 JVM 上で実行される通常の Java アプリケーションと同様に、JVM に関する情報を取得することは困難です。結局のところ、JVM はより低いレベルにあり、C++ で開発されています。

JVM はこの内部情報を教えてくれるのでしょうか?

JVM は、内部情報を公開するためのいくつかの外部インターフェースを提供します。 SA はこれらのインターフェースを通じてのみ、JVM 内部クラスの構造とアドレスにアクセスし、最下層から JVM 内部操作の詳細を観察できます。

SA グラフィカルインターフェイスで HSDB の内部を見ると、長いメニューリストが表示されます。そのほとんどには、通常の Java アプリケーションでは取得できない「内部情報」が含まれています。

これらはすべてどのように実装されるのでしょうか?これについて言えば、gHotSpotVMStructs について言及する必要があります。

JVM によって提供されるインターフェースの中核は、gHotSpotVMStructs 構造です。元のヒープアドレス、スレッドアドレス、スタックアドレスなど、JVM 内の多くの情報を公開します。

gHotSpotVMStructs 構造体は、多くのクラスとこれらのクラスのフィールド情報を指します。各クラスには一連のフィールドがあり、各フィールドには独自の名前、タイプ、静的かどうかなどが設定されます。静的フィールドの場合は、この構造を使用してその値にアクセスすることもできます。静的オブジェクトフィールドの場合、この構造体はターゲットオブジェクトのアドレスも提供します。このルートアドレスを通じて、コンパイラ、スレッド、ヒープなど、JVM 内のいくつかのコンポーネントのリバースチェックを開始できます。

したがって、JVM の内部情報を取得して理解するための鍵は、gHotSpotVMStructs 構造内のデータを解析することです。 JVM は、内部型システムのアドレスとルートオブジェクトのアドレスを公開するだけでなく、このデータを解釈するために使用される追加のシンボルと値も公開します。これには、クラスの説明情報と、このクラス内の各フィールドのオフセットが含まれます。さらに、JVM 開発者は、JVM 内の C++ クラスのフィールドを手動でマップしてグローバル gHotSpotVMStructs 構造にロードする一連の作業を実行しました。

SA はこの情報を解析する最良の例です。グラフィカルインターフェースを通じて、この情報を解析して何を学んだかを直感的に感じることができます。 gHotSpotVMStructs によって公開される情報を変換することで、Java ラッパークラスを生成できます。これらのラッパークラスによって提供されるインターフェイスにより、通常の Java アプリケーションで使用される API と同様に、JVM の内部システムに簡単かつ便利にアクセスでき、内部データへのアクセスと解析の問題が解決されます。

この情報に基づいて、他のデバッグツールや診断ツールも実装されます。

SA を使用する方法は、実際には「ptrace」システムコールを介して行われ、これにより、ターゲット JVM プロセスが一時停止され、gHotSpotVMStructs のメモリ情報の読み取りが開始されます。

上記の内容を読めば、SA がどのように機能するかが大体理解できます。このような要件がある場合、SA などのツールを使用して他のユーザーが JVM 情報を取得することを禁止しますか?

ほら、私が打ったところを指しているよ。答えは、gHotSpotVMStructs をリセットすることです。このツールではこの情報を解析できません。

Stackoverflow には、エージェントをコンパイルし、JVM の起動時にアタッチして、gHotSpotVMStructs を 0 に設定するという解決策があります。

外部 void *gHotSpotVMStructs; 
 
 int Agent_OnLoad(void *vm, char *options, void *reserved) {
    gHotSpotVMStructs = 0;
 0を返します。
 }

起動すると、JVM に接続されます。

 java -agentpath:/path/を /libnostructs.soへ...

SA ツールを再度実行すると、問題があることを示す例外がスローされます。

スレッド「main」で例外が発生しましたjava.lang.reflect.InvocationTargetException
 sun.reflect.NativeMethodAccessorImpl.invoke0 (ネイティブ メソッド)
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)で
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)で
java.lang.reflect.Method.invoke(Method.java:498)で
sun.tools.jstack.JStack.runJStackTool(JStack.java:140)で
sun.tools.jstack.JStack.main(JStack.java:106)で
原因: java.lang.RuntimeException: gHotSpotVMStructs がリモート プロセスで適切に初期化されませんでした。できない 続く 
 sun.jvm.hotspot.HotSpotTypeDataBase.readVMStructs(HotSpotTypeDataBase.java:418)で
sun.jvm.hotspot.HotSpotTypeDataBase.<init>(HotSpotTypeDataBase.java:91)で
sun.jvm.hotspot.HotSpotAgent.setupVM(HotSpotAgent.java:395)で
sun.jvm.hotspot.HotSpotAgent.go(HotSpotAgent.java:305)で
sun.jvm.hotspot.HotSpotAgent.attach(HotSpotAgent.java:140)で
sun.jvm.hotspot.tools.Tool.start(Tool.java:185)で
sun.jvm.hotspot.tools.Toolで。実行(Tool.java:118)
 sun.jvm.hotspot.tools.JStack.main(JStack.java:92)で
        ... 6件以上