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

2020-01-15 Thread 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:

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

2020-01-15 Thread 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 (Matthi

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

2020-01-15 Thread 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 probabl

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

2020-01-15 Thread 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

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

2020-01-15 Thread 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 / 16

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

2020-01-15 Thread 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.

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

2020-01-15 Thread 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

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

2020-01-15 Thread 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, Mat

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

2020-01-15 Thread 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 / gcc

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

2020-01-15 Thread 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

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

2020-01-15 Thread 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

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

2020-01-15 Thread 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 informa

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

2020-01-15 Thread 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 defau