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

[Volker Simonis]

Great! Thanks a lot David,

Volker

On Thu, Jan 14, 2016 at 4:41 AM, David Holmes <david.holmes at oracle.com> wrote:
> 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
>>>>
>>>
>