Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8150828

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


    • Type: Enhancement
    • Status: Open
    • Priority: P3
    • Resolution: Unresolved
    • Affects Version/s: 9
    • Fix Version/s: 15
    • Component/s: infrastructure
    • Labels:
    • Subcomponent:
    • OS:


      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.

      [1] http://stackoverflow.com/questions/26300819/why-gcc-compiled-c-program-needs-eh-frame-section
      [2] https://www.chromium.org/chromium-os/build/c-exception-support




            • Assignee:
              ihse Magnus Ihse Bursie
              simonis Volker Simonis
            • Votes:
              0 Vote for this issue
              5 Start watching this issue


              • Created: