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

[Baesken, Matthias]

Hello, thanks for  the info -  seems that for the minimal  VM ,  lto is fine but  currently not for the other (server/...) VM builds .

Btw.   I noticed similar issues with the SA  when using  link-time-gc . Looks like this eliminates the vtable info too that tha SA-coding  ( LinuxVtblAccess class ?)  wants to look into .


Best regards, Matthias


> cds is also disabled for minimalVM so testing of cds with LTO probably
> has not been done. There are a number of features that minimalVM
> excludes such as jvmti, cds and SA (which I think falls under
> "services"), and there was very little testing done with these features
> individually disabled. They would all at least build (if any one was
> disabled) and I think heartbeat testing was done, but probably no more
> than that. Also various combinations were not tested, other than the one
> combination that minimalVM used. Search for NON_MINIMAL_FEATURES in
> hotspot.m4 to see which features are disabled for minimalVM.
> 
> Chris
> 
> On 1/11/20 5:38 AM, Volker Simonis wrote:
> > 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.findDyna
> micTypeForAddress(BasicTypeDataBase.java:279)
> >>           at
> >>
> jdk.hotspot.agent/sun.jvm.hotspot.runtime.VirtualBaseConstructor.instanti
> ateWrapperFor(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.getClassLoad
> erKlass(SystemDictionary.java:96)
> >>           at
> >>
> jdk.hotspot.agent/sun.jvm.hotspot.tools.ClassLoaderStats.printClassLoaderS
> tatistics(ClassLoaderStats.java:93)
> >>           at
> >>
> jdk.hotspot.agent/sun.jvm.hotspot.tools.ClassLoaderStats.run(ClassLoaderS
> tats.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:3
> 21)
> >>           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
> >>