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

[Magnus Ihse Bursie]

On 2020-06-12 15:09, Erik Joelsson wrote:
> Looks good to me at least.
Thank you Erik.

Any hotspotters who care to comment?

/Magnus
>
> /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