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

[David Holmes]

On 16/06/2020 12:34 am, Magnus Ihse Bursie wrote:
> 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...)

Part of my concern as well. It was not clear from the bug report that 
these are _only_ used by C++ exceptions, otherwise why would gcc 
generate them when we have C++ exceptions disabled?

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

And in a non-debug build what does a stacktrace look like? It is correct 
but non-symbolic?

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

Yes that is the requirement, but I'm not clear to what extent these 
requirements have been verified. Have different hs_err generation 
contexts been examined or only the synchronous ones produced by the test 
flag? What kind of debugging has been checked?

> 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).

We obviously have a different view on where the pre-integration testing 
bar should be set. Please at least ensure mach5 tiers 1-3 pass before 
pushing.

Thanks,
David

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