On 2019-01-24 06:04, Magnus Ihse Bursie wrote:
On 2019-01-24 14:45, Florian Weimer wrote:
* Magnus Ihse Bursie:

The default binutils linker used by gcc, the bfd linker, is slow. The
new replacement, gold, has been distributed alongside gcc for several
years now, and is a well mature, and much faster, replacement.
The gold linker is an optional component of binutils, not available in
all builds.  For example, binutils in Red Hat Enterprise Linux 7.6 does
not include gold on the ppc64le architecture.

The gold linker also supports a different set of features compared to
BFD ld, which may or may not be what you want.  But I think OpenJDK does
not use many tricky ELF features, so the differences probably do not
matter.

Is it possible to add -fuse-ld=gold to LDFLAGS externally, outside the
build system, so that the build system can use the gold linker if people
prefer it over BFD ld?

Or you could configure your binutils with --enable-gold=default, so that
it defaults to ld.gold, again not requiring any OpenJDK changes.
One of the driving forces behind this bug is the speed increase in gold by itself. You are correct that to achieve this, a solution outside the build system can be used.

However, the other driving force is the ability to enable incremental linking. The build system must know if we use gold, so that it knows that those command line options are available. So to resort to the solution of changing the environment would not enable that second part.

But I'm leaning more towards just enabling gold on x86_64 -- for other platforms, we might as well keep the good ol' bfd linker. Does that sound like a good solution to you?

I have been looking at this before (probably a couple of years ago now) and my take then was that this should be handled with a configure flag and be opt in (that jib would set for us). The default really should be to accept what the toolchain/admin/distribution has as default. If --enable-gold is given, configure needs to check for gold availability. I had to explicitly enable it in the devkit builds, so it's definitely not always present.

We could also just make sure our internal devkit uses gold by default, and leave explicit setting of this to simply adding a linker arg with configure.

By using an explicit configure argument to enable it, configure knows about it and we can enable incremental linking using that information. Incremental linking must be opt in though. We could also skip the --enable-gold flag and just do the checks if --enable-incremental-linking is set.

Last I experimented with it, incremental did not have a positive effect on the time to link hotspot, but gold did.

/Magnus


Thanks,
Florian

Reply via email to