RFR: JDK-8150828 Consider using '-fno-asynchronous-unwind-tables' to reduce the size of libjvm.so by 10 percent

[Erik Joelsson]

Looks good to me at least.

/Erik

On 2020-06-12 05:21, Magnus Ihse Bursie wrote:
> From Volker's bug report:
>
> "We are building and linking the libjvm.so on Linux with 
> -fnoexceptions because we currently don't use C++ exception handling 
> in the HotSpot.
>
> Nevertheless, g++ generates unwind tables (i.e. .eh_frame sections) in 
> the object files and shared libraries which can not be stripped from 
> the binary. In the case of libjvm.so, these sections consume 10% of 
> the whole library.
>
> It is possible to omit the creation of these sections by using the 
> '-fno-asynchronous-unwind-tables' option during compilation and 
> linking. Ive verified that this indeed reduces the size of libjvm.so 
> by 10% on Linux/x86_64 for a product build:
>
> -rwxrwxr-x 1 simonis simonis 18798859 Feb 24 18:32 
> hotspot/linux_amd64_compiler2/product/libjvm.so
> -rwxrwxr-x 1 simonis simonis 17049867 Feb 25 18:12 
> hotspot_no_unwind/linux_amd64_compiler2/product/libjvm.so
>
> The gcc documentation mentions that the unwind information is used 
> "for stack unwinding from asynchronous events (such as debugger or 
> garbage collector)". But various references [1,2] also mention that 
> using '-fno-asynchronous-unwind-tables' together with '-g' will force 
> gcc to create this information in the debug sections of the object 
> files (i.e. .debug_frame) which can easily be stripped from the object 
> files and libraries.
>
> As we build the product version of the libjvm.so with '-g' anyway, I'd 
> suggest to use '-fno-asynchronous-unwind-tables' to reduce its size.
>
> I've done some quick tests (debugging, creation of hs_err files) with 
> a product version of libjvm.so which was build with 
> '-fno-asynchronous-unwind-tables' and couldn't find any draw backs. I 
> could observe that all the date from the current .eh_frame sections 
> has bee moved to the .debug_frame sections in the stripped out data of 
> the libjvm.debuginfo file."
>
> The patch itself is trivial, see below.
>
> Hotspot folks: Are there any reasons why we should not do it? I've 
> waited for JDK 16 to push this; if something unexpected  turns up 
> during the development of JDK 16 (if anything, it's odd corner cases 
> that might be a problem), we can always revert this.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8150828
> Patch inline:
> diff --git a/make/autoconf/flags-cflags.m4 
> b/make/autoconf/flags-cflags.m4
> --- a/make/autoconf/flags-cflags.m4
> +++ b/make/autoconf/flags-cflags.m4
> @@ -442,7 +442,8 @@
>    if test "x$TOOLCHAIN_TYPE" = xgcc || test "x$TOOLCHAIN_TYPE" = 
> xclang; then
>      # COMMON to gcc and clang
>      TOOLCHAIN_CFLAGS_JVM="-pipe -fno-rtti -fno-exceptions \
> -        -fvisibility=hidden -fno-strict-aliasing 
> -fno-omit-frame-pointer"
> +        -fvisibility=hidden -fno-strict-aliasing 
> -fno-omit-frame-pointer \
> +        -fno-asynchronous-unwind-tables"
>    fi
>
>    if test "x$TOOLCHAIN_TYPE" = xgcc; then
>
> /Magnus