G1 changes in Shenandoah

Aleksey Shipilev shade at redhat.com
Thu Jul 6 21:49:07 UTC 2017


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.

> 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?

Thanks,
-Aleksey



More information about the shenandoah-dev mailing list