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

[Volker Simonis]

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