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
