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

[Magnus Ihse Bursie]

 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