Hotspot shell games
Andrew John Hughes
gnu_andrew at member.fsf.org
Tue Jun 2 11:43:30 PDT 2009
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>:
>>>>> For now, though, we need to decide how to handle HSX vs Open6 vs.
>>>> 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.
>>> 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
> 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
>>> * 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
> 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
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
>> 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
>>> 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.
> Let's start looking into hsx-* tags!!! ;^)
Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)
Support Free Java!
Contribute to GNU Classpath and the OpenJDK
PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8
More information about the jdk6-dev