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

Wed Jan 15 15:29:48 UTC 2020

Aleksei, Matthias,

thanks for the numbers. The size reduction on libjvm.so looks not bad,
indeed.

Do you know if newer versions of GCC use the gold linker by default? I
remember from some experiments which I did many years ago that gold was
considerably faster compared to the default ld linker.

Unfortunately, the documentation I found about LTO/ld/gold [1,2] seems to
be quite old and not very precise. Do you have gained any experience with
LTO/gold and know if gold could maybe improve linking times with LTO?

[1] https://gcc.gnu.org/wiki/LinkTimeOptimization
[2] https://stackoverflow.com/questions/31688069/requirements-to-use-flto

Baesken, Matthias <matthias.baesken at sap.com> schrieb am Mi., 15. Jan. 2020,
07:02:

> Hello , I can comment on   the  code size .  This is what I get when
> comparing  a build  without  and  with  -flto .
>
>
>
> gcc7 linux x86_64  product build, normal / with -flto
>
>
> ----------------------------------------------------------------------------------
>
>
>
> du -sh on the *.so files gives :
>
>
>
> 16K / 16K      ./lib/libattach.so
>
> 48K / 44K      ./lib/libawt_headless.so
>
> 752K / 760K    ./lib/libawt.so            <------------------ this one
> gets a bit larger with flto
>
> 472K / 456K    ./lib/libawt_xawt.so       <------------------ small gain
>
> 36K / 32K      ./lib/libdt_socket.so
>
> 16K /16K       ./lib/libextnet.so
>
> 1.5M / 824K    ./lib/libfontmanager.so     <------------------ HUGE gain
>
> 784K / 792K    ./lib/libfreetype.so        <------------------ this one
> gets a bit larger with flto
>
> 56K / 56K      ./lib/libinstrument.so
>
> 52K / 52K      ./lib/libj2gss.so
>
> 20K / 20K      ./lib/libj2pcsc.so
>
> 92K / 84K      ./lib/libj2pkcs11.so
>
> 12K / 12k      ./lib/libjaas.so
>
> 260K / 244K    ./lib/libjavajpeg.so         <----------------- small gain
>
> 196K / 188K    ./lib/libjava.so
>
> 12K / 12K      ./lib/libjawt.so
>
> 280K / 256K    ./lib/libjdwp.so             <----------------- small gain
>
> 144K / 140K    ./lib/libjimage.so
>
> 84K / 76K      ./lib/libjli.so
>
> 16K / 16K      ./lib/libjsig.so
>
> 88K / 80K      ./lib/libjsound.so
>
> 564K / 420K    ./lib/liblcms.so             <----------------- large gain
>
> 12K / 12K      ./lib/libmanagement_agent.so
>
> 40K / 36K      ./lib/libmanagement_ext.so
>
> 36K / 32K      ./lib/libmanagement.so
>
> 576K / 496K    ./lib/libmlib_image.so       <----------------- large gain
>
> 112K / 108K    ./lib/libnet.so
>
> 100K / 100K    ./lib/libnio.so
>
> 16K  / 16K     ./lib/libprefs.so
>
> 8.0K / 8.0K    ./lib/librmi.so
>
> 60K / 60K      ./lib/libsaproc.so
>
> 36K / 32K      ./lib/libsctp.so
>
> 368K / 212K    ./lib/libsplashscreen.so     <----------------- large gain
>
> 320K / 296K    ./lib/libsunec.so            <----------------- medium gain
>
> 72K / 72K      ./lib/libverify.so
>
> 44K / 44K      ./lib/libzip.so
>
> 16K / 16K      ./lib/server/libjsig.so
>
> 23M / 17M      ./lib/server/libjvm.so        <----------------- big gain
> maybe because it is C++ ?
>
>
>
>
>
> So  for  some libs  you see  10% and more , but not for all .   But  most
> large  libs  like   libjvm.so,  libfontmanager.so      or   liblcms.so
> we see good results regarding reduced code size.
>
>
>
> I Cannot say much about performance improvements , probably it would be
> small .
>
>
>
> For SPEC  you find something at
>
>
>
>
> http://hubicka.blogspot.com/2019/05/gcc-9-link-time-and-inter-procedural.html
>
>
>
> (not that these results would say too much about  JVM performance ).
>
>
>
>
>
> Best regards, Matthias
>
>
>
> *From:* Volker Simonis <volker.simonis at gmail.com>
> *Sent:* Mittwoch, 15. Januar 2020 14:40
> *To:* Aleksei Voitylov <aleksei.voitylov at bell-sw.com>
> *Cc:* Baesken, Matthias <matthias.baesken at sap.com>; Magnus Ihse Bursie <
> magnus.ihse.bursie at oracle.com>; serviceability-dev at openjdk.java.net;
> build-dev <build-dev at openjdk.java.net>; hotspot-dev at openjdk.java.net
> *Subject:* Re: serviceability agent : problems when using gcc LTO (link
> time optimization)
>
>
>
> While we are speaking about all the drawbacks of LTO, it's still not clear
> what the benefits are? In the very first mail Matthias mentioned that there
> might be performance improvements but that performance is not the main
> driving factor behind this initiative. So is it the reduced code size
> (Matthias mentioned something around ~10%)?
>
>
>
> It would be nice to see some real numbers on various platform for both,
> the performance improvements for native parts like JIT/GC as well as for
> the size reduction.
>
> Aleksei Voitylov <aleksei.voitylov at bell-sw.com> schrieb am Di., 14. Jan.
> 2020, 09:54:
>
>
> On 14/01/2020 19:57, Baesken, Matthias wrote:
> > Hello  Magnus and Aleksei,  thanks for the input .
> >
> > The times you  provided really look like they make a big difference  at
> least for people  often  building   minimal-vm  .
> > Guess I have to measure myself a bit  (maybe the difference is not that
> big on our linux s390x / ppc64(le) ) .
> >
> >> If the change to enable lto by default is proposed, what would be the
> >> recommended strategy for development?
> >>
> > Probably  we should a)   do not enable it by default but just make sure
> it can be enabled easily and works  for  the minimal-vm
> That would be welcome. I have high hopes to LTO the VM some time by
> default, and the tendency observed is that the compiler time overhead
> for GCC becomes smaller. At the same time there is no reason why vendors
> that invested in testing and can absorb the build time hit could provide
> binaries with LTO built VMs by passing an additional option flag.
> >   or  b)  take it easy to disable it for local development.
> >
> > Best regards, Matthias
> >
> >
> >
> >> 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?).
> >>
>
>