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

[Magnus Ihse Bursie]

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.

>
> 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
>>>>
>>