We recently tried G1 on a 32GB heap, with a 4GB / 8GB young gen. We noticed that termination times are relatively long (around 30-40ms). The reason for this is that GC worker with id 0 (it's always GC worker with id 0) is late coming into the GC code which results in all the other threads waiting for it during termination. This is clearly a performance bottleneck. We should resolve this.
Posted Date : 2009-03-18 18:24:41.0

N/A

Ramki pointed out that it's not necessarily the same OS thread that gets id 0. And given that it's always thread 0 that has the issue we suspect some pathology in the G1 code.
Posted Date : 2009-03-18 19:34:37.0

Well, with a quick glance at the code I think I've found the culprit.

void
HRInto_G1RemSet::oops_into_collection_set_do(OopsInHeapRegionClosure* oc,
                                             int worker_i) {
  ...
  if (worker_i == 0) {
    _cg1r->clear_and_record_card_counts();
  }
  ...
Posted Date : 2009-03-18 20:05:33.0

Adding an extra timer to the code and running the 32GB heap application confirmed that the culprit is indeed the one mentioned in the previous Evaluation note. clear_and_record_card_counts() would take more than 60ms on relatively state-of-the-art hardware.
Posted Date : 2009-03-25 21:52:15.0

http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/6cb8e9df7174
Posted Date : 2009-08-05 02:48:22.0

http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/6cb8e9df7174
Posted Date : 2009-08-06 03:41:07.0