2012-02-25 2 views
3

私は、Java(例えば512k)を持っていると考えているスタック割り当てサイズが論理サイズ(実際には、ホットスポットオーバヘッドを含めて512k以上を使用していることを意味する)か、物理的な制限(つまり、スタック内のすべてのJavaの割り当てられたものを合計すると、512kのようなものは得られません)?Javaのスタック割り当てサイズは物理的または論理的ですか?

それはテストでこれを理解するのは難しい、私は私の他の記事で見られたように、と言うだろう:Inferring a method's stack memory use in Java

可能であれば、私は、ソースのいくつかの並べ替えをたいと思います!

おかげ

答えて

2

私は物理的および論理的の区別が、この場合のビットぼやけていると思います。 HotSpotはあなたのコードを自由にネイティブコードにJITし、その結果はいくつかの最適化に依存するため、両方のビューが正しい方法であると主張することができます。

スタックが物理的だとは言えますが、スタック上に移動するものは可変であり、実行されるJavaコードから派生することは必ずしも簡単ではありません。たとえば、関数呼び出しはインライン化されていてもいなくてもかまいません。そのため、ある場所から関数への呼び出しにスタック上に余分なスペースが必要な場合や、別の場所や別の場所から同じ関数を呼び出す必要がないか、もっと)。これはthis documentの深いインライン展開と呼ばれます。参照をスタックにプッシュすると、それらのサイズも変わる場合があります(64ビットJVMの場合でも参照を32ビットに絞ることを可能にするトリックがあります)。 JITコンパイラは非同期で動作し、コード実行によるデータのプロファイリングに基づいていくつかの決定を下すため、同じコードはさまざまなパフォーマンスを持ち、異なる実行中にはスタック使用量がある可能性があります。

EDIT: ガベージコレクタ、JITコンパイラなどの別のスレッドで実行するので、それはあなたが「ホットスポットオーバーヘッド」によって何を意味するかだ場合、彼らは、自分のコールスタックを使用します。

+0

私は自分自身をもう少し明確にしようとします。私はJDKとHotSpotのコードを手に入れました。たとえば、メソッド呼び出しをするときには、このようなさまざまな情報(パラメータなど)でいっぱいになったこの大きな構造体(JavaCallWrapperはどのように呼び出されているか)があります。もちろん、この構造体が存在するという事実だけが、(パラメータ自体、戻りデータ、このパラメータなどのように)存在すると思われるより明白なデータを追加します。このJavaCallWrapperで定義されたJVMのスタックサイズを「カウント」しますか? –

2

スタックサイズは、実際に使用されるまで仮想メモリを使用します。つまり、すべてのスレッドでスタックサイズが1 MBになりますが、常駐サイズはわずか32 KBになる可能性があります。

これは、実際にOSを使用しているときにOSがプログラムにページ(通常は4 KB)を割り当てるためです。

起動時に最大ヒープサイズが割り当てられますが、すべてのページが使用されるまで、プログラムはそれほどメインメモリを使用しません。

JVMのこの情報を見つけるのが難しい場合があります。これは、OSによって提供される機能であり、すべてのプログラムがこのように機能するためです。すなわち、JVMが特別なものではない。

関連する問題