Hotspot shell games

Tue Jun 2 05:40:43 PDT 2009

Sorry for the late replay (public holidays in Germany:)
Please see my comments inline...

On 5/31/09, Kelly O'Hair <Kelly.Ohair at sun.com> wrote:
>
>
>  Andrew John Hughes wrote:
>
> > 2009/5/29 Kelly O'Hair <Kelly.Ohair at sun.com>:
> >
> > > (removed jdk7-dev from this discussion)
> > >
> > > Andrew John Hughes wrote:
> > >
> > > > 2009/5/29 Erik Trimble <Erik.Trimble at sun.com>:
> > > >
> > > [snip]
> > >
> > > >
> > > > > For now, though, we need to decide how to handle HSX vs Open6 vs.
> IceTea.
> > > > >
> > > > Simplest solution would be to just remove it from OpenJDK6 and use HSX
> > > > as the upstream.  I don't see an advantage to pulling in to OpenJDK6,
> > > > given there is already a 'stable' branch of HSX.
> > > >
> > > I would prefer to keep a hotspot repository in the openjdk6 forest, just
> > > for the sake of having a buildable and complete source base.
> > >
> >
> > I can see the advantage, though I would guess the number of people
> > doing OpenJDK6 builds is far smaller than those doing IcedTea builds
> > which has been deleting the OpenJDK6 repo and replacing it for months
> > now.  If the OpenJDK6 repo is again allowed to bit-rot, then we're
> > likely to have to do this again.  We'd obviously prefer to be working
> > on a common upstream rather than having effectively two communities.
> >
>
>  It doesn't matter to me which is being built more or less, I just want
>  to make sure that OpenJDK6 is complete and does build, and work.
>  I also want to open it up as much as possible in terms of others
>  pushing changes in. I'm sure we can work this out in an acceptable way
>  for all concerned... read on...
>
>
> >
> >
> > > I would also like to have some level of confidence as to which hotspot
> > > is the default one for the openjdk6 project.
> > > Let's not leave a partial jdk6 forest sitting out there.
> > >
> > >
> >
> > My main concern is maintenance.  If what is there is maintained
> > regularly, I don't care too much either way.  That said, I'd prefer to
> > see less duplication though, and this also extends to CORBA, JAXP and
> > JAXWS as Joe already mentioned.
> >
>
>  I agree, and I'm all in favor. But having a complete OpenJDK6 tree,
>  including hotspot doesn't change that, it's just a clone of a repository
>  that represents what we know works.
>  If the IcedTea team said that they tried Hotspot version 3,246 and it
>  worked for them and looked solid, then hey, great, push those changesets
>  into the openjdk6 hotspot repository.
>  Or we work out some other way to update it, I'm open to suggestions,
>  I just would like to see 'a clone' of 'a hotspot' repository available
>  with the openjdk6 forest of repositories.
>
>
> >
> >
> > > To me the decision that needs to be made is whether you want the
> > > openjdk6 hotspot repository (jdk6/hotspot) 'related' to the other
> > > hotspot repositories, like hsx/hsx14/master is related to jdk7/hotspot.
> > >
> >
> > It isn't related; hsx includes several build drops that were never in
> > the public HotSpot repositories and which we had to wait over three
> > months for.
> >
>
>  When I say 'related' I'm referring to the ability to pull/push mercurial
>  changesets between the repositories without transplanting or reapplying
>  patches. And the hsx repository is related to the public repositories,
>  they just might not ne in sync or be proper subsets of each other at times.
>
>
> >
> >
> > > It doesn't have to be, and there are advantages and disadvantages to
> > > both approaches.
> > > None of the non-hotspot repositories in the openjdk6 forest are related
> > > to the jdk7 repositories, making them pretty independent from jdk7,
> > >
> >
> > Which is sensible, given 6 has to be stable.  It being based off jdk7
> > is merely an issue of when things were released under the GPL, as I
> > believe you or Joe have blogged about before.
> >
>
>  No it's more than that, the sources themselves have a relationship between
>  openjdk6 and openjdk7, but the repositories themselves are not related,
>  you cannot pull/push changesets between these repositories.
>  You can reapply patches and re-create new changesets that match from
>  one to the other, and Mercurial makes that easy, but they are not the
>  same changesets.
>
>  I'm thinking that they should be related, and most of the time be
>  proper subsets of each other in terms of what changesets are in them.
>  This gives us a degree of exactness you don't get when changesets are
>  re-created frpm patches.  Assuming we can do it or even agree to it.
>
>
> >
> >
> > > but hotspot is somewhat special, and the express model I support, so...
> > >
> > > My suggestions...
> > >  * Ignore hsx/hsx14, it's a drop not a development tree
> > >
> >
> > What??? I don't believe any discussions around HSX ever being about it
> > being just a drop.  It's meant to be a stability branch of hs14 for
> > use in OpenJDK6 and Sun's JDK6 releases.  If it was a drop, why do a
> > forest at all and not just update OpenJDK6?
> >
>
>  My definition of 'drop' here was that it is not intended to be a
>  two-way open street as I understood the purpose.
>  A simple source tarball could have worked, but since there was always
>  a chance of last minute hs14 changes, a repository makes things easier,
>  granted it sounds like it was updated a little slowly with the last few
>  changes.
>  My point in the comment is that, as I understand it, hs14 is for all
>  intents and purposes, done.
>  Maybe I have that wrong, but my assumption is that the team is and has
>  moved on to the next hotspot express release, and hs14 is no longer
>  a priority.
>

I'm not sure if that's true - there's a 6u15-ea-src-b01 out there
which has a HS 14.1 b01 (not sure what that is, does 14.1b01 come
after 14.0b17???). But at least it seems to be a HS 14 and therefore
all the hotspot changes to 6u15 should be instantly visible in
hsx/hsx14.

But there's an IMPORTANT point here: once the Java 6 train moves to a
HS 15 we need a hsx/hsx15 repository and from my point of view we need
it as fast as possible, to avoid all the confusion that we had with
hsx14!

>
> >
> >
> > >  * Decide to make the jdk6 and jdk7 repositories 'related'
> > >
> >
> > Impossible, unless I misunderstand what you mean by 'related'.
> >
>
>  Related to me means that both repositories have the same "changeset 0".
>  What I am suggesting is that occasionally, after a sync, the jdk6 repo
> would be
>  a proper subset of the jdk7 repo.
>
>
> >
> >
> > >  * Tag the rev in the jdk7/hotspot repo with a name jdk6-b17, the
> > >   rev that matches what is in the hsx14 repo
> > >
> >
> > Again there is no hs14b11...hs14b16 in the public HotSpot repository.
> >
>
>  Actually I think there is, we just are not recording it in the changeset
> tags.
>
>
> > That's what sparked the whole discussion that lead to HSX in the first
> > place.  Sun took HotSpot 14 'underground' and out of the public eye as
> > regards further stability work.  With hsx, we finally seem to have
> > reversed this process by the release of hs14b11...hs14b16 and I'd
> > expect to see further releases appear there too.
> >
>
>  I'm just not sure you will be getting what you are expecting with this,
>  again, I thought hsx14 was a done deal for the most part.
>
>
> >
> >
> > >  * Toss the existing jdk6/hotspot repo and replace it with a repo
> > >   created with:
> > >       hg clone -r jdk6-b17
> http://hg.openjdk.java.net/jdk7/hotspot
> > > jdk6/hotspot
> > >
> > >
> >
> > I think the only options are to pull in changeset 0 from hsx to rebase
> > the HotSpot repo on that, or (simpler) replace it with a clone of hsx.
> >  The former would preserve the commit history and would be more useful
> > over time IMO.
> >
>
>  I'm very confused now, I think we just said the same thing, or something
>  extremely similar.
>
>
> >
> >
> > > Changes going into jdk6/hotspot should be rare, critical, and should
> > > eventually be pushed back into jdk7/hotspot, indeed some critical fixes
> > > may get transplanted from jdk7/hotspot to jdk6/hotspot.
> > > If at some point it's decided to upgrade jdk6/hotspot to a newer rev,
> > > so be it, easy to do.
> > >
> > >
> >
> > I think changes should just go to hsx and then feed into OpenJDK6
> > through regular pulls, if we plan to maintain a repo. there.
> >
>
>  EXACTLY! That is what I am suggesting for OpenJDK6, just a clone.
>
>  Except you say "hsx" I say "jdk7/hotspot", to me they are the same,
>  or "the latest hotspot express where all the latest work is done".
>
>
> >
> >
> > > And for heavens sake, start adding some hsx-* tags to the hotspot
> repository
> > > so we can easily clone hsx versions from the tag name, you could also
> use
> > > the hsx tag to hold the build number, I can help with that.
> > >
> > >
> >
> > Now this I agree on :)
> >
>
>  Good...  I'll keep pushing on this then.
>
>  ---
>
>  Erik,
>
>  Let's start looking into hsx-* tags!!! ;^)
>
>  -kto
>
>
> >
> >
> > > -kto
> > >
> > >
> > >
> > >
> >
> >
> >
> >
>