SA pretends to know the exact types of objects in the JVM and for polymorphic objects it wants to read their vtable from the shared library. If LTO de-virtulizes methods and thus changes polymorphic to non-polymorphic types, this won't work. But if LTO can de-virtulizes a type, maybe you can do that manually (and update the corresponding representation in the SA), because it doesn't seem to be needed.
Notice that other places in the VM may also rely on this. E.g. CDS stores Metadata objects in the CDS archive and restores their vtable pointers when they are loaded. On the other hand, if the CDS tests have passed, this doesn't seem to be a problem. Baesken, Matthias <matthias.baes...@sap.com> schrieb am Fr., 10. Jan. 2020, 11:03: > 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 >
