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

[Volker Simonis]

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.baesken at 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
>