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

[David Holmes]

Reviewed, sponsored and pushed.

Cheers,
David

On 13/01/2016 11:56 PM, Volker Simonis wrote:
> 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
>>>
>>