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

Fri Feb 13 17:40:11 UTC 2015

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

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