Merging jdk9/hs-rt with jdk9/hs

[Mikael Vidstedt]

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
>