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

[David Holmes]

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.

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
>