On 2020-01-14 13:49, Baesken, Matthias wrote:
Hi Magnus, thanks for the info , I already noticed yesterday the
setting for arm-32 in the minimal build .
Do you think we could set it too for the other Linux platforms in
the minimal build ( serviceability agent is not supported there as
well so the observed issue wouldn’t be a problem).
You mean if you could enable it on your builds without any issues? I'd
guess so, but I don't know. Just try it:
--with-jvm-features="link-time-opt".
If you mean that it should be turned on by default on minimal builds for
all platforms? No, I don't think that's a good idea. The link time is
really a killer. I remember arm-32 going from like a couple of minutes
to half an hour for linking libjvm.so.
Things might be different with gold, though. I know they have done work
with at least some kind of "lightweight" LTO, that might be worth at
least looking into.
/Magnus
Best regards, Matthias
On 2020-01-10 11:01, Baesken, Matthias wrote:
Hello, I recently looked into the gcc lto optimization mode (see for
some detailshttps://gcc.gnu.org/onlinedocs/gccint/LTO-Overview.html
andhttp://hubicka.blogspot.com/2019/05/gcc-9-link-time-and-inter-procedural.html
).
This mode can lead to more compact binaries (~10% smaller) , it also might
bring small performance improvements but that wasn't my (main) goal .
The changes for this are rather small , one needs to use a recent gcc ,
add -flto to the compile flags , for example
--- a/make/autoconf/flags-cflags.m4 Wed Jan 01 03:08:45 2020 +0100
+++ b/make/autoconf/flags-cflags.m4 Wed Jan 08 17:39:10 2020 +0100
@@ -530,8 +530,13 @@
fi
if test "x$TOOLCHAIN_TYPE" = xgcc; then
- TOOLCHAIN_CFLAGS_JVM="$TOOLCHAIN_CFLAGS_JVM -fcheck-new
-fstack-protector"
- TOOLCHAIN_CFLAGS_JDK="-pipe -fstack-protector"
+ TOOLCHAIN_CFLAGS_JVM="$TOOLCHAIN_CFLAGS_JVM -fcheck-new -fstack-protector
-flto"
+ TOOLCHAIN_CFLAGS_JDK="-pipe -fstack-protector -flto"
.... and you have to make sure to use gcc-ar and gcc-nm instead of
ar / nm .
Build and test(s) work, however with one exception.
The serviceability tests like serviceability/sa seems to rely heavily on the
"normal" structure of libjvm.so (from what I understand e.g. in
LinuxVtblAccess it is attempted to access internal symbols like _ZTV ).
Errors in the sa tests look like :
java.lang.InternalError: Metadata does not appear to be polymorphic
at
jdk.hotspot.agent/sun.jvm.hotspot.types.basic.BasicTypeDataBase.findDynamicTypeForAddress(BasicTypeDataBase.java:279)
at
jdk.hotspot.agent/sun.jvm.hotspot.runtime.VirtualBaseConstructor.instantiateWrapperFor(VirtualBaseConstructor.java:102)
at
jdk.hotspot.agent/sun.jvm.hotspot.oops.Metadata.instantiateWrapperFor(Metadata.java:74)
at
jdk.hotspot.agent/sun.jvm.hotspot.memory.SystemDictionary.getClassLoaderKlass(SystemDictionary.java:96)
at
jdk.hotspot.agent/sun.jvm.hotspot.tools.ClassLoaderStats.printClassLoaderStatistics(ClassLoaderStats.java:93)
at
jdk.hotspot.agent/sun.jvm.hotspot.tools.ClassLoaderStats.run(ClassLoaderStats.java:78)
at jdk.hotspot.agent/sun.jvm.hotspot.tools.JMap.run(JMap.java:115)
at
jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.startInternal(Tool.java:262)
at
jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.start(Tool.java:225)
at
jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.execute(Tool.java:118)
at
jdk.hotspot.agent/sun.jvm.hotspot.tools.JMap.main(JMap.java:176)
at
jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.runJMAP(SALauncher.java:321)
at
jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.main(SALauncher.java:406)
Has anyone experimented with LTO optimization ?
Hi Matthias,
We used to have LTO enabled on the old, closed-source Oracle arm-32
builds. There is still a "link-time-opt" JVM feature present; afaik it
still works and adds the -flto flag. The main drawback of this is the
*extremely* long link times of libjvm.so.
I don't think servicability was ever supported for that platform, so
I'm not surprised this does not work.
/Magnus
And to the serviceability agent experts - any idea how to make the
jdk.hotspot.agent more independent from optimization settings ?
Best regards, Matthias
