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

Andrew Hughes gnu.andrew at redhat.com
Fri Feb 13 14:57:19 UTC 2015


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



More information about the hotspot-dev mailing list