3

CMS GC が有効になっている Java ランタイムで、次の verbosegc 行について洞察を提供してもらえますか? 具体的には：

  1. でのイベントは29.490、マーキングのための高水準のヒープ位置を示していますか?
  2. フェーズとは何precleanですか?マーキングとは何が違うのですか?
  3. resetフェーズとは何ですか？それがスイープの終わりではないのに、なぜそれが完了するのに時間がかかるのでしょうか?
  4. 最後に、 でのイベントのRescan、greyおよびroot再スキャンとremarkエリアとメトリックとは29.653何ですか? これらは、後続のスイープで報告されたヒープ メトリックであると仮定しますか? もしそうなら、なぜ彼らは時間を消費するのですか？

verbosegc ログの抜粋:

29.490: [GC [1 CMS-initial-mark: 16225K(17684K)] 16737K(22420K), 0.0030839 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
29.494: [CMS-concurrent-mark-start]
29.652: [CMS-concurrent-mark: 0.158/0.158 secs] [Times: user=0.16 sys=0.00, real=0.16 secs]
29.652: [CMS-concurrent-preclean-start]
29.652: [CMS-concurrent-preclean: 0.000/0.000 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
29.653: [GC[YG occupancy: 512 K (4736 K)]29.653: [Rescan (non-parallel) 29.654: [grey object rescan, 0.0001517 secs]29.654: [root rescan, 0.0030887 secs], 0.0033817 secs]29.657: [weak refs processing, 0.0000271 secs] [1 CMS-remark: 16225K(17684K)] 16737K(22420K), 0.0035183 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
29.658: [CMS-concurrent-sweep-start]
29.679: [CMS-concurrent-sweep: 0.022/0.022 secs] [Times: user=0.03 sys=0.00, real=0.03 secs]
29.680: [CMS-concurrent-reset-start]
29.703: [CMS-concurrent-reset: 0.022/0.022 secs] [Times: user=0.02 sys=0.00, real=0.01 secs]
29.797: [GC 29.797: [DefNew: 4736K->512K(4736K), 0.0207183 secs] 20800K->17172K(31512K), 0.0209119 secs] [Times: user=0.01 sys=0.02, real=0.03 secs]

ありがとう、

4

1 に答える 1

2

SunのWebサイトにある「コンカレントマークスイープガベージコレクタログについて」の記事を読んでください。これで、ログに関するほとんどの質問に答えられると思います。JavaのコンカレントGCの背景情報の詳細については、「Java SE 6HotSpot[tm]仮想マシンのガベージコレクションのチューニング」ページを参照してください。

于 2009-12-09T07:44:12.633 に答える