Re: RFR: 8236714: enable link-time section-gc for linux to remove unused code

[David Holmes]

Hi Matthias,

I have reservations about turning this on by default and with no way to 
control it. This seems like it should be something you have to opt-in to 
initially while we gain some experience with it and ensure there are no 
unexpected side-effects. After that it could be enabled by default.


David

On 15/01/2020 12:07 am, Baesken, Matthias wrote:

Hello,  the following change enables the  link-time section-gc for linux .

gcc and ld support enabling "garbage collection" of unused input sections.
This can be used to eliminate unused coding from native libraries (especially 
when already compiling the objects with compiler flags -ffunction-sections 
-fdata-sections .
See for details the --gc-sections and --print-gc-sections parts of the ld 
documentation :

https://linux.die.net/man/1/ld


We had this enabled already  for  linux s390x ,  with 
https://bugs.openjdk.java.net/browse/JDK-8234525
8234525: enable link-time section-gc for linux s390x to remove unused code .

This  time we enable it too for  the other linux platforms .

For the other platforms I do not enable it for JVM, just for the JDK libs.  The 
reason is that the serviceability agent  (not supported on linux s390x )is 
not  (yet) ready for the optimization .
Below you see the results , for some libraries  a significant  size reduction 
can be achieved .


Results from linux x86_64 product builds :

without / with ltgc

320K / 300K/images/jdk/lib/libsunec.so   <-
36K  / 36K /images/jdk/lib/libdt_socket.so
280K / 276K   /images/jdk/lib/libjdwp.so
23M  / 23M/images/jdk/lib/server/libjvm.so< not set for libjvm.so 
for x86_64
16K  / 16K/images/jdk/lib/server/libjsig.so
72K  / 72M/images/jdk/lib/libverify.so
84K  / 84M   /images/jdk/lib/libjli.so
16K  / 16K/images/jdk/lib/libjsig.so
196K / 196K   /images/jdk/lib/libjava.so
44K  / 44K/images/jdk/lib/libzip.so
144K / 136K   /images/jdk/lib/libjimage.so
112K / 112K   /images/jdk/lib/libnet.so
100K / 100K   /images/jdk/lib/libnio.so
36K  / 36K/images/jdk/lib/libsctp.so
576K / 556K   /images/jdk/lib/libmlib_image.so
752K / 752K   /images/jdk/lib/libawt.so
260K / 252K   /images/jdk/lib/libjavajpeg.so
784K / 784K   /images/jdk/lib/libfreetype.so
368K / 236K /images/jdk/lib/libsplashscreen.so   <-
88K / 88K/images/jdk/lib/libjsound.so
472K / 468K/images/jdk/lib/libawt_xawt.so
564K / 404K   /images/jdk/lib/liblcms.so <--
48K / 48K/images/jdk/lib/libawt_headless.so
12K / 12K/images/jdk/lib/libjawt.so
1.5M / 900K   /images/jdk/lib/libfontmanager.so  <--
12K / 12K/images/jdk/lib/libjaas.so
92K / 92K/images/jdk/lib/libj2pkcs11.so
16K / 16K/images/jdk/lib/libattach.so
8.0K / 8.0K   /images/jdk/lib/librmi.so
56K / 56K/images/jdk/lib/libinstrument.so
16K / 16K/images/jdk/lib/libprefs.so
52K / 52K/images/jdk/lib/libj2gss.so
12K / 12K/images/jdk/lib/libmanagement_agent.so
36K / 32K/images/jdk/lib/libmanagement.so
16K / 16K/images/jdk/lib/libextnet.so
20K / 20K/images/jdk/lib/libj2pcsc.so
40K / 40K/images/jdk/lib/libmanagement_ext.so
60K / 60K/images/jdk/lib/libsaproc.so


Bug/webrev :

https://bugs.openjdk.java.net/browse/JDK-8236714

http://cr.openjdk.java.net/~mbaesken/webrevs/8236714.2/


Thanks, Matthias

Re: JDK 15 RFR of JDK-8235959: Update --release 14 symbol information up to JDK 14 b31

[Jonathan Gibbons]

Looks good to me.

-- Jon

On 1/15/20 1:14 PM, Joe Darcy wrote:

Hello,

Since JDK 14 build 27,

    JDK-8236695 "java.lang.Record should be declared with an explicit 
constructor" and

    JDK-8234049 "Implementation of Memory Access API (Incubator)"

changed the API in JDK 14. The symbol information for 14 in JDK 15 
should be updated accordingly to bring it current with JDK 14 b31:


    http://cr.openjdk.java.net/~darcy/8235959.0/

Thanks,

-Joe

JDK 15 RFR of JDK-8235959: Update --release 14 symbol information up to JDK 14 b31

[Joe Darcy]

Hello,

Since JDK 14 build 27,

    JDK-8236695 "java.lang.Record should be declared with an explicit 
constructor" and

    JDK-8234049 "Implementation of Memory Access API (Incubator)"

changed the API in JDK 14. The symbol information for 14 in JDK 15 
should be updated accordingly to bring it current with JDK 14 b31:


    http://cr.openjdk.java.net/~darcy/8235959.0/

Thanks,

-Joe

RE: RFR: 8236714: enable link-time section-gc for linux to remove unused code

[Baesken, Matthias]

Hi Erik, I did not notice  slowdowns in our night makes .

Looking at a specific  test machine  I use  (x86_64,  build JOBS hardwired  set 
 to 12 )   I  get around  6 minutes build time  with and without the feature .

( but you have to take into account  that  the  link-time section-gc   on  
x86_64in my patch is only enabled  for the smaller JDK libs and not 
libjvm.so  )  

Best regards, Matthias


> 
> Given the discussion regarding lto on hotspot and the extreme increased
> build time, have you noticed any difference in build times with this patch?
> 
> /Erik
> 

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

[Baesken, Matthias]

Hello,here is another  comparison for the larger  JDK  shared libs,  this 
time  with the sizes  of   build with linktime-gc (--gc-sections)   added .
( just for the larger libs )
(  I had not  enabled  linktime-gc  for libjvm   in our  test build , just for 
the JDK libs . )

Linuxx86_64 / gcc7

normal / with -flto / with linktime-gc (--gc-sections)
---
752K / 760K / 752K   ./lib/libawt.so<-- this one 
gets a bit larger but only with flto
472K / 456K / 468K   ./lib/libawt_xawt.so   <-- small gain
1.5M / 824K / 900K   ./lib/libfontmanager.so <-- HUGE gain 
, not as good with ltgc but still good
784K / 792K / 784K  ./lib/libfreetype.so<-- this one 
gets a bit larger  (but not with ltgc)
260K / 244K / 252K   ./lib/libjavajpeg.so <- small gain
196K / 188K / 196K   ./lib/libjava.so
280K / 256K / 276K   ./lib/libjdwp.so <- small gain
144K / 140K / 136K   ./lib/libjimage.so
564K / 420K / 404K   ./lib/liblcms.so <- large gain 
,  even better with  ltgc
576K / 496K / 556K   ./lib/libmlib_image.so   <- large gain 
with flto , small one with ltgc
368K / 212K / 236K   ./lib/libsplashscreen.so <- large gain
320K / 296K / 300K   ./lib/libsunec.so<- medium gain
23M / 17M   /  --not enabled---./lib/server/libjvm.so
<- big gain maybe because it is C++ ?


So   one can see,  that   flto   is usually  a bit better  than link-time-gc  
when it comes to  improving lib sizes, but not always .
However  linktime-gc   seems to be faster when comparing build times   , I did 
not really notice much  build  time slowdown because of it .
( we have it enabled  for linux  s390x  for some time in OpenJDK ).
The  linktime-gc   also offers a nice feature  to print out the eliminated 
stuff ,   that can be used  to remove  unused code cross-platform .
e.g.  the removed symbols  from   
https://bugs.openjdk.java.net/browse/JDK-8234629has been found this way .


Best regards, Matthias



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 mailto: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  

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

[Baesken, Matthias]

Hello, I  used  the  "normal"  linker so I think  what 

https://stackoverflow.com/questions/31688069/requirements-to-use-flto

says is true ,  one can use  also the "normal"  linker .
Haven't checked  for any performance  (or other) improvements   when using gold 
 instead .  



Best regards, Matthias


> On 2020-01-15 07:29, Volker Simonis wrote:
> > 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.
> 
> The default linker is system configured so it depends on your Linux
> distro. The devkits generated by the current devkit makefiles configures
> gold as default.
> 
> /Erik
> 

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

[Erik Joelsson]

On 2020-01-15 07:29, Volker Simonis wrote:

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.


The default linker is system configured so it depends on your Linux 
distro. The devkits generated by the current devkit makefiles configures 
gold as default.


/Erik

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

[Volker Simonis]

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  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 
> *Sent:* Mittwoch, 15. Januar 2020 14:40
> *To:* Aleksei Voitylov 
> *Cc:* Baesken, Matthias ; Magnus Ihse Bursie <
> magnus.ihse.bur...@oracle.com>; serviceability-...@openjdk.java.net;
> build-dev ; 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  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)  

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

[Baesken, Matthias]

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.sowe 
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 
Sent: Mittwoch, 15. Januar 2020 14:40
To: Aleksei Voitylov 
Cc: Baesken, Matthias ; Magnus Ihse Bursie 
; serviceability-...@openjdk.java.net; build-dev 
; 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 
mailto: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 

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

[Aleksei Voitylov]

Volker,

not a full answer, but here is some static size stats:

Server     x86_64  AArch64
regular     23M       20M
lto            17M       14M

Minimal   x86_64  AArch64
regular 4.9M  3.9M
lto    4.7M  3.6M

-Aleksei

On 15/01/2020 16:40, Volker Simonis wrote:
> 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  > 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?).
> >>
>

Re: RFR: 8236714: enable link-time section-gc for linux to remove unused code

[Erik Joelsson]

Given the discussion regarding lto on hotspot and the extreme increased 
build time, have you noticed any difference in build times with this patch?


/Erik

On 2020-01-15 00:27, Baesken, Matthias wrote:

Hi Erik, thanks for the review and for forwarding ,  you are correct  
corelibs-dev is probably  interested in this as well .

Best regards, Matthias



(adding core-libs-dev)

Change looks good to me, but would like input from at least someone in
core-libs.

/Erik

On 2020-01-14 06:07, Baesken, Matthias wrote:

Hello,  the following change enables the  link-time section-gc for linux .

gcc and ld support enabling "garbage collection" of unused input sections.
This can be used to eliminate unused coding from native libraries

(especially when already compiling the objects with compiler flags -ffunction-
sections -fdata-sections .

See for details the --gc-sections and --print-gc-sections parts of the ld

documentation :

https://linux.die.net/man/1/ld


We had this enabled already  for  linux s390x ,  with

https://bugs.openjdk.java.net/browse/JDK-8234525

8234525: enable link-time section-gc for linux s390x to remove unused code

.

This  time we enable it too for  the other linux platforms .

For the other platforms I do not enable it for JVM, just for the JDK libs.  The

reason is that the serviceability agent  (not supported on linux s390x )is 
not
(yet) ready for the optimization .

Below you see the results , for some libraries  a significant  size reduction

can be achieved .


Results from linux x86_64 product builds :

without / with ltgc

320K / 300K/images/jdk/lib/libsunec.so   <-
36K  / 36K /images/jdk/lib/libdt_socket.so
280K / 276K   /images/jdk/lib/libjdwp.so
23M  / 23M/images/jdk/lib/server/libjvm.so< not set for libjvm.so

for x86_64

16K  / 16K/images/jdk/lib/server/libjsig.so
72K  / 72M/images/jdk/lib/libverify.so
84K  / 84M   /images/jdk/lib/libjli.so
16K  / 16K/images/jdk/lib/libjsig.so
196K / 196K   /images/jdk/lib/libjava.so
44K  / 44K/images/jdk/lib/libzip.so
144K / 136K   /images/jdk/lib/libjimage.so
112K / 112K   /images/jdk/lib/libnet.so
100K / 100K   /images/jdk/lib/libnio.so
36K  / 36K/images/jdk/lib/libsctp.so
576K / 556K   /images/jdk/lib/libmlib_image.so
752K / 752K   /images/jdk/lib/libawt.so
260K / 252K   /images/jdk/lib/libjavajpeg.so
784K / 784K   /images/jdk/lib/libfreetype.so
368K / 236K /images/jdk/lib/libsplashscreen.so   <-
88K / 88K/images/jdk/lib/libjsound.so
472K / 468K/images/jdk/lib/libawt_xawt.so
564K / 404K   /images/jdk/lib/liblcms.so <--
48K / 48K/images/jdk/lib/libawt_headless.so
12K / 12K/images/jdk/lib/libjawt.so
1.5M / 900K   /images/jdk/lib/libfontmanager.so  <--
12K / 12K/images/jdk/lib/libjaas.so
92K / 92K/images/jdk/lib/libj2pkcs11.so
16K / 16K/images/jdk/lib/libattach.so
8.0K / 8.0K   /images/jdk/lib/librmi.so
56K / 56K/images/jdk/lib/libinstrument.so
16K / 16K/images/jdk/lib/libprefs.so
52K / 52K/images/jdk/lib/libj2gss.so
12K / 12K/images/jdk/lib/libmanagement_agent.so
36K / 32K/images/jdk/lib/libmanagement.so
16K / 16K/images/jdk/lib/libextnet.so
20K / 20K/images/jdk/lib/libj2pcsc.so
40K / 40K/images/jdk/lib/libmanagement_ext.so
60K / 60K/images/jdk/lib/libsaproc.so


Bug/webrev :

https://bugs.openjdk.java.net/browse/JDK-8236714

http://cr.openjdk.java.net/~mbaesken/webrevs/8236714.2/


Thanks, Matthias

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

[Volker Simonis]

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

RE: RFR: 8236714: enable link-time section-gc for linux to remove unused code

[Baesken, Matthias]

Hi Erik, thanks for the review and for forwarding ,  you are correct  
corelibs-dev is probably  interested in this as well .

Best regards, Matthias


> (adding core-libs-dev)
> 
> Change looks good to me, but would like input from at least someone in
> core-libs.
> 
> /Erik
> 
> On 2020-01-14 06:07, Baesken, Matthias wrote:
> > Hello,  the following change enables the  link-time section-gc for linux .
> >
> > gcc and ld support enabling "garbage collection" of unused input sections.
> > This can be used to eliminate unused coding from native libraries
> (especially when already compiling the objects with compiler flags -ffunction-
> sections -fdata-sections .
> > See for details the --gc-sections and --print-gc-sections parts of the ld
> documentation :
> >
> > https://linux.die.net/man/1/ld
> >
> >
> > We had this enabled already  for  linux s390x ,  with
> https://bugs.openjdk.java.net/browse/JDK-8234525
> > 8234525: enable link-time section-gc for linux s390x to remove unused code
> .
> >
> > This  time we enable it too for  the other linux platforms .
> >
> > For the other platforms I do not enable it for JVM, just for the JDK libs.  
> > The
> reason is that the serviceability agent  (not supported on linux s390x )
> is not
> (yet) ready for the optimization .
> > Below you see the results , for some libraries  a significant  size 
> > reduction
> can be achieved .
> >
> >
> > Results from linux x86_64 product builds :
> >
> > without / with ltgc
> >
> > 320K / 300K/images/jdk/lib/libsunec.so   <-
> > 36K  / 36K /images/jdk/lib/libdt_socket.so
> > 280K / 276K   /images/jdk/lib/libjdwp.so
> > 23M  / 23M/images/jdk/lib/server/libjvm.so< not set for 
> > libjvm.so
> for x86_64
> > 16K  / 16K/images/jdk/lib/server/libjsig.so
> > 72K  / 72M/images/jdk/lib/libverify.so
> > 84K  / 84M   /images/jdk/lib/libjli.so
> > 16K  / 16K/images/jdk/lib/libjsig.so
> > 196K / 196K   /images/jdk/lib/libjava.so
> > 44K  / 44K/images/jdk/lib/libzip.so
> > 144K / 136K   /images/jdk/lib/libjimage.so
> > 112K / 112K   /images/jdk/lib/libnet.so
> > 100K / 100K   /images/jdk/lib/libnio.so
> > 36K  / 36K/images/jdk/lib/libsctp.so
> > 576K / 556K   /images/jdk/lib/libmlib_image.so
> > 752K / 752K   /images/jdk/lib/libawt.so
> > 260K / 252K   /images/jdk/lib/libjavajpeg.so
> > 784K / 784K   /images/jdk/lib/libfreetype.so
> > 368K / 236K /images/jdk/lib/libsplashscreen.so   <-
> > 88K / 88K/images/jdk/lib/libjsound.so
> > 472K / 468K/images/jdk/lib/libawt_xawt.so
> > 564K / 404K   /images/jdk/lib/liblcms.so <--
> > 48K / 48K/images/jdk/lib/libawt_headless.so
> > 12K / 12K/images/jdk/lib/libjawt.so
> > 1.5M / 900K   /images/jdk/lib/libfontmanager.so  
> > <--
> > 12K / 12K/images/jdk/lib/libjaas.so
> > 92K / 92K/images/jdk/lib/libj2pkcs11.so
> > 16K / 16K/images/jdk/lib/libattach.so
> > 8.0K / 8.0K   /images/jdk/lib/librmi.so
> > 56K / 56K/images/jdk/lib/libinstrument.so
> > 16K / 16K/images/jdk/lib/libprefs.so
> > 52K / 52K/images/jdk/lib/libj2gss.so
> > 12K / 12K/images/jdk/lib/libmanagement_agent.so
> > 36K / 32K/images/jdk/lib/libmanagement.so
> > 16K / 16K/images/jdk/lib/libextnet.so
> > 20K / 20K/images/jdk/lib/libj2pcsc.so
> > 40K / 40K/images/jdk/lib/libmanagement_ext.so
> > 60K / 60K/images/jdk/lib/libsaproc.so
> >
> >
> > Bug/webrev :
> >
> > https://bugs.openjdk.java.net/browse/JDK-8236714
> >
> > http://cr.openjdk.java.net/~mbaesken/webrevs/8236714.2/
> >
> >
> > Thanks, Matthias