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


Reply via email to