Re: serviceability agent : problems when using gcc LTO (link time optimization)

[Chris Plummer]

Hi Matthias, There is already support for lto in the configure script and makefiles. It was added long ago for minimalVM support. It was likely only ever used/tested with minimalVM, which does not support SA, thus the issue you are referring to did not show up. To enable minimalVM configure with:   --with-jvm-features=minimal I think this will also enable lto. If not, or if you want it without minimalVM, then configure with:   --with-jvm-features=link-time-opt Sorry, I can't offer any help on the SA polymorphic metadata issue. Hopefully someone else on this alias has some experience in that area. thanks, Chris On 1/10/20 2:01 AM, 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 ?   And to the  serviceability   agent experts -  any idea  how to make the  jdk.hotspot.agent   more independent from  optimization settings ?     Best regards, Matthias