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:
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
(Matthi
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 probabl
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
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 / 16
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.
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
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, Mat
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 / gcc
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
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
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 informa
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 defau
13 matches
Mail list logo