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
