On 2015-12-17 22:24, David Holmes wrote:
On 17/12/2015 6:18 PM, Magnus Ihse Bursie 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.
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.
That was my understanding too - that this was simply a side-effect on
hotspot, hence my suggestion to rename the variable. But Erik then
said this was also not working correctly for the JDK side - which
means the problem is far worse.
JDK-8036003 introduced the the use of DEBUG_BINARIES in jdk code as
well. So it "affects" jdk libraries as well, but not with the kind of
performance regression. However, it did enable debug information were we
didn't have it before in the Oracle builds. While I believe this is a
good thing, it should be added under more controlled forms. Therefore we
want to revert the effect of DEBUG_BINARIES for the kinds of build we do
at Oracle (external/zipped), keep the effect added in JDK-8036003 for
the new kind of builds the community requested (internal), and finally
we want to enable debug symbols for all our jdk libraries as a separate
change, JDK-8145596.
The only thing left to do is for the community to provide a fix to the
problem that the newly added functionality of debug-symbols=internal
means that hotspot in effect turns into a slowdebug build. Since the
community regularly builds by setting DEBUG_BINARIES=true on the command
line, it's not really a regression for them, but it's still a bug since
they get unnecessarily slow builds. Either they need to provide a patch,
or wait for the new hotspot build where this won't be a problem.
/Magnus
It was not "far worse", but
David
-----
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
