Differences between OpenJDK 6 hotspot tip and hsx14/master tip (Was: hg: jdk6/jdk6/hotspot: 557 new changesets)

[Martin Buchholz]

The major whitespace related changes were
- removing trailing whitespace
- changing TAB to equivalent spaces (like Emacs M-x untabify)
I think Kelly had a script to do this - perhaps it can be shared?

One thing I've done in the past is to do a whitespace cleansing
pass on just the conflicting files before doing a merge.
We might consider redoing the merge with such a different strategy.

I imagine that we want the tip of the openjdk6 hotspot to be very
close to the tip of the hsx14 stable branch - perhaps identical.
And that includes whitespace!
Any differences should be only to deal with any possible
mismatches with having to deal with an older library implementation.
But the hotspot team tries hard to maintain such backward
compatibility.  And they have to, in order to be able to ship with
proprietary jdk6 updates.

Martin

On Mon, Sep 14, 2009 at 12:47, Andrew John
Hughes<gnu_andrew at member.fsf.org> wrote:
> 2009/9/14 Dalibor Topic <Dalibor.Topic at sun.com>:
>> Congrats, Andrew, and thanks for pushing this.
>>
>> I've tried to build OpenJDK 6 with the updated hotspot code, and
>> noticed immediate build breakage on OpenSolaris 2009.06, due to the
>> line 361 in hotspot/make/solaris/makefiles/buildtree.make :
>>
>>    360
>>    361 include $(GAMMADIR)/build/solaris/makefiles/rules.make
>>    362
>>
>> Of course, since there is no hostpot/build directory, the build
>> fails. Curiously enough, the hsx 14 / master repository does not
>> have those lines in that makefile, so I'm puzzled how or why they
>> are in the OpenJDK 6 hsx 14.
>>
>> Running a diff on the hotspot repo in OpenJDK 6 vs the master of
>> hsx14 shows a lot of differences, mostly whitespace, but also in
>> several makefiles and the THIRD_PARTY_README file, curiously enough.
>>
>> Are we missing some changesets in the hotspot repo?
>>
>> cheers,
>> dalibor topic
>> --
>> *******************************************************************
>> Dalibor Topic                   Tel: (+49 40) 23 646 738
>> Java F/OSS Ambassador           AIM: robiladonaim
>> Sun Microsystems GmbH           Mobile: (+49 177) 2664 192
>> Nagelsweg 55                    http://openjdk.java.net
>> D-20097 Hamburg                 mailto:Dalibor.Topic at sun.com
>> Sitz der Gesellschaft: Sonnenallee 1, D-85551 Kirchheim-Heimstetten
>> Amtsgericht München: HRB 161028
>> Geschäftsführer: Thomas Schröder, Wolfgang Engels, Wolf Frenkel
>> Vorsitzender des Aufsichtsrates: Martin Häring
>>
>>
>>
>
> I guess it was inevitable a change of this size wouldn't go through
> without problems, even though both myself and Joe have been through
> it.  I verified the GNU/Linux build but, being unable to do either a
> Solaris or Windows build with Free tools, I haven't been able to
> verify those.  Long term, it would be nice for everyone to have the
> ability to submit patches for test runs as we did for a HotSpot patch
> recently.  That would catch most issues.
>
> What I think has happened here is that the rebasing reverted some of
> the hs14 files to their original OpenJDK6 versions.  I'm guessing that
> the file may not match hs14, but I suspect it's pretty close to the
> original OpenJDK6 one prior to the rebase (remembering way back to
> when we used hs12, it did still use the build directory). If you check
> the history, you'll see that the OpenJDK6 changesets are in there
> right at the bottom.  There are probably OpenJDK6 changes that never
> went into hs14 too, so these are worth keeping for more than just
> history IMO.
>
> And yes, I hate the whitespace changes, they made merging this far
> from straightforward.  I'm guessing some whitespace-cleansing process
> was applied to the HotSpot sources between the OpenJDK6 version and
> the one in OpenJDK7 b24; it would be nice to apply it to OpenJDK6's
> hs14 so that they do match  You'll see a lot of the rebasing changes
> at the bottom flip whitespace changes around.
>
> I'm afraid little foibles like this are the side-effect of retaining
> both the entire OpenJDK6 and hs14 histories in our repository, but in
> the long run that should help with debugging than doing some huge
> import of the tip of hs14 in one changeset, or starting from hs14 and
> losing any OpenJDK6 changes.
> --
> 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
>