ev@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
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,
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
erformance 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 )
20 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 s
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
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
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
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
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
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
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).
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
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
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.
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
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
17 matches
Mail list logo
