RFR: JDK-8217723 Switch ld from bfd to gold on gcc toolchain
Erik Joelsson
erik.joelsson at oracle.com
Thu Jan 24 17:43:39 UTC 2019
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
>
More information about the build-dev
mailing list