Merge ppc port into jdk7u-dev

[Andrew Hughes]

----- Original Message -----
> On 21/07/16 16:52, Andrew Hughes wrote:
> > As a compromise, I suggest doing a single patch for the main
> > patch import (up to changeset 9ee6abf28de9) which corresponds
> > to the whole port in the same way the initial AArch64 port was
> > done, and gets rid of the problematic changesets.
> > 
> > The remaining changesets, which either have OpenJDK bug IDs or
> > could trivially be assigned them, should be imported
> > as-is, so they will then be recorded as fixed in OpenJDK 7, rather
> > than being lost in a mega patch.
> 
> But if they are bug fixes to a new import then they will never have
> been recorded as broken in OpenJDK 7, so why do they need to be
> recorded as fixed in OpenJDK 7?
> 
> Andrew.
> 
> 

I'm not sure what you mean by "recorded as broken in OpenJDK 7".
It would be the same as for other fixes we backport; they are filed
as bugs against 9, but backports are often made all the way back
to 6.

For a bug ID such as the recent 8158260, I can do:

$ hg log -R ../jdk9/hotspot -k 8158260
changeset:   11520:5f3687f2143c
user:        simonis
date:        Fri Jun 17 11:31:24 2016 +0200
summary:     8158260: PPC64: unaligned Unsafe.getInt can lead to the generation of illegal instructions

$ hg log -R ../jdk8/hotspot -k 8158260
changeset:   7947:6021c95f5944
user:        simonis
date:        Tue Jun 14 19:48:30 2016 +0200
summary:     8158260: PPC64: unaligned Unsafe.getInt can lead to the generation of illegal instructions

$ hg log -R ../icedtea7/hotspot -k 8158260
changeset:   6414:601fbf4bf8c1
tag:         tip
user:        simonis
date:        Wed Jul 20 03:15:59 2016 +0100
summary:     8158260, PR2992, RH1341258: PPC64: unaligned Unsafe.getInt can lead to the generation of illegal instructions

I guess you could do that by including all the bug IDs in
the mega patch too, but, in general, this idea of mega patches
just defeats the whole point of using a version control
system altogether.

With OpenJDK 6, I still regularly run into changes which come
down to bulk imports of tarballs from before we had the
Mercurial trees, such as "6755902: Changes for openjdk6 build 03",
and it makes it very hard, if not impossible, to know why a
particular change was made.

When backporting changes, you find differences between e.g. 7 and 8,
and you need this kind of data mining, from tools like hg annotate, in
order to establish why that change exists and whether or not it needs
to be kept.
-- 
Andrew :)

Senior Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

PGP Key: ed25519/35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222