Skip to main content
Last updated April 03, 2014 08:24, by Martijn Verburg

NOTE: This section is out of date, patch flow for JDK9 and JDK8 updates is now different

Patch Flow Example for JDK 9


Patch Flow Example for JDK 8 Updates


Historical: Patch Flow Example for JDK 8

Stuart Marks talks about a Mac OS X 10.8.4 build bug:


The bug in question is this one:

Strange, the bug view here shows that it's not resolved, but in fact it is. The official fix has arrived in the TL forest now. The changeset is

It is indeed unfortunate that it took so long for the fix to propagate into TL. It's also unfortunate that the way changesets propagate among the various forests is so opaque. Here's how it works, following the specific example of this fix.

Briefly, there are a handful of forests into which developers push changes. Two examples of such forests are the TL forest and the Hotspot forest. (Actually, there are two levels of Hotspot forests. Also, these are distinct from the hotspot repo, which is in every forest.) Changes are propagated "up" from the Hotspot forests, where this fix was originally pushed, into master. Then, changes in the master are propagated "down" into other forests such as TL. There are varying schedules for such merges to occur; they are usually weekly or every two weeks. Thus, a fix in one forest might take several weeks to propagate to the other forests. Changes to the libraries are pushed into TL and they follow mostly an opposite path to get into the Hotspot forests and other forests.

I have the benefit of being able to watch the progress of these changesets in our bug tracking system -- still internal only for the time being, though, sorry. It's difficult, but not impossible, to track the flow of changesets through careful analysis of repository notifications and email announcements from the integrators. (The integrators are the people who propagate the changesets among the forests.) For example, this bug was checked into the Hotspot runtime forest on 2013-08-07 [1]. Then, the fix was propagated to the Hotspot Express forest (an intermediate integration forest) on 2013-08-16 [2]. On 2013-08-20 the changeset was propagated into the JDK 8 master [3]. When fixes are merged into the master, the integrator sends a descriptive announcement with a list of bugfixes that are being integrated [4]. Finally, on 2013-08-26, the changeset was propagated from master into the TL forest [5].






So, it took a total of 19 days from the time the fix was pushed into the hotspot-runtime forest for it to propagate into the TL forest. This is, I think, typical of the time it takes for changes to propagate throughout the forests.

While I don't want to have a big discussion about the history and rationale of this system, I personally think that it's a problem that changes take so long to propagate around.

Back to WhatToWorkOnForOpenJDK

Please Confirm