RFR: JDK-8145564: 8036003: startup regression on linux fastdebug builds (original) (raw)

David Holmes david.holmes at oracle.com
Thu Dec 17 21:33:41 UTC 2015

On 18/12/2015 1:58 AM, Daniel D. Daugherty wrote:

DEBUGBINARIES 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 DEBUGBINARIES and so the big hammer was left in. Solaris is my primary dev platform and DEBUGBINARIES doesn't work there so I didn't mind leaving in DEBUGBINARIES for the Linux folks...

Fast forward to today... I don't think the entire patch needs to be backed out. Not touching DEBUGBINARIES via configure is a "good idea" (TM) because it is such a big hammer. I do recommend trying to deprecate the DEBUGBINARIES 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 DEBUGBINARIES 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

More information about the build-dev mailing list