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.baes...@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.simo...@gmail.com> > *Sent:* Mittwoch, 15. Januar 2020 14:40 > *To:* Aleksei Voitylov <aleksei.voity...@bell-sw.com> > *Cc:* Baesken, Matthias <matthias.baes...@sap.com>; Magnus Ihse Bursie < > magnus.ihse.bur...@oracle.com>; serviceability-dev@openjdk.java.net; > build-dev <build-...@openjdk.java.net>; hotspot-...@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.voity...@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?). > >> > >
