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

[Martin Buchholz]

I agree with Andrew Hughes.

On Wed, Jan 30, 2019 at 9:27 AM Andrew Hughes  wrote:

>
> I'm aware of the benefits of using gold, and also occasional issues with
> it, but that's not the debate here. It's already perfectly possible to
> build with gold by using --with-ldflags="-fuse-ld=gold", as I've been
> doing for quite a while, or setting the system ld to be gold. What you're
> asking is that this option should be forced onto every build.
>
> My experience suggests that compiler flags should be kept to a minimum,
> and tested for where possible. One of the great benefits of OpenJDK finally
> having a configure system is that we can now check whether flags work
> before enabling them (e.g. my own changes to support GCC 6). What seems
> to work wonderfully on one's local machine often breaks in a variety
> of different
> ways when exposed to the variety of build environments out there.
>
> I guess you could add this with an --enable-gold option (on by default) and
> testing that the flag works in configure. I do have to wonder though if it
> is worth the effort and possible risks.
>

It's not!

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

[Andrew Hughes]

On Thu, 24 Jan 2019 at 13:12, Magnus Ihse Bursie
 wrote:
>
> 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.
>
> This issue is about replacing ld.bfd with ld.gold for our gcc toolchain.
> In general, this cuts linking times by half or more.
>
> As a future improvement, gold also allows for incremental linking.
> Turning on that is outside the scope of this issue.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8217723
> Patch inline:
> diff --git a/make/autoconf/flags-ldflags.m4 b/make/autoconf/flags-ldflags.m4
> --- a/make/autoconf/flags-ldflags.m4
> +++ b/make/autoconf/flags-ldflags.m4
> @@ -70,7 +70,7 @@
>   fi
>
>   # Add -z defs, to forbid undefined symbols in object files.
> -BASIC_LDFLAGS="$BASIC_LDFLAGS -Wl,-z,defs"
> +BASIC_LDFLAGS="$BASIC_LDFLAGS -Wl,-z,defs -fuse-ld=gold"
>
>   BASIC_LDFLAGS_JVM_ONLY="-Wl,-O1 -Wl,-z,relro"
>
> /Magnus

I'm aware of the benefits of using gold, and also occasional issues with
it, but that's not the debate here. It's already perfectly possible to
build with gold by using --with-ldflags="-fuse-ld=gold", as I've been
doing for quite a while, or setting the system ld to be gold. What you're
asking is that this option should be forced onto every build.

My experience suggests that compiler flags should be kept to a minimum,
and tested for where possible. One of the great benefits of OpenJDK finally
having a configure system is that we can now check whether flags work
before enabling them (e.g. my own changes to support GCC 6). What seems
to work wonderfully on one's local machine often breaks in a variety
of different
ways when exposed to the variety of build environments out there.

I guess you could add this with an --enable-gold option (on by default) and
testing that the flag works in configure. I do have to wonder though if it
is worth the effort and possible risks.

Thanks,
-- 
Andrew :)

Senior Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Web Site: http://fuseyism.com
Twitter: https://twitter.com/gnu_andrew_java
PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222

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

[Volker Simonis]

When I last tried gold a few years ago on ppc64 (and ia64, just for
the reference :) it didn't work because it didn't support all the
required relocations.

However, a current experiment with "GNU gold (GNU Binutils for Ubuntu
2.26.1) 1.11" on Ubuntu 16.04/ppc64le succeeded and improved the link
time of libjvm.so (with full debug info) from ~15 to ~5 seconds which
is pretty nice.

I'd still appreciate if the usage of gold would be guarded by a configure check.

Thank you and best regards,
Volker

On Sat, Jan 26, 2019 at 6:00 PM Martin Buchholz  wrote:
>
> Another, more productionized, version of my benchmark:
>
> processors=12
> g++ (Debian 7.3.0-5) 7.3.0
> --- -fuse-ld=bfd ---
> 6.559 user 1.180 system 7.740 total
> --- -fuse-ld=gold ---
> 4.575 user 0.600 system 5.176 total
> --- -fuse-ld=gold -Wl,-threads ---
> 9.355 user 5.062 system 4.289 total
> --- -fuse-ld=lld ---
> 2.700 user 1.058 system 1.157 total
> --- -fuse-ld=lld -Wl,-threads ---
> 2.572 user 1.128 system 1.107 total
>
>
> #!/bin/bash
> set -eu
> echo processors=$(nproc)
> read -a CMDLINE < $(find . -name BUILD_LIBJVM_link.cmdline -print)
>
> readonly DRIVER="${CMDLINE[0]}"
> "$DRIVER" --version | head -1
>
> benchmark() {
>   echo --- "$@" ---
>   local -r TIMEFORMAT="%U user %S system %R total"
>   time "$DRIVER" "$@" "${CMDLINE[@]:1}"
> }
>
> benchmark -fuse-ld=bfd
> benchmark -fuse-ld=gold
> benchmark -fuse-ld=gold -Wl,-threads
> benchmark -fuse-ld=lld
> benchmark -fuse-ld=lld -Wl,-threads

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

[Martin Buchholz]

Another, more productionized, version of my benchmark:

processors=12
g++ (Debian 7.3.0-5) 7.3.0
--- -fuse-ld=bfd ---
6.559 user 1.180 system 7.740 total
--- -fuse-ld=gold ---
4.575 user 0.600 system 5.176 total
--- -fuse-ld=gold -Wl,-threads ---
9.355 user 5.062 system 4.289 total
--- -fuse-ld=lld ---
2.700 user 1.058 system 1.157 total
--- -fuse-ld=lld -Wl,-threads ---
2.572 user 1.128 system 1.107 total


#!/bin/bash
set -eu
echo processors=$(nproc)
read -a CMDLINE < $(find . -name BUILD_LIBJVM_link.cmdline -print)

readonly DRIVER="${CMDLINE[0]}"
"$DRIVER" --version | head -1

benchmark() {
  echo --- "$@" ---
  local -r TIMEFORMAT="%U user %S system %R total"
  time "$DRIVER" "$@" "${CMDLINE[@]:1}"
}

benchmark -fuse-ld=bfd
benchmark -fuse-ld=gold
benchmark -fuse-ld=gold -Wl,-threads
benchmark -fuse-ld=lld
benchmark -fuse-ld=lld -Wl,-threads

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

[Andrew Haley]

On 1/25/19 3:39 PM, Andrew Haley wrote:
> On 1/25/19 2:39 PM, Andrew Haley wrote:
>> Massive win for gold here, on my (very old) AArch64 system:
> 
> And on another, faster AArch64 system:
> 
> BFD linker:
> 
> real  0m14.532s
> user  0m13.070s
> sys   0m1.419s
> 
> gold, single-threaded:
> 
> real  0m6.313s
> user  0m6.123s
> sys   0m0.190s
> 
> gold, multi-threaded:
> 
> real  0m4.129s
> user  0m8.724s
> sys   0m1.741s
> 
> Verdict: yes, please!
I couldn't get lld to work with any of the tools I have installed. So I built
a bleeding-edge gcc and lld, and I got:

lld, single-threaded

real0m3.269s
user0m3.049s
sys 0m0.221s

lld, multi-threaded:

real0m1.213s
user0m4.336s
sys 0m0.960s

Which is faster by a factor of 12! It'll be a while before this is installed
everywhere, but worth having. Effectively it makes linking go away as a major
component of build time.

-- 
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. 
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

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

[Andrew Haley]

On 1/25/19 6:43 PM, Martin Buchholz wrote:
> repeating my last experiment with explicit --threads:

Weird, so you don't get the same performance improvement with threads
that I do. You have fewer cores, maybe? My tests were with 8 and 48,
respectively. I'm also seeing more than a factor of 2 speedup from
bfd to gold. But never mind: choice is good.

-- 
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. 
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

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

[Martin Buchholz]

On Fri, Jan 25, 2019 at 10:07 AM Andrew Haley  wrote:
>
> On 1/25/19 5:01 PM, Martin Buchholz wrote:
> > I re-ran my linker performance experiment using  configure
> > --with-native-debug-symbols="internal"
> > lld is a big winner here:
>
> It looks to me like lld and multi-threaded gold would be a near tie. I
> think that lld uses multi-threading; I wonder why gold doesn't. But
> either is so fast linking libjvm.so that I no longer care.

repeating my last experiment with explicit --threads:

--- ld=gold ---
/usr/bin/g++ -fuse-ld=$ld -Wl,--threads -Wl,--hash-style=both
-Wl,-z,defs  9.18s user 4.98s system 329% cpu 4.292 total
/usr/bin/g++ -fuse-ld=$ld -Wl,--threads -Wl,--hash-style=both
-Wl,-z,defs  9.12s user 5.12s system 333% cpu 4.266 total
--- ld=lld ---
/usr/bin/g++ -fuse-ld=$ld -Wl,--threads -Wl,--hash-style=both
-Wl,-z,defs  2.70s user 1.09s system 324% cpu 1.169 total
/usr/bin/g++ -fuse-ld=$ld -Wl,--threads -Wl,--hash-style=both
-Wl,-z,defs  2.74s user 1.00s system 328% cpu 1.141 total

and with explicit --no-threads:

--- ld=gold ---
/usr/bin/g++ -fuse-ld=$ld -Wl,--no-threads -Wl,--hash-style=both
-Wl,-z,defs   4.61s user 0.61s system 99% cpu 5.213 total
/usr/bin/g++ -fuse-ld=$ld -Wl,--no-threads -Wl,--hash-style=both
-Wl,-z,defs   4.60s user 0.61s system 99% cpu 5.212 total
--- ld=lld ---
/usr/bin/g++ -fuse-ld=$ld -Wl,--no-threads -Wl,--hash-style=both
-Wl,-z,defs   1.67s user 0.60s system 99% cpu 2.289 total
/usr/bin/g++ -fuse-ld=$ld -Wl,--no-threads -Wl,--hash-style=both
-Wl,-z,defs   1.66s user 0.60s system 99% cpu 2.283 total

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

[Andrew Haley]

On 1/25/19 5:01 PM, Martin Buchholz wrote:
> I re-ran my linker performance experiment using  configure
> --with-native-debug-symbols="internal"
> lld is a big winner here:

It looks to me like lld and multi-threaded gold would be a near tie. I
think that lld uses multi-threading; I wonder why gold doesn't. But
either is so fast linking libjvm.so that I no longer care.

-- 
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. 
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

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

[Philip Race]

Category 3 has to deal with plenty of native code too ...

-phil

On 1/25/19, 9:15 AM, Martin Buchholz wrote:

In our own wrappers around configure, we've introduced the concept of
a "developer mode".  But this thread suggests there are 3 populations
of users invoking configure:

1. release engineers
2. hotspot developers
3. java library developers

Category 1 doesn't care about edit-compile-debug cycle - they just
want to build a reliable high-performance jdk without pitfalls.  This
is the VAST MAJORITY of users, for whom we should design defaults in
configure.
Category 2 wants debug info and maybe incremental linking.  They might
cheat and rebuild only libjvm.so and drop that one file into a
previously built jdk as part of their development cycle.
Category 3 doesn't care about native debug symbols at all

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

[Martin Buchholz]

In our own wrappers around configure, we've introduced the concept of
a "developer mode".  But this thread suggests there are 3 populations
of users invoking configure:

1. release engineers
2. hotspot developers
3. java library developers

Category 1 doesn't care about edit-compile-debug cycle - they just
want to build a reliable high-performance jdk without pitfalls.  This
is the VAST MAJORITY of users, for whom we should design defaults in
configure.
Category 2 wants debug info and maybe incremental linking.  They might
cheat and rebuild only libjvm.so and drop that one file into a
previously built jdk as part of their development cycle.
Category 3 doesn't care about native debug symbols at all

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

[Andrew Haley]

On 1/25/19 4:45 PM, Magnus Ihse Bursie wrote:
> On 2019-01-25 16:42, Andrew Haley wrote:
>> On 1/24/19 2:04 PM, Magnus Ihse Bursie wrote:
>>> 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'd love it to be an option for AArch64.
>>
> I hear you.
> 
> My current thinking is that I'm going to introduce a configure argument, 
> something like --with-toolchain-linker=gold, and if it is enabled, I'll 
> verify that gold is indeed present, and if it supports --threads. It 
> will be available on all gcc platforms.
> 
> This will take some more time to write than my initial one-liner, so 
> I'll take this back to the drawing board for awhile.

Thank you.

-- 
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. 
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

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

[Martin Buchholz]

I re-ran my linker performance experiment using  configure
--with-native-debug-symbols="internal"
lld is a big winner here:

--- ld=bfd ---
/usr/bin/g++ -fuse-ld=$ld -Wl,--hash-style=both -Wl,-z,defs
-Wl,-z,noexecstac  7.30s user 1.26s system 99% cpu 8.559 total
/usr/bin/g++ -fuse-ld=$ld -Wl,--hash-style=both -Wl,-z,defs
-Wl,-z,noexecstac  6.73s user 1.18s system 99% cpu 7.908 total
--- ld=gold ---
/usr/bin/g++ -fuse-ld=$ld -Wl,--hash-style=both -Wl,-z,defs
-Wl,-z,noexecstac  4.57s user 0.62s system 99% cpu 5.191 total
/usr/bin/g++ -fuse-ld=$ld -Wl,--hash-style=both -Wl,-z,defs
-Wl,-z,noexecstac  4.67s user 0.53s system 99% cpu 5.209 total
--- ld=lld ---
/usr/bin/g++ -fuse-ld=$ld -Wl,--hash-style=both -Wl,-z,defs
-Wl,-z,noexecstac  2.61s user 1.10s system 330% cpu 1.124 total
/usr/bin/g++ -fuse-ld=$ld -Wl,--hash-style=both -Wl,-z,defs
-Wl,-z,noexecstac  2.72s user 1.03s system 326% cpu 1.146 total


On Thu, Jan 24, 2019 at 10:49 AM Martin Buchholz  wrote:
>
> Here's an experiment using the 3 competing open source linkers to link
> hotspot.  This confirms that lld is faster than gold is faster than
> bfd, but is the one second saving worth the engineering effort?
>
>  $ (BUILDDIR=$HOME/ws/jdk/build/linux-x86_64-server-release; for
> linker in bfd gold lld; do echo --- $linker ---; time /usr/bin/g++
> -fuse-ld=$linker -Wl,--hash-style=both -Wl,-z,defs -Wl,-z,noexecstack
> -Wl,-O1 -Wl,-z,relro -m64 -static-libstdc++ -static-libgcc -shared
> -m64 -Wl,-version-script=$BUILDDIR/hotspot/variant-server/libjvm/mapfile
> -Wl,-soname=libjvm.so -o
> $BUILDDIR/support/modules_libs/java.base/server/libjvm.so
> @$BUILDDIR/hotspot/variant-server/libjvm/objs/_BUILD_LIBJVM_objectfilenames.txt
> -lm -ldl -lpthread; done)
> --- bfd ---
> /usr/bin/g++ -fuse-ld=$linker -Wl,--hash-style=both -Wl,-z,defs
> -Wl,-O1  -m6  1.31s user 0.36s system 99% cpu 1.669 total
> --- gold ---
> /usr/bin/g++ -fuse-ld=$linker -Wl,--hash-style=both -Wl,-z,defs
> -Wl,-O1  -m6  0.42s user 0.11s system 99% cpu 0.537 total
> --- lld ---
> /usr/bin/g++ -fuse-ld=$linker -Wl,--hash-style=both -Wl,-z,defs
> -Wl,-O1  -m6  0.25s user 0.20s system 145% cpu 0.310 total

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

[Magnus Ihse Bursie]

On 2019-01-25 16:42, Andrew Haley wrote:

On 1/24/19 2:04 PM, Magnus Ihse Bursie wrote:

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'd love it to be an option for AArch64.


I hear you.

My current thinking is that I'm going to introduce a configure argument, 
something like --with-toolchain-linker=gold, and if it is enabled, I'll 
verify that gold is indeed present, and if it supports --threads. It 
will be available on all gcc platforms.


This will take some more time to write than my initial one-liner, so 
I'll take this back to the drawing board for awhile.


/Magnus

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

[Andrew Haley]

On 1/24/19 2:04 PM, Magnus Ihse Bursie wrote:
> 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'd love it to be an option for AArch64.

-- 
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. 
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

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

[Andrew Haley]

On 1/25/19 2:39 PM, Andrew Haley wrote:
> Massive win for gold here, on my (very old) AArch64 system:

And on another, faster AArch64 system:

BFD linker:

real0m14.532s
user0m13.070s
sys 0m1.419s

gold, single-threaded:

real0m6.313s
user0m6.123s
sys 0m0.190s

gold, multi-threaded:

real0m4.129s
user0m8.724s
sys 0m1.741s

Verdict: yes, please!

-- 
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. 
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

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

[Andrew Haley]

Massive win for gold here, on my (very old) AArch64 system:

BFD linker:

 $ time /home/aph/gcc-x/aarch64-trunk-install/bin/g++ -Wl,-z,defs -fuse-ld=bfd 
-Wl,-z,noexecstack ...

real0m26.090s
user0m24.570s
sys 0m1.480s

gold, single-threaded:

 $ time /home/aph/gcc-x/aarch64-trunk-install/bin/g++ -Wl,-z,defs -fuse-ld=gold 
-Wl,-z,noexecstack ...

real0m12.325s
user0m12.030s
sys 0m0.280s

gold, multi-threaded:

 $ time /home/aph/gcc-x/aarch64-trunk-install/bin/g++ -Wl,-z,defs -fuse-ld=gold 
-Wl,--threads -Wl,-z,noexecstack ...

real0m8.297s
user0m14.680s
sys 0m1.650s

I would very much like to see this change go in, with a probe to make
sure that -fuse-ld=gold works. There is unfortunately one gotcha: on
some systems gold is built without threading support (why,
fercrineoutloud?) so it's necessary to probe for -Wl,--threads
separately.

-- 
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. 
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

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

[Martin Buchholz]

On Thu, Jan 24, 2019 at 2:28 PM Erik Joelsson  wrote:

> > Do the constituent object files have debugging information?  Sub-second
> > processing times for ~350 MiB of output are rather impressive.
>
> Ah! That must be it. I just tried with --with-native-debug-symbols=none
> and then I get comparable link times.

Yup!
Native debug symbols - more trouble than they're worth.

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

[Erik Joelsson]

On 2019-01-24 14:17, Florian Weimer wrote:

* Martin Buchholz:


Here's an experiment using the 3 competing open source linkers to link
hotspot.  This confirms that lld is faster than gold is faster than
bfd, but is the one second saving worth the engineering effort?

  $ (BUILDDIR=$HOME/ws/jdk/build/linux-x86_64-server-release; for
linker in bfd gold lld; do echo --- $linker ---; time /usr/bin/g++
-fuse-ld=$linker -Wl,--hash-style=both -Wl,-z,defs -Wl,-z,noexecstack
-Wl,-O1 -Wl,-z,relro -m64 -static-libstdc++ -static-libgcc -shared
-m64 -Wl,-version-script=$BUILDDIR/hotspot/variant-server/libjvm/mapfile
-Wl,-soname=libjvm.so -o
$BUILDDIR/support/modules_libs/java.base/server/libjvm.so
@$BUILDDIR/hotspot/variant-server/libjvm/objs/_BUILD_LIBJVM_objectfilenames.txt
-lm -ldl -lpthread; done)
--- bfd ---
/usr/bin/g++ -fuse-ld=$linker -Wl,--hash-style=both -Wl,-z,defs
-Wl,-O1  -m6  1.31s user 0.36s system 99% cpu 1.669 total
--- gold ---
/usr/bin/g++ -fuse-ld=$linker -Wl,--hash-style=both -Wl,-z,defs
-Wl,-O1  -m6  0.42s user 0.11s system 99% cpu 0.537 total
--- lld ---
/usr/bin/g++ -fuse-ld=$linker -Wl,--hash-style=both -Wl,-z,defs
-Wl,-O1  -m6  0.25s user 0.20s system 145% cpu 0.310 total

Do the constituent object files have debugging information?  Sub-second
processing times for ~350 MiB of output are rather impressive.


Ah! That must be it. I just tried with --with-native-debug-symbols=none 
and then I get comparable link times.


/Erik


On a Sandybridge-era Xeon (probably without SSD storage), I see a change
from 13 seconds to 8 seconds (BFD to gold).  This is the first libjvm.so
link from “make images”, and the output includes (apparently full)
debugging information.

Thanks,
Florian

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

[Erik Joelsson]

Hello,

On 2019-01-24 13:18, Martin Buchholz wrote:

I just copied the command out of
hotspot/variant-server/libjvm/objs/BUILD_LIBJVM_link.cmdline
and lightly edited it.


I took the .cmdline verbatim and then just added -fuse-ld=gold, so 
should be the same. I'm running on Ubuntu 18.04 using a devkit produced 
by the makefiles in make/devkit. I'm running SSDs and AFAIK they are 
working as they should. When running the command using /usr/bin/time, I 
get 99% cpu. If I instead try the native toolchain on the system, the 
times are better, but still miles from yours:


With devkit, default linker: 23s
With devkit, gold: 14.2s
Native compiler, default linker: 12.5s
Native compiler, gold: 8.1s

The machine has 2 cpus identifying as "Intel(R) Xeon(R) CPU E5-2665 0 @ 
2.40GHz". These are certainly not known for single threaded performance, 
but I'm surprised by this difference.


Given our reality, I think you can understand why this change matters. 
Cutting off nearly 10s from incremental rebuilds is significant for 
developers when in an edit-build-test loop.


/Erik


On my old underpowered NUC at home I see slightly worse numbers (but
warmed up, files on SSD - are you I/O bound?).

(BUILDDIR=$HOME/ws/jdk/build/linux-x86_64-server-release; for ld in
bfd gold; do time /usr/bin/g++ -fuse-ld=$ld -Wl,--hash-style=both
-Wl,-z,defs -Wl,-z,noexecstack -Wl,-O1 -Wl,-z,relro -m64
-static-libstdc++ -static-libgcc -shared -m64
-Wl,-version-script=$BUILDDIR/hotspot/variant-server/libjvm/mapfile
-Wl,-soname=libjvm.so -o
$BUILDDIR/support/modules_libs/java.base/server/libjvm.so
@$BUILDDIR/hotspot/variant-server/libjvm/objs/_BUILD_LIBJVM_objectfilenames.txt
-lm -ldl -lpthread; done)
/usr/bin/g++ -fuse-ld=$ld -Wl,--hash-style=both -Wl,-z,defs
-Wl,-z,noexecstac  2.28s user 0.33s system 99% cpu 2.621 total
/usr/bin/g++ -fuse-ld=$ld -Wl,--hash-style=both -Wl,-z,defs
-Wl,-z,noexecstac  0.65s user 0.09s system 98% cpu 0.747 total

On Thu, Jan 24, 2019 at 11:06 AM Erik Joelsson  wrote:

Are you actually linking libjvm.so in 1.3 seconds? A normal link time
for me using bfd is about 23 seconds while gold takes it to 14.2(+-0.2).
This is in line with what hotspot developers I have talked to also see
(and they have similar hardware).

My workstation has a few years on it, but surely machines haven't gotten
17 times faster? There must be something else at play here.

/Erik

On 2019-01-24 10:49, Martin Buchholz wrote:

Here's an experiment using the 3 competing open source linkers to link
hotspot.  This confirms that lld is faster than gold is faster than
bfd, but is the one second saving worth the engineering effort?

   $ (BUILDDIR=$HOME/ws/jdk/build/linux-x86_64-server-release; for
linker in bfd gold lld; do echo --- $linker ---; time /usr/bin/g++
-fuse-ld=$linker -Wl,--hash-style=both -Wl,-z,defs -Wl,-z,noexecstack
-Wl,-O1 -Wl,-z,relro -m64 -static-libstdc++ -static-libgcc -shared
-m64 -Wl,-version-script=$BUILDDIR/hotspot/variant-server/libjvm/mapfile
-Wl,-soname=libjvm.so -o
$BUILDDIR/support/modules_libs/java.base/server/libjvm.so
@$BUILDDIR/hotspot/variant-server/libjvm/objs/_BUILD_LIBJVM_objectfilenames.txt
-lm -ldl -lpthread; done)
--- bfd ---
/usr/bin/g++ -fuse-ld=$linker -Wl,--hash-style=both -Wl,-z,defs
-Wl,-O1  -m6  1.31s user 0.36s system 99% cpu 1.669 total
--- gold ---
/usr/bin/g++ -fuse-ld=$linker -Wl,--hash-style=both -Wl,-z,defs
-Wl,-O1  -m6  0.42s user 0.11s system 99% cpu 0.537 total
--- lld ---
/usr/bin/g++ -fuse-ld=$linker -Wl,--hash-style=both -Wl,-z,defs
-Wl,-O1  -m6  0.25s user 0.20s system 145% cpu 0.310 total

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

[Florian Weimer]

* Martin Buchholz:

> Here's an experiment using the 3 competing open source linkers to link
> hotspot.  This confirms that lld is faster than gold is faster than
> bfd, but is the one second saving worth the engineering effort?
>
>  $ (BUILDDIR=$HOME/ws/jdk/build/linux-x86_64-server-release; for
> linker in bfd gold lld; do echo --- $linker ---; time /usr/bin/g++
> -fuse-ld=$linker -Wl,--hash-style=both -Wl,-z,defs -Wl,-z,noexecstack
> -Wl,-O1 -Wl,-z,relro -m64 -static-libstdc++ -static-libgcc -shared
> -m64 -Wl,-version-script=$BUILDDIR/hotspot/variant-server/libjvm/mapfile
> -Wl,-soname=libjvm.so -o
> $BUILDDIR/support/modules_libs/java.base/server/libjvm.so
> @$BUILDDIR/hotspot/variant-server/libjvm/objs/_BUILD_LIBJVM_objectfilenames.txt
> -lm -ldl -lpthread; done)
> --- bfd ---
> /usr/bin/g++ -fuse-ld=$linker -Wl,--hash-style=both -Wl,-z,defs
> -Wl,-O1  -m6  1.31s user 0.36s system 99% cpu 1.669 total
> --- gold ---
> /usr/bin/g++ -fuse-ld=$linker -Wl,--hash-style=both -Wl,-z,defs
> -Wl,-O1  -m6  0.42s user 0.11s system 99% cpu 0.537 total
> --- lld ---
> /usr/bin/g++ -fuse-ld=$linker -Wl,--hash-style=both -Wl,-z,defs
> -Wl,-O1  -m6  0.25s user 0.20s system 145% cpu 0.310 total

Do the constituent object files have debugging information?  Sub-second
processing times for ~350 MiB of output are rather impressive.

On a Sandybridge-era Xeon (probably without SSD storage), I see a change
from 13 seconds to 8 seconds (BFD to gold).  This is the first libjvm.so
link from “make images”, and the output includes (apparently full)
debugging information.

Thanks,
Florian

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

[Martin Buchholz]

I just copied the command out of
hotspot/variant-server/libjvm/objs/BUILD_LIBJVM_link.cmdline
and lightly edited it.

On my old underpowered NUC at home I see slightly worse numbers (but
warmed up, files on SSD - are you I/O bound?).

(BUILDDIR=$HOME/ws/jdk/build/linux-x86_64-server-release; for ld in
bfd gold; do time /usr/bin/g++ -fuse-ld=$ld -Wl,--hash-style=both
-Wl,-z,defs -Wl,-z,noexecstack -Wl,-O1 -Wl,-z,relro -m64
-static-libstdc++ -static-libgcc -shared -m64
-Wl,-version-script=$BUILDDIR/hotspot/variant-server/libjvm/mapfile
-Wl,-soname=libjvm.so -o
$BUILDDIR/support/modules_libs/java.base/server/libjvm.so
@$BUILDDIR/hotspot/variant-server/libjvm/objs/_BUILD_LIBJVM_objectfilenames.txt
-lm -ldl -lpthread; done)
/usr/bin/g++ -fuse-ld=$ld -Wl,--hash-style=both -Wl,-z,defs
-Wl,-z,noexecstac  2.28s user 0.33s system 99% cpu 2.621 total
/usr/bin/g++ -fuse-ld=$ld -Wl,--hash-style=both -Wl,-z,defs
-Wl,-z,noexecstac  0.65s user 0.09s system 98% cpu 0.747 total

On Thu, Jan 24, 2019 at 11:06 AM Erik Joelsson  wrote:
>
> Are you actually linking libjvm.so in 1.3 seconds? A normal link time
> for me using bfd is about 23 seconds while gold takes it to 14.2(+-0.2).
> This is in line with what hotspot developers I have talked to also see
> (and they have similar hardware).
>
> My workstation has a few years on it, but surely machines haven't gotten
> 17 times faster? There must be something else at play here.
>
> /Erik
>
> On 2019-01-24 10:49, Martin Buchholz wrote:
> > Here's an experiment using the 3 competing open source linkers to link
> > hotspot.  This confirms that lld is faster than gold is faster than
> > bfd, but is the one second saving worth the engineering effort?
> >
> >   $ (BUILDDIR=$HOME/ws/jdk/build/linux-x86_64-server-release; for
> > linker in bfd gold lld; do echo --- $linker ---; time /usr/bin/g++
> > -fuse-ld=$linker -Wl,--hash-style=both -Wl,-z,defs -Wl,-z,noexecstack
> > -Wl,-O1 -Wl,-z,relro -m64 -static-libstdc++ -static-libgcc -shared
> > -m64 -Wl,-version-script=$BUILDDIR/hotspot/variant-server/libjvm/mapfile
> > -Wl,-soname=libjvm.so -o
> > $BUILDDIR/support/modules_libs/java.base/server/libjvm.so
> > @$BUILDDIR/hotspot/variant-server/libjvm/objs/_BUILD_LIBJVM_objectfilenames.txt
> > -lm -ldl -lpthread; done)
> > --- bfd ---
> > /usr/bin/g++ -fuse-ld=$linker -Wl,--hash-style=both -Wl,-z,defs
> > -Wl,-O1  -m6  1.31s user 0.36s system 99% cpu 1.669 total
> > --- gold ---
> > /usr/bin/g++ -fuse-ld=$linker -Wl,--hash-style=both -Wl,-z,defs
> > -Wl,-O1  -m6  0.42s user 0.11s system 99% cpu 0.537 total
> > --- lld ---
> > /usr/bin/g++ -fuse-ld=$linker -Wl,--hash-style=both -Wl,-z,defs
> > -Wl,-O1  -m6  0.25s user 0.20s system 145% cpu 0.310 total

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

[Erik Joelsson]

Are you actually linking libjvm.so in 1.3 seconds? A normal link time 
for me using bfd is about 23 seconds while gold takes it to 14.2(+-0.2). 
This is in line with what hotspot developers I have talked to also see 
(and they have similar hardware).


My workstation has a few years on it, but surely machines haven't gotten 
17 times faster? There must be something else at play here.


/Erik

On 2019-01-24 10:49, Martin Buchholz wrote:

Here's an experiment using the 3 competing open source linkers to link
hotspot.  This confirms that lld is faster than gold is faster than
bfd, but is the one second saving worth the engineering effort?

  $ (BUILDDIR=$HOME/ws/jdk/build/linux-x86_64-server-release; for
linker in bfd gold lld; do echo --- $linker ---; time /usr/bin/g++
-fuse-ld=$linker -Wl,--hash-style=both -Wl,-z,defs -Wl,-z,noexecstack
-Wl,-O1 -Wl,-z,relro -m64 -static-libstdc++ -static-libgcc -shared
-m64 -Wl,-version-script=$BUILDDIR/hotspot/variant-server/libjvm/mapfile
-Wl,-soname=libjvm.so -o
$BUILDDIR/support/modules_libs/java.base/server/libjvm.so
@$BUILDDIR/hotspot/variant-server/libjvm/objs/_BUILD_LIBJVM_objectfilenames.txt
-lm -ldl -lpthread; done)
--- bfd ---
/usr/bin/g++ -fuse-ld=$linker -Wl,--hash-style=both -Wl,-z,defs
-Wl,-O1  -m6  1.31s user 0.36s system 99% cpu 1.669 total
--- gold ---
/usr/bin/g++ -fuse-ld=$linker -Wl,--hash-style=both -Wl,-z,defs
-Wl,-O1  -m6  0.42s user 0.11s system 99% cpu 0.537 total
--- lld ---
/usr/bin/g++ -fuse-ld=$linker -Wl,--hash-style=both -Wl,-z,defs
-Wl,-O1  -m6  0.25s user 0.20s system 145% cpu 0.310 total

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

[Martin Buchholz]

Here's an experiment using the 3 competing open source linkers to link
hotspot.  This confirms that lld is faster than gold is faster than
bfd, but is the one second saving worth the engineering effort?

 $ (BUILDDIR=$HOME/ws/jdk/build/linux-x86_64-server-release; for
linker in bfd gold lld; do echo --- $linker ---; time /usr/bin/g++
-fuse-ld=$linker -Wl,--hash-style=both -Wl,-z,defs -Wl,-z,noexecstack
-Wl,-O1 -Wl,-z,relro -m64 -static-libstdc++ -static-libgcc -shared
-m64 -Wl,-version-script=$BUILDDIR/hotspot/variant-server/libjvm/mapfile
-Wl,-soname=libjvm.so -o
$BUILDDIR/support/modules_libs/java.base/server/libjvm.so
@$BUILDDIR/hotspot/variant-server/libjvm/objs/_BUILD_LIBJVM_objectfilenames.txt
-lm -ldl -lpthread; done)
--- bfd ---
/usr/bin/g++ -fuse-ld=$linker -Wl,--hash-style=both -Wl,-z,defs
-Wl,-O1  -m6  1.31s user 0.36s system 99% cpu 1.669 total
--- gold ---
/usr/bin/g++ -fuse-ld=$linker -Wl,--hash-style=both -Wl,-z,defs
-Wl,-O1  -m6  0.42s user 0.11s system 99% cpu 0.537 total
--- lld ---
/usr/bin/g++ -fuse-ld=$linker -Wl,--hash-style=both -Wl,-z,defs
-Wl,-O1  -m6  0.25s user 0.20s system 145% cpu 0.310 total

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

[Andrew Haley]

On 1/24/19 1:25 PM, Aleksey Shipilev wrote:

> That'd be nice. Maybe we should check for the presence of ld.gold,
> though, and override LD when it is available? That would also allow
> the fallback when ld.gold is misbehaving, but setting LD forcefully.

Yes, we absolutely should check. I just built the latest buinutils, and
gold is not enabled by default. Apart from anything else, that means gold
won't get so much testing.

-- 
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. 
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

Re: 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

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

[Erik Joelsson]

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

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

[Martin Buchholz]

On Thu, Jan 24, 2019 at 7:46 AM Magnus Ihse Bursie
 wrote:

> So, we already tacitly assume a specific linker with the gcc toolchain; we 
> have just not made that check explicitly.

gcc  runs on almost every system, but it's harder to replace the
compiler than the linker, so gcc ends up being used with many other OS
default linkers.
Same for clang.
Meanwhile, we have 3 competing open source linkers: bfd gold lld, so
linker availability is especially fluid these days.
Incremental linking will only be of interest to openjdk developers
(and then probably only hotspot developers) for non-release builds, so
should be opt-in.

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

[Magnus Ihse Bursie]

I agree that the relationship between compiler, linker and OS is problematic. 
In the OpenJDK build system, we have used the concept of "toolchain", by which 
we mean (amongst other things) a compiler and a linker working together. For 
some platforms it's a perfect fit (eg Visual Studio), for others like gcc it's 
so-so, for yet others (solstudio) it's really bad. 

So, we already tacitly assume a specific linker with the gcc toolchain; we have 
just not made that check explicitly. 

As I said in a previous email, part of the reason for this switch is to allow 
--incremental. So for that reason, we must know that the linker supports that 
option. 

/Magnus

> 24 jan. 2019 kl. 15:48 skrev Martin Buchholz :
> 
> Getting into the business of choosing the linker is big trouble.
> 
> The system default toolchain may have already chosen a linker.
> 
> BFD might be configured to have either bfd ld or gold.
> # Handle --enable-gold, --enable-ld.
> # --disable-gold [--enable-ld]
> # Build only ld.  Default option.
> # --enable-gold [--enable-ld]
> # Build both gold and ld.  Install gold as "ld.gold", install ld
> # as "ld.bfd" and "ld".
> # --enable-gold=default [--enable-ld]
> # Build both gold and ld.  Install gold as "ld.gold" and "ld",
> # install ld as "ld.bfd".
> # --enable-gold[=default] --disable-ld
> # Build only gold, which is then installed as both "ld.gold" and "ld".
> # --enable-gold --enable-ld=default
> # Build both gold (installed as "ld.gold") and ld (installed as "ld"
> # and ld.bfd).
> # In other words, ld is default
> 
> The compiler driver itself may have been configured to choose a linker.
> 
> The system administrator may have used update-alternatives to choose a linker.
> 
> A user might have configured openjdk to use -fuse-ld=... (we do this!)
> How do you resolve the conflict?
> 
> There's evidence that lld is even faster than gold.  The Internet says,
> """Liked linking 3x faster with gold? Link 10x faster with lld!"""
> so hardcoding gold might be a regression!
> 
> So ... -fuse-ld is a flag that is perfect for a local wrapper around
> configure that is __not__ part of openjdk (we do this!)

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

[Martin Buchholz]

Getting into the business of choosing the linker is big trouble.

The system default toolchain may have already chosen a linker.

BFD might be configured to have either bfd ld or gold.
# Handle --enable-gold, --enable-ld.
# --disable-gold [--enable-ld]
# Build only ld.  Default option.
# --enable-gold [--enable-ld]
# Build both gold and ld.  Install gold as "ld.gold", install ld
# as "ld.bfd" and "ld".
# --enable-gold=default [--enable-ld]
# Build both gold and ld.  Install gold as "ld.gold" and "ld",
# install ld as "ld.bfd".
# --enable-gold[=default] --disable-ld
# Build only gold, which is then installed as both "ld.gold" and "ld".
# --enable-gold --enable-ld=default
# Build both gold (installed as "ld.gold") and ld (installed as "ld"
# and ld.bfd).
# In other words, ld is default

The compiler driver itself may have been configured to choose a linker.

The system administrator may have used update-alternatives to choose a linker.

A user might have configured openjdk to use -fuse-ld=... (we do this!)
How do you resolve the conflict?

There's evidence that lld is even faster than gold.  The Internet says,
"""Liked linking 3x faster with gold? Link 10x faster with lld!"""
so hardcoding gold might be a regression!

So ... -fuse-ld is a flag that is perfect for a local wrapper around
configure that is __not__ part of openjdk (we do this!)

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

[Magnus Ihse Bursie]

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?


/Magnus



Thanks,
Florian

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

[Florian Weimer]

* 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.

Thanks,
Florian

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

[Magnus Ihse Bursie]

On 2019-01-24 14:20, John Paul Adrian Glaubitz wrote:

On 1/24/19 2:11 PM, Magnus Ihse Bursie wrote:

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.

I would recommend testing this change on all supported targets. Gold is
definitely not as mature on all targets as bfd in my experience. There
are still some cases where it can cause issues.

Good point.

I was mainly considering x86_64 here. It might be safest to limit the 
use of gold to this platform. From the developer point of view, it's the 
one that counts most.


But even if I change this to only use gold on x86_64, I'd still like to 
bump the binutils version globally. There's no good way to express 
different version requirements on different platforms for the same 
toolchain. Do you see a problem with that?


/Magnus




Adrian

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

[Aleksey Shipilev]

On 1/24/19 2:15 PM, Magnus Ihse Bursie wrote:
> I see now on Wikipedia that gold was added to binutils 2.19.[1] (I thought it 
> was older still...)
> We currently have this check:
> TOOLCHAIN_MINIMUM_LD_VERSION_gcc="2.18"
> 
> As part of this fix, I ought to bump it to 2.19, so we know for sure that 
> gold is included.

Not sure it would be compatible with all current build environments. I asked 
Red Hat people if this
would be problematic for them.

>> Bug: https://bugs.openjdk.java.net/browse/JDK-8217723
>> Patch inline:
>> diff --git a/make/autoconf/flags-ldflags.m4 b/make/autoconf/flags-ldflags.m4
>> --- a/make/autoconf/flags-ldflags.m4
>> +++ b/make/autoconf/flags-ldflags.m4
>> @@ -70,7 +70,7 @@
>>  fi
>>
>>  # Add -z defs, to forbid undefined symbols in object files.
>> -    BASIC_LDFLAGS="$BASIC_LDFLAGS -Wl,-z,defs"
>> +    BASIC_LDFLAGS="$BASIC_LDFLAGS -Wl,-z,defs -fuse-ld=gold"
>>
>>  BASIC_LDFLAGS_JVM_ONLY="-Wl,-O1 -Wl,-z,relro"

That'd be nice. Maybe we should check for the presence of ld.gold, though, and 
override LD when it
is available? That would also allow the fallback when ld.gold is misbehaving, 
but setting LD forcefully.

-Aleksey

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

[John Paul Adrian Glaubitz]

On 1/24/19 2:11 PM, Magnus Ihse Bursie wrote:
> 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.

I would recommend testing this change on all supported targets. Gold is
definitely not as mature on all targets as bfd in my experience. There
are still some cases where it can cause issues.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

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

[Magnus Ihse Bursie]

I see now on Wikipedia that gold was added to binutils 2.19.[1] (I 
thought it was older still...)


We currently have this check:

TOOLCHAIN_MINIMUM_LD_VERSION_gcc="2.18"

As part of this fix, I ought to bump it to 2.19, so we know for sure 
that gold is included.


Volker, would that be a problem for you?

/Magnus
[1] https://en.wikipedia.org/wiki/Gold_(linker)

On 2019-01-24 14:11, Magnus Ihse Bursie wrote:
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.


This issue is about replacing ld.bfd with ld.gold for our gcc 
toolchain. In general, this cuts linking times by half or more.


As a future improvement, gold also allows for incremental linking. 
Turning on that is outside the scope of this issue.


Bug: https://bugs.openjdk.java.net/browse/JDK-8217723
Patch inline:
diff --git a/make/autoconf/flags-ldflags.m4 
b/make/autoconf/flags-ldflags.m4

--- a/make/autoconf/flags-ldflags.m4
+++ b/make/autoconf/flags-ldflags.m4
@@ -70,7 +70,7 @@
 fi

 # Add -z defs, to forbid undefined symbols in object files.
-    BASIC_LDFLAGS="$BASIC_LDFLAGS -Wl,-z,defs"
+    BASIC_LDFLAGS="$BASIC_LDFLAGS -Wl,-z,defs -fuse-ld=gold"

 BASIC_LDFLAGS_JVM_ONLY="-Wl,-O1 -Wl,-z,relro"

/Magnus