RFR: Heuristics fix, refactoring + 2 new heuristics

[Roman Kennke]

Hi,

this patch does a bunch of things to heuristics:

- it fixes a bug. It's what Alexey found. If you allocate many
humongour objects, it is possible that the tail regions are not full,
and if they are < garbage-threshold the heuristics would not pick them
up. They would forever remain in that state.

- Refactoring: the choose_collection_set() code is changed so that
there's a non-virtual driver in ShenandoahHeuristics and very little
code in the subclasses. The point is that all heuristics basically did
the same thing, and I did not want to duplicate this and produce
gazillions little inconsistencies and bugs.

- Two new heuristics:

global: ShenandoahGarbageThreshold is interpreted as global garbage
threshold. The heuristic adds regions into the collection set, until it
has X% of total garbage in it. The rationale being that sometimes (more
often than we want to) we get unfortunate garbage distributions where
lots of regions fly just below the garbage threshold, and wouldn't get
enough garbage collected. Current default is 90% (i.e. 90% compared to
total garbage)

ratio: similar to global, except that the threshold is interpreted as
ratio between garbage and live data in the cset. We put enough regions
into the cset until we reach that ratio. Current default is 95% (i.e.
95% garbage, 5% live data).

The defaults have been picked from observation of the current dynamic
heuristics.

- Some interesting information printed with -Xlog:gc=debug. E.g.:

[10,820s][debug][gc] Total Garbage: 1886682376
[10,821s][debug][gc] Immediate Garbage: 910590264
[10,821s][debug][gc] Immediate Garbage regions: 3482
[10,821s][debug][gc] Garbage to be collected: 875507552
[10,821s][debug][gc] Objects to be evacuated: 152357024
[10,821s][debug][gc] Live / Garbage ratio: 17%
[10,821s][debug][gc] Collected-Garbage ratio / Total-garbage: 46%


http://cr.openjdk.java.net/~rkennke/heuristics/webrev.00/


Ok?

Roman