RFR (M): 8036767 PPC64: Support for little endian execution model

Mon Feb 16 16:56:52 UTC 2015

----- Original Message -----
> OK, sounds good.
> 
> So Andrew, could you please elaborate what other changes this would
> require for the other repositories like jdk and top-level (preferably
> in the jdk9 context because that's where we've to start with before we
> can downport this to 8u-dev).
> 

On 7, it's the usual arch-specific additions; CFLAGS, jvm.cfg and the
javax.sound definitions.

I imagine it's similar on 8 but I'm working from the opposite direction here.
The bug was raised on 7 and I've been testing there. We'll need to fix it on
8 too, but 9 is difficult because I don't have a direct way of building on
ppc64le and there are currently no OpenJDK packages for 9.

So it may take a little while...

> Volker
> 
> 
> On Fri, Feb 13, 2015 at 6:25 PM, Alexander Smundak <asmundak at google.com>
> wrote:
> > I was always in favor of having ppc64le as a separate architecture.
> > I hope this will be backported to JDK8?
> >
> > On Fri, Feb 13, 2015 at 8:37 AM, Volker Simonis
> > <volker.simonis at gmail.com> wrote:
> >> On Fri, Feb 13, 2015 at 3:57 PM, Andrew Hughes <gnu.andrew at redhat.com>
> >> wrote:
> >>> ----- Original Message -----
> >>>> On 11/03/2014 6:36 PM, Volker Simonis wrote:
> >>>> > On Tue, Mar 11, 2014 at 4:29 AM, David Holmes
> >>>> > <david.holmes at oracle.com>
> >>>> > wrote:
> >>>> >> I don't see anything that actually controls what is built. Is it the
> >>>> >> case
> >>>> >> that the new arch value will be reported by uname on the ppc64le
> >>>> >> system?
> >>>> >>
> >>>> >> (I cringe seeing a new top-level arch introduced for this.)
> >>>> >>
> >>>> >
> >>>> > I didn't liked this too much as well in my first review and I think we
> >>>> > can get along without a new top-level arch (see
> >>>> > http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2014-March/001790.html).
> >>>> >
> >>>> > But in the end I can live with both approaches (and having two
> >>>> > top-level archs probably makes it slightly simpler to support them
> >>>> > both in parallel) so I think finally it is up to you which approach we
> >>>> > take.
> >>>>
> >>>> I agree with your initial review. I don't see a LE build as a distinct
> >>>> architecture but a variant of ppc64.
> >>>>
> >>>> Lets see what anyone else has to say.
> >>>>
> >>>> Thanks,
> >>>> David
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> > Regards,
> >>>> > Volker
> >>>> >
> >>>> >> Thanks,
> >>>> >> David
> >>>> >>
> >>>> >>
> >>>> >> On 7/03/2014 1:37 PM, Alexander Smundak wrote:
> >>>> >>>
> >>>> >>> This patch contains the changes to the build files to build JDK on
> >>>> >>> the
> >>>> >>> little endian PowerPC64 running Linux, and the changes to the source
> >>>> >>> files to support little endian mode.
> >>>> >>> This preceding related change
> >>>> >>> https://bugs.openjdk.java.net/browse/JDK-8036767 added support for
> >>>> >>> the
> >>>> >>> ELFv2 ABi used on the little endian PowerPC64.
> >>>> >>>
> >>>> >>> Please review and test this change. I need a sponsor.
> >>>> >>>
> >>>> >>> The patch is at:
> >>>> >>> http://cr.openjdk.java.net/~martin/asmundak/8036767/webrev.00/
> >>>> >>>
> >>>> >>> Sasha
> >>>> >>>
> >>>> >>
> >>>>
> >>>
> >>> We're now seeing problems with Java tools on ppc64le as a result of this
> >>> decision not to give it a distinct arch name.
> >>>
> >>> The os.arch property on both ppc64be and ppc64le builds of OpenJDK is
> >>> being
> >>> reported as the same; "ppc64". This leaves Java applications no way of
> >>> determining which of the two platforms the JDK is running on and, for
> >>> example,
> >>> means that Maven can't determine which native JNI binaries to download.
> >>>
> >>> There is a sun.cpu.endian property but this is non-standard and it seems
> >>> wrong to me that every Java tool should have to add a special case for
> >>> ppc64le using such a property. This value is traditionally not so much
> >>> just the architecture as a composite of the architecture, the bit size
> >>> and the endianness. The only difference with other platforms is that they
> >>> only support one default endianness so the value is implied e.g.
> >>> little-endian for amd64, big-endian for sparc. We do distinguish between
> >>> ppc and ppc64 rather than expecting tools to check sun.arch.data.model,
> >>> so we should do the same with endianness.
> >>>
> >>> To add to the confusion, other JDKs are reporting it as ppc64le
> >>> (thanks to Tiago Sturmer Daitx for these results):
> >>>
> >>> IBM Java 2.7 SR1
> >>> os.arch: ppc64le
> >>> sun.cpu.endian: little
> >>>
> >>> GCJ 4.8.2 (gij (GNU libgcj) version 4.8.2):
> >>> os.arch: ppc64le
> >>> sun.cpu.endian: null
> >>>
> >>> whereas OpenJDK gives:
> >>>
> >>> os.arch: ppc64
> >>> sun.cpu.endian: little
> >>>
> >>> It also means that ppc64le is alone in not having a unique architecture
> >>> directory in jre/lib. I understand that a ppc64le machine is not going
> >>> to support ppc64be, but likewise amd64 is not going to support arm,
> >>> yet they have unique arch directories.
> >>>
> >>> I've prepared a webrev which fixes the external facing architecture
> >>> names,
> >>> LIBARCH and os.name, while leaving the HotSpot build architecture,
> >>> BUILDARCH,
> >>> as it is, to avoid the duplication mentioned as a problem in the original
> >>> review.
> >>>
> >>> http://cr.openjdk.java.net/~andrew/rh1191652/webrev.01/
> >>>
> >>> This is against our IcedTea OpenJDK7-based HotSpot where we've been
> >>> testing
> >>> but it should still be applicable to the 9 HotSpot repositories. The JDK
> >>> side
> >>> is another issue and I suspect we'll need a completely different patch
> >>> there
> >>> to the one we have for 7.
> >>>
> >>> Our builds of OpenJDK 7 with this fixed now give:
> >>>
> >>> java.library.path =
> >>> /usr/java/packages/lib/ppc64le:/usr/lib64:/lib64:/lib:/usr/lib
> >>> sun.boot.library.path =
> >>> /builddir/build/BUILD/java-1.7.0-openjdk-1.7.0.75-2.5.4.5.ael7b.ppc64le/openjdk/build/linux-ppc64le/j2sdk-image/jre/lib/ppc64le
> >>> os.arch = ppc64le
> >>>
> >>> I've filed a bug for this here:
> >>>
> >>> https://bugs.openjdk.java.net/browse/JDK-8073139
> >>>
> >>> Thanks,
> >>> --
> >>> Andrew :)
> >>>
> >>> 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
> >>>
> >>> PGP Key: rsa4096/248BDC07 (hkp://keys.gnupg.net)
> >>> Fingerprint = EC5A 1F5E C0AD 1D15 8F1F  8F91 3B96 A578 248B DC07
> >>>
> >>
> >> Hi Andrew,
> >>
> >> I don't have a problem with your change and it doesn't affect the
> >> ppc64 big endian build.
> >>
> >> I've prepared a patch which applies cleanly to jdk9-hs-rt here:
> >>
> >> http://cr.openjdk.java.net/~simonis/webrevs/2015/8073139/
> >>
> >> Let's here some other opinions as well (you'll need a sponsor from
> >> Oracle anyway and it would also be interesting to here from Alexander
> >> if they already rely on os.arch being ppc64) but from my side thumbs
> >> up.
> >>
> >> Regards,
> >> Volker
> 

-- 
Andrew :)

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

PGP Key: rsa4096/248BDC07 (hkp://keys.gnupg.net)
Fingerprint = EC5A 1F5E C0AD 1D15 8F1F  8F91 3B96 A578 248B DC07