We've experimented with this as well a few years ago. The problem was that it doesn't correctly support all architectures (if I remember right there were some problems with unknown relocation types). So when you add this we have to take care that it will be only used on ppc/s390/aarch if it really works.
Regards, Volker On Mon, Mar 27, 2017 at 10:47 AM, Ioi Lam <[email protected]> wrote: > > > On 3/26/17 8:43 PM, Claes Redestad wrote: >> >> +1, at least to make it an optional setting. >> >> Making it heavily multi-threaded by default may be a pessimization when >> we're doing full image builds, cf. how many of the java tools in the >> build is using serial GC and fewer compiler threads to play nice under >> heavy parallelism. >> >> Have you done any assessment on whether this has any effect on static >> footprint and performance on the resulting images? >> > I haven't done any formal measurements. Anecdotally when I ran a class > loading benchmark it shows no noticeable difference in performance. I didn't > measure the size of the libjvm.so > > Thanks > - Ioi > >> /Claes >> >> On 2017-03-26 12:30, Ioi Lam wrote: >>> >>> I just tried adding -fuse-ld=gold to the g++ linker flags, and my >>> libjvm.so link time shrinks from 18 seconds to 6 seconds. And that's >>> with single threaded linking. If I add "-Wl,--threads >>> -Wl,--thread-count,8" it becomes 4 seconds. It doesn't seem to scale >>> after 8 threads. >>> >>> Any plans for adding official (perhaps optional) support for gold in the >>> JDK build system? >>> >>> Thanks >>> - Ioi > >
