The G1CollectorPolicy class contains a lot of code that is either unused or redundant. Such code falls into two categories:

* Code used by the PERDICTIONS_VERBOSE switch

There are a lot of field and methods used to store information that is only there to be reported when the PREDICTIONS_VERBOSE switch is enabled (but we are going to replace that switch with logging using G1's ergo decision logging framework, see 7084525). So, we should remove the PREDICTIONS_VERBOSE flag and all the associated unused code to simplify G1CollectorPolicy and as a prelude to 7084525. In fact, we should also get rid of the three remaining uses of G1PolicyVerbose as this will allow us to remove one extra otherwise unused field (and we want to ultimately remove that argument anyway).

Removing all this code requires no changes to the rest of the codebase as there's nothing else that relies on it; it's pure code removal.

* Several redundant ways of keeping track of region counts

It turns out that we have no less than six different ways to count regions in the CSet (either all CSet regions, or per-category):

a) YoungList : maintains the count of survivor and eden regions that are added to it
b) _inc_cset_size : the number of young regions added to the incremental CSet, which is the same as the counts the YoungList maintains
c) _collection_set_size : the number of regions added to the CSet, which is the same as _inc_cset_size plus any old regions we'll add to the CSet
d) _inc_cset_young_index : used to set an index to the young regions in the CSet (0 for the oldest region, 1 for the second oldest region, etc.) which is again essentially the same as _inc_cset_size
e) _young_cset_length : the number of young regions in the CSet
f) _recorded_young_regions / _recorded_non_young_regions : the number of young / old regions in the CSet

We should simplify this. The YoungList keeps track of the number of eden and survivor regions that will be added to the CSet so no point in calculating that information separately, as we do in b) and d). Also, no point in storing the same information twice, as we do in e) and f).

We should replace b) through f) with these three fields:

1) eden CSet regions
2) survivor CSet regions
3) old CSet regions

We'll set 1) and 2) from the information in the YoungList, we'll update 3) as we add old regions to the CSet. So, getting the number of young CSet regions or all CSet regions can be simply done by using the above three fields.

This change is mostly straightforward: a lot of the rendundant code can be removed and we can use the new information we'll maintain where we were using the old one (in almost an one-to-one correspondance). The only non-trivial part is that we have to correctly update the CSet young index for each eden / survivor region without having the _inc_cset_young_index field which requires a bit of code re-organization (but it's very minor).

In addition, we maintain counts for the number of mutator allocation regions that we allocate. Given that we used to allow such allocations to be satisfied out of the old generation, we maintain two counts: one for young allocations and one for tenured allocations. It was helpful to know what percentage of allocations were satisfied out of the old gen. Given that all mutator allocation regions are now allocated out of the young gen, this information is irrelevant. So, we can also remove the associated code.