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

[David Holmes]

On 18/12/2015 1:58 AM, Daniel D. Daugherty wrote:
> DEBUG_BINARIES is one of those "hidden" HotSpot big hammers that only
> affects Linux (IIRC). Basically, many years ago someone got tired of
> trying to figure out how to get completely debuggable HotSpot build
> on Linux and this big hammer was dropped in. I could chase down who
> and when, but I don't think that really matters...

Unfortunately it also got "cloned" into BSD and AIX ports.

Thanks for the additional info.

David
-----

> When I did FDS a few years back, I was asked to not break the semantics
> of DEBUG_BINARIES and so the big hammer was left in. Solaris is my
> primary dev platform and DEBUG_BINARIES doesn't work there so I didn't
> mind leaving in DEBUG_BINARIES for the Linux folks...
>
> Fast forward to today... I don't think the entire patch needs to be
> backed out. Not touching DEBUG_BINARIES via configure is a "good idea"
> (TM) because it is such a big hammer. I do recommend trying to deprecate
> the DEBUG_BINARIES setting in the big HotSpot Makefile rewrite...
>
> I'm very much looking forward to a cleaner HotSpot build...
>
> Dan
>
>
> On 12/17/15 2:24 AM, Erik Joelsson 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.
>>>
>> I didn't follow this particular review closely as Magnus was on it and
>> so I had missed the NativeCompilation part. It's true that it is very
>> unlikely to be part of the problem described in this bug, but I still
>> feel that the safest action at this point is to restore the behavior
>> of "external" and "zipped" to what they used to be. Magnus is working
>> on a complete fix where debug symbols will be enabled for everything
>> in NativeCompilation.
>>> I'm tempted to say rollback the whole thing rather than hack at it.
>>>
>> Rolling back will be much more work for me than submitting this patch.
>> There are two changes already that depend on this change. I also don't
>> dislike the idea of the new configure parameter.
>>> And apologies as I'm just about to go offline for a few hours at least.
>>>
>> I hope you won't object to me pushing this with just ihse as reviewer.
>> I feel this is rather a priority to get fixed.
>>
>> /Erik
>