Merging jdk9/hs-rt with jdk9/hs

[Mikael Vidstedt]

Everything is in shape for doing the switch *tomorrow, Friday*. In order to make the transition a smooth one we kindly ask everybody to *not push changes to jdk9/hs-rt and/or jdk9/hs starting 7pm PT today, Thursday* (hours from now). We will send out an email when jdk9/hs is open for business - or, if things don't work out, when jdk9/hs-rt is open for business again.

Note that we will wait to see if everything works before actually making jdk9/hs-rt read-only on the mercurial server, so please double check the target repo URLs before pushing changes the next day or two.

Cheers,
Mikael

> On 4/6/2016 3:19 PM, Mikael Vidstedt 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