RFR(XS): 8146979: Backport of 8046471 breaks ppc64 build in jdk8u because 8072383 was badly backported before

[Volker Simonis]

On Wed, Jan 13, 2016 at 1:35 PM, David Holmes <david.holmes at oracle.com> wrote:
> Hi Volker,
>
> On 13/01/2016 9:40 PM, Volker Simonis wrote:
>>
>> Hi,
>>
>> I please need an urgent review for this little patch in jdk8u-dev
>> which fixes a build problem on ppc64.
>>
>> Can I push this myself directly to
>> http://hg.openjdk.java.net/jdk8u/jdk8u-dev/hotspot ?
>
>
> It is preferable that a shared file change goes through JPRT, just to avoid
> accidents.
>

Sure, if you volunteer as a sponsor :)

>> http://cr.openjdk.java.net/~simonis/webrevs/2016/8146979/
>> https://bugs.openjdk.java.net/browse/JDK-8146979
>>
>> Recently the change "8046471: Use OPENJDK_TARGET_CPU_ARCH instead of
>> legacy value for hotspot ARCH" was backporeted to jdk8u. It changes
>> the ARCH value which is passed from the top-level configure to the
>> hotspot make via the hotspot-spec.gmk file. For the ppc64 architecture
>> this changes the reported value for ARCH from 'ppc64' to 'ppc'.
>>
>> In jdk9 this is no problem, because the hotspot makefiles correctly
>> handle this value. Unfortunately in jdk8u this is not the case,
>> because the change "8072383: resolve conflicts between open and closed
>> ports" hasn't been correctly downported from jdk9 to jdk8u before.
>
>
> That backport was in February 2015 and seems to have been quite correct
> until now. I think it is the backport of 8046471 that has caused the problem

That's exactly what I wanted to express with the bug summary "Backport
of 8046471 breaks ppc64 build in jdk8u because 8072383 was badly
backported before" :)

The real problem is that the backport (i.e. 8073816) was not a "real"
backport but was done in parallel (and actually submitted even before)
8072383.

I've reviewed both changes at that time (see mail thread [1]) and
detected exactly this problem (see [2]) in the initial jdk9 version
(because jdk9 already contained 8046471 at that time). Dean included
the fix I proposed in his change for jdk9 so no problem. But now
somebody has decided to also downport 8046471 to jdk8u so we're facing
the same problems there. And they can be solved by the same fix.

[1] http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2015-February/thread.html#17121
[2] http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2015-February/017148.html

> - likely because there is a big difference in jdk9 and jdk8u with regards to
> our closed ports.
>
> That said the fix you propose may be fine but I need to verify a few things
> first - which I will do when I am in the office in the morning.

So will you push this trough JPRT? Would be great!

Thanks,
Volker

>
> Thanks,
> David
>
>
>> In jdk9 it contains the following lines:
>>
>> - SRCARCH = $(ARCH/$(filter sparc sparc64 ia64 amd64 x86_64 arm ppc
>> ppc64 aarch64 zero,$(ARCH)))
>> + SRCARCH ?= $(ARCH/$(filter sparc sparc64 ia64 amd64 x86_64 ppc ppc64
>> aarch64 zero,$(ARCH)))
>>
>>     ARCH/ppc64 = ppc
>>     ARCH/ppc = ppc
>> - ARCH/arm = arm
>>     ARCH/aarch64= aarch64
>>
>> but in the downport this was for whatever reason changed to:
>>
>> - SRCARCH = $(ARCH/$(filter sparc sparc64 ia64 amd64 x86_64 arm ppc
>> ppc64 zero,$(ARCH)))
>> + SRCARCH ?= $(ARCH/$(filter sparc sparc64 ia64 amd64 x86_64 ppc64
>> zero,$(ARCH)))
>>
>>     ARCH/ppc64 = ppc
>> - ARCH/ppc = ppc
>> - ARCH/arm = arm
>>     ARCH/zero = zero
>>
>> Notice how in jdk8u 'ppc' was removed from SRCARCH and how the line
>> 'ARCH/ppc = ppc' was completely deleted in jdk8u.
>>
>> We need to fix these two line in jdk8u in order to make the build work
>> again on ppc64.
>>
>> Regards,
>> Volker
>>
>