メモリ使用量

余分に使用されるメモリの量
from(to) = NewSize / (1 + 1 + SurvivorRatio)

 -Xms2560m -Xmx2560m -XX:NewSize=768m -XX:MaxNewSize=768M -XX:SurvivorRatio=8

768m / (1 + 1 + 8) = 77m

eden     616m
from(to) 77m 

[ParNew 655720K->141587K(2542848K), 0.5363089 secs]
Heap after gc invocations=2:
 par new generation   total 707840K, used 78592K [0xfffffd7f52a00000, 0xfffffd7f82a00000,
0xfffffd7f82a00000)
  eden space 629248K,   0% used [0xfffffd7f52a00000, 0xfffffd7f52a00000, 0xfffffd7f7908000
0)
  from space 78592K, 100% used [0xfffffd7f79080000, 0xfffffd7f7dd40000, 0xfffffd7f7dd40000
)
  to   space 78592K,   0% used [0xfffffd7f7dd40000, 0xfffffd7f7dd40000, 0xfffffd7f82a00000
)
 concurrent mark-sweep generation total 1835008K, used 62995K [0xfffffd7f82a00000, 0xfffff
d7ff2a00000, 0xfffffd7ff2a00000)
 concurrent-mark-sweep perm gen total 21248K, used 15604K [0xfffffd7ff2a00000, 0xfffffd7ff
3ec0000, 0xfffffd7ff7e00000)
}
 -Xms2560m -Xmx2560m -XX:NewSize=1024m -XX:MaxNewSize=1024M -XX:SurvivorRatio=2

1024m / (1 + 1 + 2) = 256m

eden     512m
from(to) 256m

[ParNew 949894K->440607K(2359296K), 0.8114740 secs]
Heap after gc invocations=21:
 par new generation   total 786432K, used 248896K [0xfffffd7f52a00000, 0xfffffd7f92a00000,
 0xfffffd7f92a00000)
  eden space 524288K,   0% used [0xfffffd7f52a00000, 0xfffffd7f52a00000, 0xfffffd7f72a0000
0)
  from space 262144K,  94% used [0xfffffd7f82a00000, 0xfffffd7f91d10078, 0xfffffd7f92a0000
0)
  to   space 262144K,   0% used [0xfffffd7f72a00000, 0xfffffd7f72a00000, 0xfffffd7f82a0000
0)
 concurrent mark-sweep generation total 1572864K, used 191711K [0xfffffd7f92a00000, 0xffff
fd7ff2a00000, 0xfffffd7ff2a00000)
 concurrent-mark-sweep perm gen total 21248K, used 18220K [0xfffffd7ff2a00000, 0xfffffd7ff
3ec0000, 0xfffffd7ff7e00000)
}

CMSのデフォルト設定

http://java.sun.com/performance/reference/whitepapers/tuning.html

CMSのデフォルト設定: SurvivorRatio=1024 MaxTenuringThreshold=0
→ Scavenge GCの全ての survivors を昇格させる
→ デフォルト設定は survivors を積極的に昇格させCMSコレクタで回収させる?

4.2.6 Tuning Example 6: Tuning for low pause times and high throughput

This tuning example similar to Example 2, but uses the concurrent garbage collector (instead of the parallel throughput collector).

java -Xmx3550m -Xms3550m -Xmn2g -Xss128k -XX:ParallelGCThreads=20 -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:SurvivorRatio=8 -XX:TargetSurvivorRatio=90 -XX:MaxTenuringThreshold=31

Comments:
-XX:+UseConcMarkSweepGC -XX:+UseParNewGC
Selects the Concurrent Mark Sweep collector. This collector may deliver better response time properties for the application (i.e., low application pause time). It is a parallel and mostly-concurrent collector and and can be a good match for the threading ability of an large multi-processor systems.
-XX:SurvivorRatio=8
Sets survivor space ratio to 1:8, resulting in larger survivor spaces (the smaller the ratio, the larger the space). Larger survivor spaces allow short lived objects a longer time period to die in the young generation.
-XX:TargetSurvivorRatio=90
Allows 90% of the survivor spaces to be occupied instead of the default 50%, allowing better utilization of the survivor space memory.
-XX:MaxTenuringThreshold=31
Allows short lived objects a longer time period to die in the young generation (and hence, avoid promotion). A consequence of this setting is that minor GC times can increase due to additional objects to copy. This value and survivor space sizes may need to be adjusted so as to balance overheads of copying between survivor spaces versus tenuring objects that are going to live for a long time. The default settings for CMS are SurvivorRatio=1024 and MaxTenuringThreshold=0 which cause all survivors of a scavenge to be promoted. This can place a lot of pressure on the single concurrent thread collecting the tenured generation. Note: when used with -XX:+UseBiasedLocking, this setting should be 15.

Peformance tuning letter

最後はゲームプログラマが始めたスレッドですが、こんなアドバイスがありました。 「だいたいの場合、すべてのガベージがかなり頻繁に削除され、古い世代に送られるものがほとんどないように、若い世代の回収機構をチューニングできなくてはいけません」 問題は、いったいどうやってそんなことをするのか、ということです。 私の経験では、生存オブジェクト用のスペースを増やすのが一番いいようです。 Eden と survivor spaces はすべて若い空間から取り分けられていて、survivor space の大きさを増やせば Eden の大きさは小さくなります。 Eden の全体的サイズを減らすと GC が頻繁に起きるようになります。 survivor spaces を大きくするとオブジェクトは(GC のコストがずっと低い)若い世代に残るようになります。 他のすべてのパフォーマンスチューニングのアドバイスもそうですが、効果は必ずしもあるとは限りません。

-XX:SurvivorRatio=n は -XX:+UseConcMarkSweepGC が有効でないと効かない?

linux 1.5.0_10-b03
SurvivorRatio指定なし

 -Xms2560m -Xmx2560m -XX:NewSize=512m 
 -XX:+UseParNewGC -XX:+UseConcMarkSweepGC

{Heap before gc invocations=1:
 par new generation   total 523840K, used 523392K [0x15000000, 0x35000000, 0x35000000)
  eden space 523392K, 100% used [0x15000000, 0x34f20000, 0x34f20000)
  from space 448K,   0% used [0x34f90000, 0x34f90000, 0x35000000)
  to   space 448K,   0% used [0x34f20000, 0x34f20000, 0x34f90000)
 concurrent mark-sweep generation total 2097152K, used 21669K [0x35000000, 0xb5000000, 0xb
5000000)
 concurrent-mark-sweep perm gen total 16384K, used 10860K [0xb5000000, 0xb6000000, 0xb9000
000)
[ParNew 545061K->90196K(2620992K), 0.5306093 secs]
Heap after gc invocations=2:
 par new generation   total 523840K, used 0K [0x15000000, 0x35000000, 0x35000000)
  eden space 523392K,   0% used [0x15000000, 0x15000000, 0x34f20000)
  from space 448K,   0% used [0x34f20000, 0x34f20000, 0x34f90000)
  to   space 448K,   0% used [0x34f90000, 0x34f90000, 0x35000000)
 concurrent mark-sweep generation total 2097152K, used 90196K [0x35000000, 0xb5000000, 0xb
5000000)
 concurrent-mark-sweep perm gen total 16384K, used 10860K [0xb5000000, 0xb6000000, 0xb9000
000)
}

SurvivorRatio指定あり

 -Xms2560m -Xmx2560m -XX:NewSize=512m -XX:SurvivorRatio=8
 -XX:+UseParNewGC -XX:+UseConcMarkSweepGC

{Heap before gc invocations=0:
 par new generation   total 471872K, used 419456K [0x0d1f0000, 0x2d1f0000, 0x2d1f0000)
  eden space 419456K, 100% used [0x0d1f0000, 0x26b90000, 0x26b90000)
  from space 52416K,   0% used [0x26b90000, 0x26b90000, 0x29ec0000)
  to   space 52416K,   0% used [0x29ec0000, 0x29ec0000, 0x2d1f0000)
 concurrent mark-sweep generation total 2097152K, used 0K [0x2d1f0000, 0xad1f0000, 0xad1f0
000)
 concurrent-mark-sweep perm gen total 16384K, used 10678K [0xad1f0000, 0xae1f0000, 0xb11f0
000)
[ParNew 419456K->32632K(2569024K), 0.2045250 secs]
Heap after gc invocations=1:
 par new generation   total 471872K, used 32632K [0x0d1f0000, 0x2d1f0000, 0x2d1f0000)

  eden space 419456K,   0% used [0x0d1f0000, 0x0d1f0000, 0x26b90000)
  from space 52416K,  62% used [0x29ec0000, 0x2be9e2c8, 0x2d1f0000)
  to   space 52416K,   0% used [0x26b90000, 0x26b90000, 0x29ec0000)
 concurrent mark-sweep generation total 2097152K, used 0K [0x2d1f0000, 0xad1f0000, 0xad1f0
000)
 concurrent-mark-sweep perm gen total 16384K, used 10678K [0xad1f0000, 0xae1f0000, 0xb11f0
000)
}