RFR (M): 8036767 PPC64: Support for little endian execution model
volker.simonis at gmail.com
Fri Feb 13 16:37:39 UTC 2015
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.
>> > 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
> 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-188.8.131.52-184.108.40.206.ael7b.ppc64le/openjdk/build/linux-ppc64le/j2sdk-image/jre/lib/ppc64le
> os.arch = ppc64le
> I've filed a bug for this here:
> 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
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:
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
More information about the hotspot-dev