Hotspot shell games
Volker Simonis
volker.simonis at gmail.com
Tue Jun 2 12:40:38 PDT 2009
On 6/2/09, Andrew John Hughes <gnu_andrew at member.fsf.org> wrote:
> 2009/6/2 Volker Simonis <volker.simonis at gmail.com>:
>
> > On 6/2/09, Andrew John Hughes <gnu_andrew at member.fsf.org> wrote:
> >> 2009/5/31 Kelly O'Hair <Kelly.Ohair at sun.com>:
> >>
> >> >
> >> >
> >> > 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.
> >> >
> >>
> >>
> >> My reticence is mainly because getting changes upstream has been so
> >> slow. That seems to be changing though. I agree with your feelings
> >> about OpenJDK6 being 'complete'.
> >>
> >>
> >> >>
> >> >>> 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.
> >> >
> >>
> >>
> >> Ok, they are related in one direction sure; hsx and jdk7/hotspot match
> >> up to hs14b10. But at that point, one continues up to hs14b11, and
> >> the other starts on hs15b01 up to hs16b03 (in JDK7 b59). We don't
> >> want hs15 or hs16 in 6 until they have proved stable enough; that's
> >> exactly why IcedTea was using a specific HotSpot 7 changeset of
> >> hs14b10 rather than tip prior to the availability of hsx. But the
> >> changesets needed for OpenJDK6 simply aren't in the jdk7 forest and
> >> they can't really be inserted back in the past somewhere.
> >>
> >
> > This was my first thought too, but after rereading Kellys mails and
> > rethinking the whole story I think Kelly is right and it's possible,
> > exactly because the repositories are related. You can think of it as
> > creating a new branch in the jdk7/hotspot repository at the point
> > where hs14 was forked off with a new head which is the tip of the
> > current hsx14 repo (please see my previous mail in this thread - after
> > all a Mercurial repo is a real tree and you don't necessarily have to
> > merge all the branches in the end). The only glitch is the jcheck
> > problem with duplicate bug ids mentioned by Kelly.
> >
>
>
> Maybe I'm not following things right. If OpenJDK6 takes a clone of
> hsx, then, assuming hsx is already based on HotSpot 7's tree, it will
> be possible to merge changesets between all three. The only one that
> isn't related is the current OpenJDK6 HotSpot which we can probably
> just remove (hardly anyone uses it anyway). What I was thinking is
> that he somehow wanted to put the hsx changesets back into 7, which is
> possible sure but they would be on top of later changes (hs15/16)
> which we don't want for 6.
>
Yes, that's what he wanted and no, they would not sit on top of hs15/16 -
the repo would look like this (you probably want to look at this with a
fixed size font such that it makes sense):
-> hs14b01->..->hs14b10->hs15b01->..->hs16b01->.. (default branch)
\
(initial hsx14 clone)
\
\->hs14b10->hs14b11->..->hs14b17->.. (HSX14 branch)
The HSX14 branch can be easily created in the jdk7/hotspot repo by syncing
to "hs14b10" and pulling from the HSX14 repo. You just create a new head in
jdk7/hotspot - that's all...
>
> > The one thing where I however strongly agree with you is that Sun
> > should do the stabilization work in the open from the very beginning,
> > and not after the work is finished - we'll see if this will be true at
> > the point where HS15/HSX15 will appear in Java 6.
> >
>
>
> Thanks :)
> I'm taking it as a faux pas, but that won't be the case if it happens
again.
>
>
> >>
> >> >>
> >> >>> 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.
> >> >
> >>
> >>
> >> Tell me about it... :) Being able to do hg export/import would be
easier.
> >>
> >>
> >> > 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.
> >> >
> >>
> >>
> >> The immediate problem I see is that OpenJDK6 is based on a version of
> >> OpenJDK7 not represented in Mercurial. Only b24 and on are, and I
> >> believe OpenJDK6 was forked prior to this.
> >>
> >>
> >> >>
> >> >>> 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.
> >>
> >>
> >> My understanding is that while development for 7 continued to hs15 and
> >> hs166 in the public jdk7/hotspot repositories, a fork was silently
> >> created inside Sun of hs14 for the 6 update releases. This is what
> >> has now finally been published as hsx. The fork came as a shock to
> >> me, and it would have been a whole lot better if it had been created
> >> in public to begin with. Thus, my understanding is that hsx will
> >> continue to evolve while a version of hs14 is needed for the 6
> >> updates.
> >>
> >>
> >> >
> >> >>
> >> >>> * 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.
> >> >
> >>
> >>
> >> Would be nice, but see my comment about b24 above.
> >>
> >>
> >> >>
> >> >>> * 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.
> >>
> >>
> >> No there isn't. We wouldn't have made a fuss for three months about
> >> it if there was :)
> >>
> >>
> >> >
> >> >> 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.
> >> >
> >>
> >>
> >> Nothing would surprise me at this stage. To be honest, I'm just
> >> getting a little sick and tired of all these forks, especially when
> >> (to the outside world) many seem unnecessary. With IcedTea, we
> >> deliberately went down a more difficult path of patching the upstream
> >> source and trying to contribute the patches upstream rather than just
> >> forking. This was done for the good of the community. What Sun did
> >> with hs14 seems to go against the entire purpose of the OpenJDK
> >> project and I'd like to assume it was just a mistake.
> >>
> >> Even when JDK7 is released, I don't see 6 disappearing overnight. By
> >> that time, I think we want to be in a situation where OpenJDK6 is an
> >> open-source version of what Sun shipped as the last 6 update release
> >> (well minus the plugin but that's a whole other story). There's no
> >> real reason for this not to be the case AFAICS except the need for
> >> time and effort to get everything out in the open and into OpenJDK6.
> >>
> >>
> >> >>
> >> >>> * 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.
> >> >
> >>
> >>
> >> We're saying the same, except I'm talking about using hsx while you're
> >> talking about using jdk7/hotspot. The latter would lose us the 6 new
> >> build drops of hs14.
> >>
> >>
> >> >>
> >> >>> 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".
> >> >
> >>
> >>
> >> Unfortunately they aren't the same. I wish they were.
> >>
> >>
> >> >>
> >> >>> 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
> >> >>>
> >> >>>
> >> >>>
> >> >>
> >> >>
> >> >>
> >> >
> >>
> >>
> >>
> >>
> >> --
> >> Andrew :-)
> >>
> >> Free Java Software Engineer
> >> Red Hat, Inc. (http://www.redhat.com)
> >>
> >> Support Free Java!
> >> Contribute to GNU Classpath and the OpenJDK
> >> http://www.gnu.org/software/classpath
> >> http://openjdk.java.net
> >>
> >> PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
> >> Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8
> >>
> >
>
>
>
>
> --
>
> Andrew :-)
>
> Free Java Software Engineer
> Red Hat, Inc. (http://www.redhat.com)
>
> Support Free Java!
> Contribute to GNU Classpath and the OpenJDK
> http://www.gnu.org/software/classpath
> http://openjdk.java.net
>
> PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
> Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/jdk6-dev/attachments/20090602/424e2a66/attachment.html
More information about the jdk6-dev
mailing list