Community Input on Hotspot 22 integration into 7u (original) (raw)

Erik Trimble erik.trimble at oracle.com
Wed Aug 10 19:50:38 PDT 2011

Please see my related post on the process around integrating Hotspot Express versions into JDK 7u.

This email is specifically about a technical question around the integration of Hotspot 22 b01 into the 7u series.

The current situation is this:

The contents of http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot (and jdk7u-dev/hotspot ) are derived from the JDK 7 FCS Hotspot, which is Hotspot 21 Build 17.

Hotspot 22 is a fork from Hotspot 21 build 13, as HS21 was being stabilized for the JDK 7 release, and additional work needed a new place to reside.

Thus, the current contents of jdk7u/hotspot are not an ancestor (in Hg terms) of the HS22 repository (http://hg.openjdk.java.net/hsx/hsx22/hotspot ). In particular, there are a multitude of instances where the same CR is fixed in both HS22 and HS21 in a different changeset.

While the jcheck restriction on duplicate CRs has been relaxed for the 7u repositories (i.e. jcheck will complain, but will allow one to push a changeset that has an already-existing CR in the summary), there is a technical issue here.

We have two options:

A) We can delete the existing copy of jdk7u/jdk7u/hotspot (and all derived repositories, e.g. jdk7u/jdk7u-dev/hotspot ), and simply copy the new Hotspot 22 repository files into those places. This is done INSIDE the Hg servers, as a filesystem-level delete and copy.

B) We can do a merge of the HS22 repo into the existing HS21 repo. From a technical standpoint, I've been informed that it's about a 4 on a 10-scale of difficulty to do.

Here's the tradeoffs:

Option A will require everyone to re-clone any repository they have made from any repo derived from jdk7u/jdk7u/hotspot. Obviously, we (Oracle) would have to publish a complete list of all repositories which were so affected. Option B would be simply business-as-usual.

Option B would result in a repository with several dozen changesets which have both the same bugID (CR), AND which also perform the exact same code change. This can make code review a bit dicey, and results in a much "messier" history than Option A.

Option B retains all the JDK 7 FCS-related tags (e.g. hs21-b1[4-7] and jdk7-b14[4-7]), while Option A does not have them (it stops at hs21-b13/jdk7-b143).

The Option A replacement would be a one-time occurrence - no future update to the 7u/hotspot repo would ever have to undergo this replacement again (as all such future updates would be a direct descendant of the existing HS22 repo). The Option B merge would of course also be a one-time thing, though the "messy" history would remain forever.

Both A and B require about the same level of work on our (Oracle's) end. B is slightly more risky than A, due to the added burden of making sure the merge is correct.

Given that it is very, very early in the development process for 7u (we're on what, about build 02?), I would vote for cleanliness over some minor temporary inconvenience in re-cloning. Thus, personally, I would prefer Option A, avoiding the messy merge history, and forcing everyone to re-clone.

But, this being a community, and I not being Dictator-for-Life, I put it to everyone here:

A, or B? Replace or Merge?

I'd like to do this HS22 integration right after the resolution to my "Process proposal for Updating JDK 7u with Hotspot Express..." proposal. Thus, please have your votes (and, of course, comments/questions) in by no later than 12pm (noon), on Friday, 12 August.

Thanks, everyone!

-- Erik Trimble Java Platform Group - Infrastructure Mailstop: usca22-317 Phone: x67195 Santa Clara, CA Timezone: US/Pacific (UTC-0800)

More information about the jdk7u-dev mailing list