Hotspot shell games

[Kelly O'Hair]

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.

> 
>>  * 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
>>
>>
>>
> 
> 
>