Java (または少なくとも Sun の Hotspot JVM) は、長い間、非常に大きなメモリ フットプリントを持つという評判がありました。JVM にこの評判を与えているのは、正確には何なのでしょうか? 詳細な内訳に興味があります: ランタイムに使用されるメモリの量 (JIT? GC/メモリ管理? クラスローダー?) JNI/JVMTI などの「補助」API に関連するものは? 標準ライブラリ？(どの部品がどれだけ得ますか?) 他の主要なコンポーネントはありますか?
これは、具体的なアプリケーションと VM 構成がないと簡単に答えられない可能性があることを認識しているため、少なくともある程度絞り込むために、主にデフォルト/典型的な VM 構成と、ベースライン コンソールの「Hello world」アプリに関心があります。現実世界のデスクトップやサーバー アプリと同様です。(私は、JVM のフットプリントのかなりの部分がアプリ自体から大きく独立しているのではないかと疑っています。理想的には、この部分を拡大したいと思います。)
他にもいくつかの密接に関連する質問があります。
.NET/mono などの他の同様のテクノロジは、ほぼ同じフットプリントを示しません。これはなぜですか？
フットプリントの大部分は、単に標準ライブラリのサイズによるものであると、インターウェブのどこかで読んだことがあります。もしそうなら、なぜこれほど多くの標準ライブラリが事前にロードされるのでしょうか?
メモリ フットプリントを抑えるための取り組み (JSR など) はありますか? 私が遭遇した最も近いものは、 JVM のディスク上のフットプリントを削減するプロジェクトです。
Java の新しいバージョンごとに、過去 10 年ほどの間にフットプリントが変化したことは確かです。JVM のフットプリントがどれだけ変化したかを正確に記録する特定の数値/グラフはありますか?
