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

[David Holmes]

Hi Magnus,

On 15/06/2020 10:57 pm, Magnus Ihse Bursie wrote:
> On 2020-06-12 15:09, Erik Joelsson wrote:
>> Looks good to me at least.
> Thank you Erik.
> 
> Any hotspotters who care to comment?

I'd like a little more assurance that nothing is broken than just:

"I've done some quick tests (debugging, creation of hs_err files)"

I don't know whether these tables play any part in stack walking.

Thanks,
David
-----

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