RFR: JDK-8145564: 8036003: startup regression on linux fastdebug builds

[Alejandro E Murillo]

On 12/16/2015 5:40 PM, David Holmes wrote:
> On 17/12/2015 7:35 AM, Erik Joelsson wrote:
>> One more thing, where should this fix be pushed? Do you need it urgently
>> in hs-rt?
>
> It is urgently needed in both the hs-rt and hs-comp repos as it 
> affects nightly testing and JPRT. If Alejandro agrees I suggest 
> pushing to jdk9/hs and it can then be pulled down to the team repos.
Fine with me.
It will go through PIT this weekend
Alejandro

>
> With regard to the fix ... previously DEBUG_BINARIES was never set in 
> spec.gmk and so was never externally introduced into the hotspot build 
> this way. So why not simply change the name of the variable so that it 
> has no affect on the hotspot part of the build?
>
> Thanks,
> David
>
>> /Erik
>>
>> On 2015-12-16 22:34, Erik Joelsson wrote:
>>> Hello,
>>>
>>> Please review this quick fix for the build issue introduced in Hotspot
>>> by JDK-8036003. The short story is that if you set DEBUG_BINARIES=true
>>> when building Hotspot fastdebug, you essentially get a slowdebug
>>> build. For an explanation of why, see comment in bug. This behavior is
>>> of course also a bug, but not something I will address in this quick 
>>> fix.
>>>
>>> What happened in JDK-8036003 was that a new configure API for
>>> controlling debug symbols was introduced. The two main settings of
>>> this new parameter, --with-native-debug-symbols, that we use
>>> internally at Oracle are "external" and "zipped". It was important to
>>> us that the behavior of these did not change with JDK-8036003, but
>>> exactly that did happen, because both of these settings now cause
>>> DEBUG_BINARIES=true to be set. This variable has never been set by
>>> configure before and because of the above weird behavior in the
>>> Hotspot makefiles, we are having problems.
>>>
>>> My proposed quick fix is to not set DEBUG_BINARIES=true for "external"
>>> or "zipped". It can remain true for "internal" since Oracle never
>>> builds it that way, and I understand those that requested this new
>>> configure parameter were setting DEBUG_BINARIES=true as a workaround
>>> before this anyway, so they should be fine with the broken fastdebug
>>> behavior for a while more. I will file a follow up bug to properly
>>> clean up this mess, but it will take some more time.
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8145564
>>> Webrev: http://cr.openjdk.java.net/~erikj/8145564/webrev.01/
>>>
>>> /Erik
>>

-- 
Alejandro