G1 changes in Shenandoah

[Roman Kennke]

Am 06.07.2017 um 23:49 schrieb Aleksey Shipilev:
> On 07/06/2017 09:24 PM, Roman Kennke wrote:
>> 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...).
> Yeah, so my idea is to just revert g1/, and let Shenandoah use shared/ parts.
> This decouples G1 code changes enough, I guess.

Ah yes, that sounds like a good idea. Also makes it easy to compare the
versions...
>> 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).
> You mean doing this in upstream itself?
I mean to move stuff that we share with G1 from g1/ to shared/, in
preparation of upstreaming Shenandoah. That would only affect jdk10 though.

Roman