G1GC Full GCs

[Peter Schuller]

> I still seem to be putting off GC of non-young regions too much though. I

Part of my experiments I have been harping on was the below change to
cut GC efficiency out of the decision to perform non-young
collections. I'm not suggesting it actually be disabled, but perhaps
it can be adjusted to fit your workload? If there is nothing outright
wrong in terms of predictions and the problem is due to cost estimates
being too high, that may be a way to avoid full GC:s at the expense of
more expensive GC activity. This smells like something that should be
a tweakable VM option. Just like GCTimeRatio affects heap expansion
decisions, something to affect this (probably just a ratio applied to
the test below?).

Another thing: This is to a large part my human confirmation biased
brain speaking, but I would be really interested to find out if if the
slow build-up you seem to be experiencing is indeed due to rs scan
costs de to sparse table overflow (I've been harping about roughly the
same thing several times so maybe people are tired of it; most
recently in the thread "g1: dealing with high rates of inter-region
pointer writes").

Is your test easily runnable so that one can reproduce? Preferably
without lots of hbase/hadoop knowledge. I.e., is it something that can
be run in a self-contained fashion fairly easily?

Here's the patch indicating where to adjust the efficiency thresholding:

--- a/src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp   Fri
Dec 17 23:32:58 2010 -0800
+++ b/src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp   Sun
Jan 23 09:21:54 2011 +0100
@@ -1463,7 +1463,7 @@
     if ( !_last_young_gc_full ) {
       if ( _should_revert_to_full_young_gcs ||
            _known_garbage_ratio < 0.05 ||
-           (adaptive_young_list_length() &&
+           (adaptive_young_list_length() && //false && // scodetodo
            (get_gc_eff_factor() * cur_efficiency < predict_young_gc_eff())) ) {
         set_full_young_gcs(true);
       }


-- 
/ Peter Schuller
_______________________________________________
hotspot-gc-use mailing list
hotspot-gc-use at openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use