Merging jdk9/hs-rt with jdk9/hs

[Volker Simonis]

+1 :)

On Thu, Apr 7, 2016 at 12:19 AM, Mikael Vidstedt
<mikael.vidstedt at oracle.com> wrote:
>
> Having heard no feedback[1], we're going to go ahead with this experiment
> and the plan is to do the switch next week, *Friday April 15th*. Again,
> please note that any outstanding work based on jdk9/hs-rt will have to be
> rebased on jdk9/hs once the switch is made. More information as we get
> closer to the actual switchover.
>
> Let us know if you have any concerns with the date, and/or any feedback on
> how it's working out.
>
> Cheers,
> Mikael
>
> [1] Not even from Volker *hint* ;)
>
>
> On 3/21/2016 4:59 PM, Mikael Vidstedt wrote:
>>
>>
>> All,
>>
>> The JDK 9 development of Hotspot is primarily done in two different
>> mercurial forests: jdk9/hs-rt[1], and jdk9/hs-comp[2]. In June of last year
>> we moved[3] all the GC development from jdk9/hs-gc[4] to jdk9/hs-rt, and the
>> experience so far has been a good one. Change propagation (from jdk9/hs-rt
>> to jdk9/hs-gc and vice verse) is now a non-issue, we get testing faster on
>> the union of the changes where previously it could take weeks to catch a GC
>> related bug in RT testing, etc.
>>
>> However, both jdk9/hs-rt and jdk9/hs-comp still integrate through a third
>> forest - jdk9/hs[5], aka. hs "main" - before the changes are integrated to
>> jdk9/dev[6]. In line with the previous simplification, we would like to
>> suggest a further simplification of the forest structure. Specifically, we
>> suggest that the work currently done on the jdk9/hs-rt forest moves directly
>> to the jdk9/hs forest. In addition to making the forest structure easier to
>> understand, this would have the benefit of removing one set of integrations
>> (jdk9/hs <-> jdk9/hs-rt), which further reduces cost and propagation time.
>> It is also paving the way for eventually integrating up to jdk9/dev more
>> often (but that is a separate discussion).
>>
>> We suggest that the experiment starts on April 15th, and goes on for at
>> least two weeks (giving us some time to adapt in case of issues). Monitoring
>> and evaluation of the new structure will take place continuously, with an
>> option to revert back if things do not work out. The experiment would keep
>> going for at least a few months, after which we will evaluate it and
>> depending on the results consider making it the new standard. If so, the
>> jdk9/hs-rt forest will eventually be retired, with an option of looking at
>> further reduction of forests going forward. At least for now, we suggest
>> that jdk9/hs-comp remains a separate forest and that it integrates through
>> jdk9/hs just like it does today.
>>
>> Much like when we merged the jdk9/hs-gc and jdk9/hs-rt forests we would
>> leave the jdk9/hs-rt forest around until we see if the experiment works out.
>> We would also lock it down so that no accidental integrations are made to
>> it. Once the jdk9/hs-rt forest is locked down, any work in flight based on
>> it would have to be rebased on jdk9/hs.
>>
>> Please let us know if you have any feedback or questions!
>>
>> Cheers,
>> Mikael
>>
>> [1]http://hg.openjdk.java.net/jdk9/hs-rt
>> [2]http://hg.openjdk.java.net/jdk9/hs-comp
>> [3]http://mail.openjdk.java.net/pipermail/hotspot-dev/2015-May/thread.html
>> [4]http://hg.openjdk.java.net/jdk9/hs-gc
>> [5]http://hg.openjdk.java.net/jdk9/hs
>> [6]http://hg.openjdk.java.net/jdk9/dev
>>
>