3

Oracle の 64 ビット Java 1.8 Hotspot JVM を実行しています。私は、異なる GC メカニズムが使用されている場合に、JVM の動作の違いに頭を悩ませて、圧縮されたオブジェクト ポインターを起動しようとしています。例えば：

$ java -XX:+UseConcMarkSweepGC -XX:+PrintFlagsFinal -Xms32766m -Xmx32766m

bool UseCompressedClassPointers        := true        {lp64_product}
bool UseCompressedOops                 := true        {lp64_product}

$ java -XX:+UseConcMarkSweepGC -XX:+PrintFlagsFinal -Xms32767m -Xmx32767m

bool UseCompressedClassPointers        = false        {lp64_product}
bool UseCompressedOops                 = false        {lp64_product}

$ java -XX:+UseG1GC -XX:+PrintFlagsFinal -Xms32736m -Xmx32736m

bool UseCompressedClassPointers        := true        {lp64_product}
bool UseCompressedOops                 := true        {lp64_product}

$ java -XX:+UseG1GC -XX:+PrintFlagsFinal -Xms32737m -Xmx32737m

bool UseCompressedClassPointers        = false        {lp64_product}
bool UseCompressedOops                 = false        {lp64_product}

他のいくつかの G1GC ノブを変更しようとしましたが、G1 の 32736 MB を超えるヒープ サイズで圧縮ポインターの最適化を開始できません。しかし、明らかにわかるように、CMS は最大 32766 MB のヒープ サイズに圧縮ポインタを使用できます。さまざまな GC アルゴリズムのこのしきい値を制御するものを理解しようとしています。

4

1 に答える 1

4

しかし、32736 MB を超えるヒープ サイズでは、圧縮ポインターの最適化を開始することはできません。

オブジェクトはデフォルトで 8 バイト境界に整列されているため、これは正常です。つまり、最下位 3 ビットは冗長であり、シフトによって削除されます。つまり、32 ビット オブジェクト ポインターは、その整列で最大 4GB * 8 相当のオブジェクトをアドレス指定できることを意味します。

-XX:ObjectAlignmentInBytes=16圧縮 oops で 32GB 以上を使用したい場合は、オブジェクトのアラインメントを 16 バイトに上げる必要があります。これにより、小さなオブジェクトが大きくなることに注意してください。つまり、一部のメモリが浪費されるため、実際に何かが得られるかどうかを測定する必要があります。

この回答には、興味深い可能性のある追加の診断オプションがいくつかあります。

于 2016-08-05T10:28:14.967 に答える