RFR: Do not reset learning cycles after resizing

[William Kemper]

Also, require more than 10 gc cycles before trigger can resize generations. The behavior on the extremem 'phased' workload looks much better:

[1334.381s][info][gc,stats       ]    66 Successful Concurrent GCs
[1334.381s][info][gc,stats       ]       0 invoked explicitly
[1334.381s][info][gc,stats       ]       0 invoked implicitly
[1334.381s][info][gc,stats       ] 
[1334.381s][info][gc,stats       ]     7 Completed Old GCs
[1334.381s][info][gc,stats       ]       0 mixed
[1334.381s][info][gc,stats       ]       0 interruptions
[1334.381s][info][gc,stats       ] 
[1334.381s][info][gc,stats       ]     1 Degenerated GCs
[1334.381s][info][gc,stats       ]       1 caused by allocation failure
[1334.381s][info][gc,stats       ]         1 happened at Mark
[1334.381s][info][gc,stats       ]       1 upgraded to Full GC
[1334.381s][info][gc,stats       ] 
[1334.381s][info][gc,stats       ]     0 Abbreviated GCs
[1334.381s][info][gc,stats       ] 
[1334.381s][info][gc,stats       ]     1 Full GCs
[1334.381s][info][gc,stats       ]       0 invoked explicitly
[1334.381s][info][gc,stats       ]       0 invoked implicitly
[1334.381s][info][gc,stats       ]       0 caused by allocation failure
[1334.381s][info][gc,stats       ]       1 upgraded from Degenerated GC

The full cycle here was the first cycle after the last of the initial learning cycles.

-------------

Commit messages:
 - Require more than 10 gc cycles before trigger can resize generations
 - Merge branch 'shenandoah-master' into generation-sizing-refinements
 - Do not reset learning cycles after resizing

Changes: https://git.openjdk.org/shenandoah/pull/203/files
 Webrev: https://webrevs.openjdk.org/?repo=shenandoah&pr=203&range=00
  Stats: 22 lines in 3 files changed: 16 ins; 3 del; 3 mod
  Patch: https://git.openjdk.org/shenandoah/pull/203.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah pull/203/head:pull/203

PR: https://git.openjdk.org/shenandoah/pull/203