Should we use '-fno-asynchronous-unwind-tables' to reduce the size of by 10 percent?

Volker Simonis volker.simonis at
Mon Feb 29 12:16:11 UTC 2016


We are currently building and linking the 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, 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
by 10% on Linux/x86_64 for a product build:

-rwxrwxr-x 1 simonis simonis 18798859 Feb 24 18:32
-rwxrwxr-x 1 simonis simonis 17049867 Feb 25 18:12

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

I've opened "8150828: Consider using '-fno-asynchronous-unwind-tables'
to reduce the size of by 10 percent" to track this issue:

and would be interested what others think about this "optimization"?
The only reason for not using it I can currently think of is that we
might have to switch exception handling on when we are integrating the
new "JEP 281: HotSpot C++ Unit-Test Framework".



More information about the build-dev mailing list