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-15 15:15, David Holmes wrote:
> 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.
I thought Volker's bug report were quite comprehensive.

Unwind tables are only used for C++ exception handling. This is not used 
by Hotspot. (Why gcc still generates those when they are not needed is a 
bit of a mystery...)

If we add -g (which we do), gcc will create the data needed for 
debugging in the debug sections, from where we strip it to debuginfo files.

If hs_err files are generated correctly, and it is possible to debug 
hotspot, I think that covers the areas that could be problematic?

If anything else can be broken by this, it is likely to be some odd 
corner-case. That's why I want this integrated at the start of JDK 16, 
so we have plenty of time to discover any potential issues, and if 
necessary, revert the change (or fix the problematic case).

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