Fwd: Re: How to decrease size of j2sdk_image

[Daniel D. Daugherty]

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.daugherty at oracle.com
>>>> <mailto:daniel.daugherty at 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.daugherty at oracle.com
>>>>> <mailto:daniel.daugherty at 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.wang at oracle.com>
>>>>>> <mailto:weijun.wang at oracle.com>
>>>>>> To: discuss at openjdk.java.net
>>>>>> <mailto:discuss at 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
>>>>>> >
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>