Merging jdk9/hs-comp with jdk9/hs

[Mikael Vidstedt]

Having heard no objections, we’re looking to move forward with the consolidation.

We of course want to make sure that what’s currently in hs-comp is ready for (the last) integration, and due to some technical difficulties we’re still waiting for the relevant test results. We’re still hoping to have everything ready to go on Friday, but if not we may have to postpone the merge.

Cheers,
Mikael

> On Sep 29, 2016, at 11:23 AM, Mikael Vidstedt <mikael.vidstedt at oracle.com> wrote:
> 
> 
> All,
> 
> Over the last two years we have worked towards simplifying the mercurial forest structure for Hotspot development by consolidating and removing forests. Last year we moved[1] the GC development work from jdk9/hs-gc[2] to jdk9/hs-rt[3], and earlier this year we further consolidated forests by moving[4] the jdk9/hs-rt work directly to the jdk9/hs[5] - aka. "hs main" - forest. The reduction in forests has led to less work spent on integration, faster quality feedback, more efficient hardware utilization, etc. All in all, the experience so far has been a good one.
> 
> However, the Hotspot (JIT) compiler changes are still integrated through the jdk9/hs-comp[6] forest, and are tested separately before they are (bulk) integrated up to jdk9/hs. The separate forest of course comes with the expected integration/gatekeeper overhead and lead times. Since JDK 9 development is ramping down, we expect the number of changes to ramp down as well. This means that the benefit of having a separate jdk9/hs-comp forest is going to reduce over time. Now seems like a good time to look at doing a final hotspot forest consolidation.
> 
> In line with this, we propose closing down jdk9/hs-comp and doing all remaining JDK 9 Hotspot development to jdk9/hs. We propose that this final forest consolidation to take place on Friday, October 7th. Much like the earlier forest consolidations the jdk9/hs-comp forest will be kept around, but will be locked down so that no accidental integrations are made to it. Any work in flight based on jdk9/hs-comp would have to be rebased on jdk9/hs.
> 
> The earlier forest consolidations have gone very smoothly, and we expect this one to go smoothly as well, but if for some reason things don't work out we will of course have an option to go back to what we have today. That said, before using the escape hatch and reverting back, we will of course want to try to address any issues - thank you in advance for your patience while we work through any such issues.
> 
> Please let us know if you have any feedback or questions! If no serious objections have been raised by 15:00 UTC Wednesday, 5 October 2016, we will go ahead with the forest consolidation.
> 
> Cheers,
> Mikael
> 
> [1]http://mail.openjdk.java.net/pipermail/hotspot-dev/2015-May/thread.html <http://mail.openjdk.java.net/pipermail/hotspot-dev/2015-May/thread.html>
> [2]http://hg.openjdk.java.net/jdk9/hs-gc <http://hg.openjdk.java.net/jdk9/hs-gc>
> [3]http://hg.openjdk.java.net/jdk9/hs-rt <http://hg.openjdk.java.net/jdk9/hs-rt>
> [4]http://mail.openjdk.java.net/pipermail/hotspot-dev/2016-March/022218.html <http://mail.openjdk.java.net/pipermail/hotspot-dev/2016-March/022218.html>
> [5]http://hg.openjdk.java.net/jdk9/hs <http://hg.openjdk.java.net/jdk9/hs>
> [6]http://hg.openjdk.java.net/jdk9/hs-comp <http://hg.openjdk.java.net/jdk9/hs-comp>
>