G1 changes in Shenandoah

[Roman Kennke]

Am 06.07.2017 um 20:14 schrieb 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?

Yes, I think that makes sense. We won't be able to let G1 use the
pristine upstream code... there are some changes that had to be made for
Shenandoah, iirc in SATB and CMBitMap code. Some other code can be used
unchanged (ParallelCleaning...).

I am planning to move around and prepare stuff for Shenandoah upstream
soon (CMBitMap, SATB, ParallelCleaning and probably some other parts we
reused from G1).

Roman
>
> Thanks,
> -Aleksey
>