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

[Magnus Ihse Bursie]

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
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20200114/988e8edd/attachment-0001.htm>