G1 changes in Shenandoah

[Aleksey Shipilev]

Hi,

I am trying to do jdk10/hs -> shenandoah/jdk10 merge, and realize there are
troubles merging our G1 changes with upstream. The changes are at least in
ParallelCleaningTask and CMBitMap which we moved from g1/ to shared/, and quite
possibly modified along the way.

It is understandable that moving these implementations to shared/ is a good
engineering practice, but there are risks:
  a) Upstream merges get complicated;
  b) We might introduce new G1 bugs, because shared parts are run with
Shenandoah, but not really with G1. This gets especially interesting if we ship
Shenandoah code for G1 users (many of them would use it by default in 9!)
  c) We might silently omit G1 changes in their own classes, because we switched
G1 to use shared/ (unlikely though, because let's hope version control works fine).

So I think we need to mitigate these risks by doing this:
  1. Revert all changes in g1/ in 8u, 9, 10 -- letting G1 use the pristine and
tested code from upstream;
  2. Continue using shared/ things in Shenandoah
  3. (periodically) Review changes between g1/ and shared/ implementations, and
cherrypick improvements
  4. (later) Push Shenandoah + shared/ to upstream, and work out switch to
shared/ in both Shenandoah and G1 directly in upstream

Sounds fine?

Thanks,
-Aleksey