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

[David Holmes]

On 17/12/2015 6:18 PM, Magnus Ihse Bursie wrote:
> On 2015-12-17 09:08, David Holmes wrote:
>> On 17/12/2015 5:54 PM, Erik Joelsson wrote:
>>>
>>>
>>> On 2015-12-17 01:40, 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.
>>>>
>>> Will do.
>>>> 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?
>>>>
>>> Well, we don't want it affecting the jdk part of the build either at
>>> this point. This patch aims to restore the "external" and "zipped"
>>> settings to exactly what they were before the patch, as was promised.
>>
>> I had not inferred from any of this that what was being done via
>> NativeCompilation.gmk was in any way a problem. I would have expected
>> any problems there to be readily seen before this was reviewed and
>> pushed. So I'm a bit confused about this.
>
> The changes in NativeCompilation.gmk looked perfectly fine. They turned
> out to trigger a bug (or, at the very least, very unsuspected behavior)
> which was deeply hidden in the hotspot linux makefiles, where setting
> DEBUG_BINARIES did indeed enable the -g flag, but also, as a side
> effect, turned fastdebug builds into slowdebug builds. This was not
> something that we could possibly forsee.

That was my understanding too - that this was simply a side-effect on 
hotspot, hence my suggestion to rename the variable. But Erik then said 
this was also not working correctly for the JDK side - which means the 
problem is far worse.

David
-----


>>
>> I'm tempted to say rollback the whole thing rather than hack at it.
>
> I don't think there is any compelling reason to rollback the whole
> change. The basic idea is sound. However, we do need to work on how to
> handle the debug symbols "under the hood". This deficit has been known
> for a long time to me and Erik but we have not spent any time on it.
> This change brought the problems up to daylight, and I think that's a
> good thing.
>
> I've started working on JDK-8145596, which will provide a proper
> solution to how we handle debug symbols. It is based on JDK-8036003.
>
> /Magnus
>
>
>>
>> And apologies as I'm just about to go offline for a few hours at least.
>>
>> David
>> -----
>>
>>
>>
>>> We will followup with a more complete fix.
>>>
>>> /Erik
>>>> 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
>>>>>
>>>
>