David is right. It is amazing how many times I read right past
the fact that the wrong make variable was being used. The right
make invocation is:
make FULL_DEBUG_SYMBOLS=0
The ENABLE_FULL_DEBUG_SYMBOLS make variable is what is used in
the various makefiles to implement the logic checks for the
FDS feature.
Here is the text from the (currently internal) FDS FAQ:
8) How do I build without FDS?
Invoke your build with "FULL_DEBUG_SYMBOLS=0", e.g., with a JPRT
job, use "-buildenv FULL_DEBUG_SYMBOLS=0" on the JPRT submit
command line. That will disable the Full Debug Symbols for
"product" builds (HotSpot) and for "OPT" builds (JDK).
Some folks have asked how to disable FDS on all builds. Invoke
your build with "ALT_OBJCOPY=/no_such_path", e.g., with a JPRT
job, use "-buildenv ALT_OBJCOPY=/no_such_path" on the JPRT submit
command line. That will disable the Full Debug Symbols for all
Linux and Solaris builds.
There isn't a way to disable FDS on all Windows builds.
"FULL_DEBUG_SYMBOLS=0" does disable FDS for Windows "product"
builds (HotSpot) and for Windows "OPT" builds (JDK). FDS had been
hard-coded as enabled on Windows since JDK1.4.1 so being able to
disable it for "product" builds was a step forward.
Dan
On 10/11/12 11:20 PM, David Holmes wrote:
On 10/11/12 9:09 AM, matchew wrote:
Understand. But why still when ENABLE_FULL_DEBUG_SYMBOLS is set
to 0 these files are generated?
Because you have to set FULL_DEBUG_SYMBOLS=0 when invoking make, not
ENABLE_FULL_DEBUG_SYMBOLS=0. From the makefiles:
# The Full Debug Symbols (FDS) default for VARIANT == OPT builds is
# enabled with debug info files ZIP'ed to save space. For VARIANT !=
# OPT builds, FDS is always enabled, after all a debug build without
# debug info isn't very useful. The ZIP_DEBUGINFO_FILES option only has
# meaning when FDS is enabled.
#
# If you invoke a build with FULL_DEBUG_SYMBOLS=0, then FDS will be
# disabled for a VARIANT == OPT build.
#
# Note: Use of a different variable name for the FDS override option
# versus the FDS enabled check is intentional (FULL_DEBUG_SYMBOLS
# versus ENABLE_FULL_DEBUG_SYMBOLS). For auto build systems that pass
# in options via environment variables, use of distinct variables
# prevents strange behaviours. For example, in a VARIANT != OPT build,
# the FULL_DEBUG_SYMBOLS environment variable will be 0, but the
# ENABLE_FULL_DEBUG_SYMBOLS make variable will be 1. If the same
# variable name is used, then different values can be picked up by
# different parts of the build. Just to be clear, we only need two
# variable names because the incoming option value can be overridden
# in some situations, e.g., a VARIANT != OPT build.
David
-----
What type of build are you doing? The ENABLE_FULL_DEBUG_SYMBOLS
flag only disables the feature for "product bits" builds. For a
JDK build that is an "OPT" build. For a HotSpot build that is a
"product" build.
Dan
2012/10/11 Daniel D. Daugherty <daniel.daughe...@oracle.com
<mailto:daniel.daughe...@oracle.com>>
On 10/11/12 8:50 AM, matchew wrote:
what about openjdk builds used for example by ubuntu package
manager (default repos)? these builds do not have these
debug files (*.diz) at all.
I don't know how Ubuntu builds the OpenJDK repos so I can't
really comment on why those builds don't have debug info files.
Downstream projects can change the default settings and several
of the downstream Linux project have enabled even more debug
info in their builds.
If i am not considering jvm/jdk native code debugging is it
safe to just remove them all?
It's your build. If you don't think you need the debug info, then
you can remove it.
Dan
2012/10/11 Daniel D. Daugherty <daniel.daughe...@oracle.com
<mailto:daniel.daughe...@oracle.com>>
On 10/11/12 3:21 AM, Seán Coffey wrote:
Moving this off discuss mailing list to build-dev.
Why is ENABLE_FULL_DEBUG_SYMBOLS being set to 1 for
many product builds now ? It slows down the build and
creates increased bundle size even though the majority
of users do not require this functionality.
The Full Debug Symbols feature will eventually be
enabled for all
OSes for which Oracle generates bits. I think MacOS X is
the last
platform and that work is tracked by:
7165611 3/3 implement Full Debug Symbols on MacOS X
The default setting for ENABLE_FULL_DEBUG_SYMBOLS is "1"
(enabled)
because the Full Debug Symbols feature is intentionally
enabled in
all promoted bits for diagnosibility and debuggability.
If FDS is
not enabled when the promoted bits are built, then the
debug info
generated by a rebuild of *exactly the same source* with
FDS enabled
cannot be (reliably) used with the promoted bits.
You might be saying:
That's fine for promoted bits, but what about the
rest of us?
The answer there is actually simple. We want our
developer private
builds and automated system builds, e.g., JPRT, to match
what Release
Engineering builds. We don't want RE to be surprised by
an integration
that builds fine when FDS is disabled only to blow up
when FDS is
enabled.
Similarly, we also don't want SQE/SQA to be surprised by
different
test results with bits built by RE versus bits built
with FDS disabled,
e.g., JPRT. Enabling "debug info" in a build changes the
compiler
optimizations and that changes the bits in the binary.
Those changes
in the binary might mask a bug that only shows up after
RE has built
with FDS enabled. Conversely, if you disable FDS in your
private build,
you might end up chasing a bug that only reproduces in
your private
build and doesn't reproduce in an FDS enabled build.
Could we consider flipping the default for
ENABLE_FULL_DEBUG_SYMBOLS to 0 ? (like I've done for
all my build scripts?)
For the reasons I stated above, no we won't change the
default for
ENABLE_FULL_DEBUG_SYMBOLS to "0" (disabled) unless
Oracle changes
the way that promoted bits are built.
You are welcome to disable the feature in your private
builds which
is why I added the ENABLE_FULL_DEBUG_SYMBOLS flag.
However, please
remember that any testing that you do with those bits
won't necessarily
match testing done with the official promoted bits.
Dan
regards,
Sean.
-------- Original Message --------
Subject: Re: How to decrease size of j2sdk_image
Date: Thu, 11 Oct 2012 14:57:46 +0800
From: Weijun Wang <weijun.w...@oracle.com>
<mailto:weijun.w...@oracle.com>
To: disc...@openjdk.java.net
<mailto:disc...@openjdk.java.net>
You can try set ENABLE_FULL_DEBUG_SYMBOLS to 0.
-Max
On 10/11/2012 02:38 PM, matchew wrote:
>
> After successful openJDK7 build (Ubuntu 12.04) i have found that
> 'j2sdk-image' has 240MB. More than 100MB belongs to one directory:
> openjdk7/jre/lib/amd64
>
> Can anyone explain me why it is so big? For example in openJDK7
installed
> via package manager this folder has only 18MB
>
> Is there any way to decrease its size?
>
> Thanks in advance
> --
> Mateusz
>
