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

[Chris Plummer]

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