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

[Alexander Smundak]

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