Merging jdk/hs with jdk/jdk

jesper.wilhelmsson at jesper.wilhelmsson at
Fri Apr 6 00:37:16 UTC 2018

Hi all,

I've gotten only positive feedback on this suggestion. The next step
is to propose a date and outline the steps needed to go through with
this change.

The proposed date is April 12 (Thursday next week).

The steps are:

1. jdk/hs is closed for pushes at 8 pm PST on April 12. This is when
    the hotspot nightly takes the snapshot of jdk/hs and starts the nightly
    tests. Please note that this is a hard deadline as the system is
    automated and will take the snapshot on time.

2. The Thursday snapshot will then be sent through the regular product
    integration testing (PIT) which runs over the weekend.

3. On Friday, April 13, the hotspot nightly and the hotspot CI (post
    integration testing) will be reconfigured to look at jdk/jdk.

4. The goal is to get the PIT analysis done by Wednesday, April 18.
    At this point the PIT snapshot will be pushed to jdk/jdk.

5. Once the PIT snapshot has been pushed to jdk/jdk, the jdk/jdk
    repository will be open for hotspot changes.

In order to minimize the risk of merge conflicts when pushing the
PIT snapshot to jdk/jdk, we will not open for hotspot changes
until after the snapshot has been pushed.

It is important that everyone that has a new change in the snapshot
are available on Monday / Tuesday (April 16-17) to handle any
problems that might arise as a result of the change. If you know that
you will not be available these days, make sure someone else can
cover your change, or hold your push until after the merge is done.


> On 14 Mar 2018, at 22:00, jesper.wilhelmsson at wrote:
> All,
> Over the last couple of years we have left behind a graph of
> integration forests where each component in the JVM had its own
> line of development. Today all HotSpot development is done in the
> same repository, jdk/hs [1]. As a result of merging we have seen
> several positive effects, ranging from less confusion around
> where and how to do things, and reduced time for fixes to
> propagate, to significantly better cooperation between the
> components, and improved quality of the product. We would like to
> improve further and therefore we suggest to merge jdk/hs into
> jdk/jdk [2].
> As before, we expect this change to build a stronger team spirit
> between the merged areas, and contribute to less confusion -
> especially around ramp down phases and similar. We also expect
> further improvements in quality as changes that cause problems in
> a different area are found faster and can be dealt with
> immediately.
> In the same way as we did in the past, we suggest to try this out
> as an experiment 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 jdk/hs forest will eventually be retired. As part of this
> merge we can also retire the newly setup submit-hs [3] repository
> and do all testing using the submit repo based on jdk/jdk [4].
> Much like what we have done in the past we would leave the jdk/hs
> forest around until we see if the experiment works out. We would
> also lock it down so that no accidental pushes are made to
> it. Once the jdk/hs forest is locked down, any work in flight
> based on it would have to be rebased on jdk/jdk.
> We tried this approach during the last few months of JDK 10
> development and it worked out fine there.
> Please let us know if you have any feedback or questions!
> Thanks,
> /Jesper
> [1] <>
> [2] <>
> [3] <>
> [4] <>

More information about the jdk-dev mailing list