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