RFR: JDK-8217723 Switch ld from bfd to gold on gcc toolchain

[Magnus Ihse Bursie]

On 2019-01-24 18:43, Erik Joelsson wrote:
>
> 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.
Ok. I'll retract my RFR for now, and come back with a way to set this 
conditionally using configure flags.

/Magnus
>
> /Magnus
>>
>>>
>>> Thanks,
>>> Florian
>>