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

[Baesken, Matthias]

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

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-dev@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 

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: 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: serviceability agent : problems when using gcc LTO (link time optimization)

[Aleksei Voitylov]

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: serviceability agent : problems when using gcc LTO (link time optimization)

[Baesken, Matthias]

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

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

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

[Baesken, Matthias]

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

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 
details https://gcc.gnu.org/onlinedocs/gccint/LTO-Overview.html  and  
http://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

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

[Magnus Ihse Bursie]

On 2020-01-10 11:01, Baesken, Matthias wrote:

Hello,   I recently looked into  the  gcc  lto  optimization mode (see for some 
details https://gcc.gnu.org/onlinedocs/gccint/LTO-Overview.html  and  
http://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

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

[Baesken, Matthias]

Hello, thanks for  the info -  seems that for the minimal  VM ,  lto is fine 
but  currently not for the other (server/...) VM builds .

Btw.   I noticed similar issues with the SA  when using  link-time-gc . Looks 
like this eliminates the vtable info too that tha SA-coding  ( LinuxVtblAccess 
class ?)  wants to look into .


Best regards, Matthias


> cds is also disabled for minimalVM so testing of cds with LTO probably
> has not been done. There are a number of features that minimalVM
> excludes such as jvmti, cds and SA (which I think falls under
> "services"), and there was very little testing done with these features
> individually disabled. They would all at least build (if any one was
> disabled) and I think heartbeat testing was done, but probably no more
> than that. Also various combinations were not tested, other than the one
> combination that minimalVM used. Search for NON_MINIMAL_FEATURES in
> hotspot.m4 to see which features are disabled for minimalVM.
> 
> Chris
> 
> On 1/11/20 5:38 AM, Volker Simonis wrote:
> > SA pretends to know the exact types of objects in the JVM and for
> > polymorphic objects it wants to read their vtable from the shared library.
> > If LTO de-virtulizes methods and thus changes polymorphic to
> > non-polymorphic types, this won't work. But if LTO can de-virtulizes a
> > type, maybe you can do that manually (and update the corresponding
> > representation in the SA), because it doesn't seem to be needed.
> >
> > Notice that other places in the VM may also rely on this. E.g. CDS stores
> > Metadata objects in the CDS archive and restores their vtable pointers
> when
> > they are loaded. On the other hand, if the CDS tests have passed, this
> > doesn't seem to be a problem.
> >
> > Baesken, Matthias  schrieb am Fr., 10. Jan.
> 2020,
> > 11:03:
> >
> >> Hello,   I recently looked into  the  gcc  lto  optimization mode (see for
> >> some details https://gcc.gnu.org/onlinedocs/gccint/LTO-Overview.html
> >> and
> >> http://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.findDyna
> micTypeForAddress(BasicTypeDataBase.java:279)
> >>   at
> >>
> jdk.hotspot.agent/sun.jvm.hotspot.runtime.VirtualBaseConstructor.instanti
> ateWrapperFor(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.getClassLoad
> erKlass(SystemDictionary.java:96)
> >>   at
> >>
> jdk.hotspot.agent/sun.jvm.hotspot.tools.ClassLoaderStats.printClassLoaderS
> tatistics(ClassLoaderStats.java:93)
> >>   at
> >>
> jdk.hotspot.agent/sun.jvm.hotspot.tools.ClassLoaderStats.run(ClassLoaderS
> tats.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:3
> 21)
> >>   at
> >>
> jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.main(SALauncher.java:406)
> >>
> >> Has anyone experimented with LTO optimization ?
> >>
> >> And to the  

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

[Chris Plummer]

cds is also disabled for minimalVM so testing of cds with LTO probably 
has not been done. There are a number of features that minimalVM 
excludes such as jvmti, cds and SA (which I think falls under 
"services"), and there was very little testing done with these features 
individually disabled. They would all at least build (if any one was 
disabled) and I think heartbeat testing was done, but probably no more 
than that. Also various combinations were not tested, other than the one 
combination that minimalVM used. Search for NON_MINIMAL_FEATURES in 
hotspot.m4 to see which features are disabled for minimalVM.


Chris

On 1/11/20 5:38 AM, Volker Simonis wrote:

SA pretends to know the exact types of objects in the JVM and for
polymorphic objects it wants to read their vtable from the shared library.
If LTO de-virtulizes methods and thus changes polymorphic to
non-polymorphic types, this won't work. But if LTO can de-virtulizes a
type, maybe you can do that manually (and update the corresponding
representation in the SA), because it doesn't seem to be needed.

Notice that other places in the VM may also rely on this. E.g. CDS stores
Metadata objects in the CDS archive and restores their vtable pointers when
they are loaded. On the other hand, if the CDS tests have passed, this
doesn't seem to be a problem.

Baesken, Matthias  schrieb am Fr., 10. Jan. 2020,
11:03:


Hello,   I recently looked into  the  gcc  lto  optimization mode (see for
some details https://gcc.gnu.org/onlinedocs/gccint/LTO-Overview.html
and
http://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 ?

And to the  serviceability   agent experts -  any idea  how to make the
jdk.hotspot.agent   more independent from  optimization settings ?


Best regards, Matthias

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

[Volker Simonis]

SA pretends to know the exact types of objects in the JVM and for
polymorphic objects it wants to read their vtable from the shared library.
If LTO de-virtulizes methods and thus changes polymorphic to
non-polymorphic types, this won't work. But if LTO can de-virtulizes a
type, maybe you can do that manually (and update the corresponding
representation in the SA), because it doesn't seem to be needed.

Notice that other places in the VM may also rely on this. E.g. CDS stores
Metadata objects in the CDS archive and restores their vtable pointers when
they are loaded. On the other hand, if the CDS tests have passed, this
doesn't seem to be a problem.

Baesken, Matthias  schrieb am Fr., 10. Jan. 2020,
11:03:

> Hello,   I recently looked into  the  gcc  lto  optimization mode (see for
> some details https://gcc.gnu.org/onlinedocs/gccint/LTO-Overview.html
> and
> http://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 ?
>
> And to the  serviceability   agent experts -  any idea  how to make the
> jdk.hotspot.agent   more independent from  optimization settings ?
>
>
> Best regards, Matthias
>

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

[Chris Plummer]

  
  
Hi Matthias,
  
  There is already support for lto in the configure script and
  makefiles. It was added long ago for minimalVM support. It was
  likely only ever used/tested with minimalVM, which does not
  support SA, thus the issue you are referring to did not show up.
  To enable minimalVM configure with:
  
    --with-jvm-features=minimal
  
  I think this will also enable lto. If not, or if you want it
  without minimalVM, then configure with:
  
    --with-jvm-features=link-time-opt
  
  Sorry, I can't offer any help on the SA polymorphic metadata
  issue. Hopefully someone else on this alias has some experience in
  that area.
  
  thanks,
  
  Chris
  
  On 1/10/20 2:01 AM, Baesken, Matthias wrote:


  
  
  
  
Hello,   I recently
looked into  the  gcc  lto  optimization mode (see for some
details
  https://gcc.gnu.org/onlinedocs/gccint/LTO-Overview.html
   and 
  http://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 ?
 
And to the 
serviceability   agent experts -  any idea  how to make the 
jdk.hotspot.agent   more independent from  optimization
settings ?
 
 
Best regards, Matthias