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

[Aleksei Voitylov]

Magnus, Matthias,

for me, lto is a little heavyweight for development. x86_64 build time
with gcc 7:

Server 1m32.484s
Server+Minimal 1m42.166s
Server+Minimal (--with-jvm-features="link-time-opt") 5m29.422s

If the change to enable lto by default is proposed, what would be the
recommended strategy for development?

For ARM32 Minimal, please keep in mind that it's not uncommon to disable
LTO plugin in commodity ARM32 gcc compiler distributions, so for some it
does not matter what settings we have in OpenJDK. I believe there could
be other reasons for that on top of build time (bugs?).

-Aleksei

On 14/01/2020 17:04, Magnus Ihse Bursie wrote:
> On 2020-01-14 13:49, Baesken, Matthias wrote:
>>
>> Hi Magnus, thanks for the info , I already noticed yesterday the
>> setting for arm-32 in the minimal build .
>>
>> Do you think  we could set it too for the other Linux platforms  in
>> the minimal build  ( serviceability agent is not supported there as
>> well so the  observed issue wouldn’t be a problem).
>>
>
> You mean if you could enable it on your builds without any issues? I'd
> guess so, but I don't know. Just try it:
> --with-jvm-features="link-time-opt".
>
> If you mean that it should be turned on by default on minimal builds
> for all platforms? No, I don't think that's a good idea. The link time
> is really a killer. I remember arm-32 going from like a couple of
> minutes to half an hour for linking libjvm.so.
>
> Things might be different with gold, though. I know they have done
> work with at least some kind of "lightweight" LTO, that might be worth
> at least looking into.
>
> /Magnus
>
>
>> Best regards, Matthias
>>
>> On 2020-01-10 11:01, Baesken, Matthias wrote:
>>
>>     Hello,   I recently looked into  the  gcc  lto  optimization mode
>> (see for some
>> detailshttps://gcc.gnu.org/onlinedocs/gccint/LTO-Overview.html  
>> andhttp://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 ?
>>
>>
>> Hi Matthias,
>>
>> We used to have LTO enabled on the old, closed-source Oracle arm-32
>> builds. There is still a "link-time-opt" JVM feature present; afaik
>> it still works and adds the -flto flag. The main drawback of this is
>> the *extremely* long link times of libjvm.so.
>>
>> I don't think servicability was ever supported for that platform, so
>> I'm not surprised this does not work.
>>
>> /Magnus
>>
>>
>>     And to the  serviceability   agent experts -  any idea  how to
>> make the  jdk.hotspot.agent   more independent from  optimization
>> settings ?
>>
>>     Best regards, Matthias
>>
>