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

[Volker Simonis]

On Mon, Feb 16, 2015 at 5:48 PM, Andrew Hughes <gnu.andrew at redhat.com> wrote:
> snip...
>
>> >
>> > 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/
>>
>
> Thanks. I see OpenJDK 9 still doesn't have aarch64; that seems to be
> the only difference.
>
>> 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.
>
> Thanks. I thought arch-specific changes were now able to go through
> without Oracle sponsorship? Anyway, if David is willing to shepherd
> it through, it's not a problem.
>

It's not arch-specific changes which external committers can push on
their own it's just changes which only touch arch-specific files of
non-Oracle architectures :)

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