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

[David Holmes]

On 17/12/2015 7:24 PM, 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.

My concern is recognizing that these adjustments do in fact restore the 
old behaviour. From the hotspot side it seemed cleaner to avoid the 
breakage by using a different variable name.

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

Rolling back the new configure parameters and then reinstating them 
again would also not win us any friends as it would be very disruptive. 
As others have noted the way we introduce and remove configure 
parameters needs to be looked at. I was mainly concerned that the 
out-of-the-box default behaviour was unchanged.

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

Sure. I had verified that DEBUG_BINARIES is only ever tested against 
"true" so setting it to false should be as effective as not setting it 
at all.

I'll follow up separately to see where this was pushed and whether we 
need to pull it into anywhere else urgently.

Thanks,
David

> /Erik