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

David Holmes david.holmes at oracle.com
Thu Feb 26 07:58:11 UTC 2015

On 26/02/2015 12:31 PM, David Holmes wrote:
> On 26/02/2015 2:57 AM, Andrew Hughes wrote:
>>>>> These are the revised versions of the webrevs:
>>>>> http://cr.openjdk.java.net/~andrew/rh1191652/webrev.02/root/
>>>>> http://cr.openjdk.java.net/~andrew/rh1191652/webrev.02/jdk/
>>>>> http://cr.openjdk.java.net/~andrew/rh1191652/webrev.02/hotspot/
>>>>> (HotSpot is unchanged, dropped the sound changes from JDK)
>> Ok if I push the jdk and root parts then? I think someone on the Oracle
>> HS team (David?) needs to push the HotSpot bit.
> Best to push it all together I think, which I can do through the hs-rt
> forest. But first I need to see where things settled with all this :) I
> was quite confused by some of the initial suggestions. Will try to get
> to this today.

I'm still very confused by these changes and have trouble tracking the 
values of the various "arch" related variables. If I follow this right 
presently the only distinction between ppc64 and ppc64le is the value of 
OPENJDK_TARGET_CPU_ENDIAN. In particular they both use ppc64 as the 
hotspot LIBARCH value and ppc as the ARCH value. (Aside: so ARCH/ppc64 
is either unused or only used by a hotspot-only build?)

The desired change is that the top-level architecture (VAR_CPU which 
becomes OPENJDK_TARGET_CPU) should now be ppc64le not ppc64, but that 
for hotspot the only difference is LIBARCH becomes ppc64le. So to 
achieve this hotspot-spec.gmk switches ARCH to be ppc64 instead of the 
current ppc; and then hotspot's def.make uses that combined with being 
lttle-endian to reset the LIBARCH to ppc64le.

This all seems very convoluted! Why can you not simply check the value 
of BUILD_ARCH for ppc64 and then check the endianess to redefine 
LIBARCH? That way you don't need to change ARCH as set by hotspot-spec.gmk.

Does "uname -m" return ppc64le ? I'm unclear whether either your 
proposal or mine actually works correctly for a hotspot-only build. But 
maybe we just don't care about builds not done via configure any more.


Given the LIBARCH switcheroo that happens in hotspot/make/def.make, why 
bother also doing the switcheroo in 
<top>/common/autoconf/hotspot-spec.gmk.in when you could just do 
everything in hotspot/make/defs

> David
> -----
>> Thanks,

More information about the hotspot-dev mailing list