RFR: JDK-8145564: 8036003: startup regression on linux fastdebug builds
erik.joelsson at oracle.com
Thu Dec 17 07:58:32 UTC 2015
I only got a bug report for Linux and can't test AIX. A quick look at
the makefiles for AIX, I think you are probably fine. At least the weird
construct in the Linux makefiles is not there to mess things up.
On 2015-12-17 07:49, Thomas Stüfe wrote:
> Hi Eric,
> short question, are other platforms beside Linux affected or is this
> Linux-specific (I saw you said Windows x64 showed no regression)?
> Reason I ask is, we just changed the default for AIX to "internal"
> because this is the only configuration we support and the build was
> broken after JDK-8036003 (see
> Kind Regards, Thomas
> On Wed, Dec 16, 2015 at 10:34 PM, Erik Joelsson
> <erik.joelsson at oracle.com <mailto:erik.joelsson at oracle.com>> wrote:
> 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/
More information about the hotspot-dev