building OpenJDK 11 with link time optimizations?

[Magnus Ihse Bursie]

On 2021-01-27 11:42, Matthias Klose wrote:
> On 1/27/21 10:35 AM, Magnus Ihse Bursie wrote:
>> On 2021-01-26 17:08, Matthias Klose wrote:
>>> Several Linux distros now build with link time optimizations (-flto=auto) by
>>> default.  It looks like 15 and newer versions can be built with -flto. I haven't
>>> yet checked test results for LTO/non-LTO builds. I also only tried building with
>>> GCC 10.
>>>
>>> 11 still fails with
>>> /usr/bin/ld: /tmp/libjvm.so.xGmnnW.ltrans45.ltrans.o: in function
>>> `G1CMOopClosure::do_oop(oopDesc**)':
>>> /<<BUILDDIR>>/openjdk-lts-11.0.9.1+1/make/hotspot/./src/hotspot/share/gc/g1/g1OopClosures.hpp:176:
>>>
>>> undefined reference to `void G1CMOopClosure::do_oop_work<oopDesc*>(oopDesc**)'
>>> [...]
>>>
>>> However this might be just the first build failure.
>> Is this when building with --enable-jvm-feature-link-time-opt on linux-x64?
> No, just passing -flto=auto in CFLAGS, CXXFLAGS, and LDFLAGS, and configuring
> with --with-extra-*flags
> here's a build log for such kind of build:
> https://launchpad.net/ubuntu/+archive/test-rebuild-20201216-hirsute-lto/+build/20573901
>
>> When I try that (with gcc-10 on Ubuntu) on the mainline, I get:
> [...]
>
> these seem to be warnings "only". A 16+33 build configured with
> --enable-jvm-feature-link-time-opt also succeeds for me.
>
> at least for GCC, the LTO streaming format doesn't collect warning options, so
> maybe these should be passed to the linker explicitly when configuring with the
> lto option.
So these are warnings that we disable to the compiler, but when running 
with lto, it is triggered first when linking, instead of when compiling? 
I see.

>
>> I don't think anyone used LTO seriously since the old Oracle arm-32 port. The
>> major blocker is the added linking time spent for hotspot, I think. Patches to
>> fix this is more than welcome, though!
> currently --enable-jvm-feature-link-time-opt only builds with -flto, and
> therefore sequentially. An obvious thing to do is either to build with
> -flto=auto or -flto=jobserver to use all available cores for the link.

Well, that did drastically improve the link speed. On my machine it went 
from ~12 minutes with the "old" LTO, to 3 min 20 s with -flto=jobserver. 
This is still quite a lot more than without LTO (which is < 2 minutes on 
the same machine), but very much bearable.

We should definitely add =jobserver to the -flto option. We should 
probably also clean up some of the other dumb stuff that link-time-opt 
does, since that's just backwards compatibility with the old (and now 
removed) behavior for Oracle arm-32.

However, the resulting libjvm.so was several times larger, which 
suprised me quite a bit. I assumed (perhaps naively) that using LTO 
would result in a more compact end binary. (With LTO: 59 MB, without: 22 
MB).

>
> I also saw in the link:
> /usr/bin/nm: bytecodeHistogram.o: no symbols
> /usr/bin/nm: c1_Defs.o: no symbols
> /usr/bin/nm: instanceOop.o: no symbols
> /usr/bin/nm: oopsHierarchy.o: no symbols
> /usr/bin/nm: operator_new.o: no symbols
> /usr/bin/nm: register.o: no symbols
> /usr/bin/nm: vm_version_linux_x86.o: no symbols
> /usr/bin/nm: weakProcessorPhases.o: no symbols
> Creating mapfile
> Linking libjvm.so
>
> if something relies on the object code, then maybe use -ffat-lto-objects,
> although this will slow down the build of the object files.
My initial guess would be that you are building without certain 
components, which make these files end up empty. But the names sound 
very much general, so that is a bit suspicious...

/Magnus

>
> Matthias