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).
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 details https://gcc.gnu.org/onlinedocs/gccint/LTO-Overview.html and http://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
