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

[Tiago Sturmer Daitx]

Hi all,


What's the status of this bug fix? It is not clear if the fix was ever
accepted - I haven't been able to find a commit for it.

If it was not accepted, what is missing to get this integrated into JDK9
and then backported to JDK8?

As for JDK7, IcedTea 2.6 (just released) has the fix and IIRC the
PPC-AIX-Port repository also has it. 

It would be good to get this into JDK8 ASAP, otherwise distros will need
to patch it on their own (those that aren't already).

This was reported initally at JDK-8073139 [1].

Best regards,
Tiago

[1] https://bugs.openjdk.java.net/browse/JDK-8073139

On Mon, 2015-03-02 at 18:38 +1000, David Holmes wrote:
> <trimming>
> 
> On 28/02/2015 5:06 AM, Andrew Hughes wrote:
> > ----- Original Message -----
> >> On 27/02/2015 11:25 AM, Andrew Hughes wrote:
> >>> ----- Original Message -----
> >>>> <trimming>
> >>>> 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.
> >>>
> >>> Well, I'd push it all myself if there weren't still restrictions on pushing
> >>> to HotSpot...
> >>>
> >>>>
> >>>> 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.
> >>>
> >>>   From ppc64le. Without the override in hotspot-spec.gmk, the HotSpot build
> >>> will get called with ARCH=ppc64le and fail, because make/defs.make will
> >>> set SRCARCH to x86
> >>
> >> No, ARCH comes from $(OPENJDK_TARGET_CPU_ARCH) which comes from
> >> $VAR_CPU_ARCH which is still ppc, not ppc64le. So SRCARCH will be set to
> >> ppc as per current code. Then BUILDARCH will check LP64 and so become
> >> ppc64. Then you can check endian-ness to define LIBARCH to ppc64le.
> >>
> >
> > Ah, not in 8 where this was tested:
> >
> >   ARCH=$(OPENJDK_TARGET_CPU_LEGACY)
> > +# ppc64le uses the HotSpot ppc64 build
> > +ifeq ($(OPENJDK_TARGET_CPU), ppc64le)
> > +  ARCH=ppc64
> > +endif
> >
> > OPENJDK_TARGET_CPU_LEGACY is set to OPENJDK_TARGET_CPU which is ppc64le in this case.
> >
> > 9 changed this with:
> >
> > 8046471: Use OPENJDK_TARGET_CPU_ARCH instead of legacy value for hotspot ARCH
> >
> > So it looks like we're going to end up with three different patches for this issue.
> 
> That explains all the confusion :)
> 
> >> Yes but you can do it based on the value of LIBARCH rather than a
> >> modified ARCH.
> >
> > Yes, with 8046471 in place. Hardly a huge difference though.
> 
> Avoiding the need to mess with what happens at the configure level in 
> hoptspot-spec.gmk.in makes it a lot simpler to follow IMHO.
> 
> 
> >> I don't know if I already had this conversation but it strikes me as
> >> really bizarre that the PPC64 port uses two different ARCH values
> >> depending on whether it is a configure-based build or not! ???
> >>
> >
> > It's not just that port. Every build either gets ARCH set by
> > hotspot-spec.gmk (by way of configure) or by uname -m in
> > make/linux/makefiles/defs.make. This is necessary if you're
> > going to allow someone to skip configure and just build HotSpot.
> 
> It's not the two different mechanisms that I was referring to, but the 
> fact that those mechanisms result in two completely different values for 
> ARCH for the same port. This just piles complexity on top of complexity.
> 
> > If no-one does that any more, then the old stuff that was needed
> > for 7 builds (no configure) could be culled.
> 
> Eventually the hotspot build will be all configure based. Even now I'm 
> not sure why people need to do a hotspot-only build this way rather than 
> just running configure and "make hotspot-only".
> 
> >> That aside if ARCH == ppc64 from uname then:
> >> - SRCARCH = ARCH/ppc64  = ppc
> >> - BUILDARCH = ppc64
> >>
> >> and so the same fix as above would work for this case.
> >>
> >
> > It doesn't, as I said. It's ppc64le. So the uname override is necessary.
> > For consistency, it probably should now be overridden to be ppc, not
> > ppc64, given the value passed in from configure changed to that in
> > 8046471.
> 
> Ok.
> 
> Thanks,
> David
> -----
> 
> >>> so our addition to hotspot-spec.gmk is just to do the same as this
> >>> block for configure builds.
> >>>
> >>> It was unneeded before because configure would just set the arch
> >>> to ppc64 for the entire build, not just HotSpot.
> >>
> >> AFAICS it set it to ppc not ppc64.
> >
> > I was referring to:
> >
> > -      VAR_CPU=ppc64
> > +      VAR_CPU=ppc64le
> >
> > and in turn OPENJDK_TARGET_CPU_LEGACY, not VAR_CPU_ARCH/OPENJDK_TARGET_CPU_ARCH.
> >
> >>
> >> David
> >> -----
> >>
> >>
> >>>> Thanks,
> >>>> David
> >>>>
> >>>>
> >>>> 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,
> >>>>>>
> >>>>
> >>>
> >>
> >
>