Community Input on Hotspot 22 integration into 7u

[Erik Trimble]

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)