On 2020-01-30 21:38, August Nagro wrote:
Its been a while since I tried, but if I remember correctly I had to
delete the code that tested the compiler name / version in one of the
sh files. I set the compiler to icc via the environment variables.
The build ran for a while but then stopped
Its been a while since I tried, but if I remember correctly I had to delete
the code that tested the compiler name / version in one of the sh files. I
set the compiler to icc via the environment variables.
The build ran for a while but then stopped with an error message. I
remember it not being
On 2019-12-18 00:05, August Nagro wrote:
I published some benchmarks of OpenJDK on Mac with Ofast and O3 [1]. Some
microbenchmarks like Netty’s HttpObjectEncoder experienced >100% speedup with
O3, and the more real-world Dacapo suite was ~15% improvement over O2 (which is
exactly the same
ber 2019 14:42
> *To:* Baesken, Matthias
> *Cc:* claes.redes...@oracle.com; Doerr, Martin ;
> erik.joels...@oracle.com; build-dev@openjdk.java.net;
> hotspot-...@openjdk.java.net
> *Subject:* Re: RE: building libjvm with -Os for space optimization - was
> : RE: RFR: 8234525: enabl
...@oracle.com; Doerr, Martin ;
erik.joels...@oracle.com; build-dev@openjdk.java.net;
hotspot-...@openjdk.java.net
Subject: Re: RE: building libjvm with -Os for space optimization - was : RE:
RFR: 8234525: enable link-time section-gc for linux s390x to remove unused code
I compiled with clang since I'm
I compiled with clang since I'm on Mac.
The Renaissance benchmark suite is also a good one that I learned about
recently.
My opinion is that there are probably more compelling alternatives if
reducing binary size is the goal. Even if the tests show that Os/O2 is no
different than O3, who knows
I published some benchmarks of OpenJDK on Mac with Ofast and O3 [1]. Some
microbenchmarks like Netty’s HttpObjectEncoder experienced >100% speedup with
O3, and the more real-world Dacapo suite was ~15% improvement over O2 (which is
exactly the same as Os). I did include a few other flags,
Hi August , thanks for pointing to your webpage, very interesting !
We did our builds+tests/benchmarks with gcc 7.4.0 , what compiler+version
did you use?
Probably I should look a bit more into Dacapo (we used that one in the past too
sometimes).
Best regards, Matthias
>
> I
Hello, a small update from my side . I had (on Linux) for a couple of days
our jdk11u tests + benchmarks running with -Os instead of the usual
settings (-O3) .
With have (independent of -Os / -O3) a bit of variance in our benchmarks
( jbb15 , jvm2008, jvm98 ) .
However the
Joelsson ; 'build-
d...@openjdk.java.net' ; 'hotspot-
d...@openjdk.java.net'
Subject: Re: building libjvm with -Os for space optimization - was : RE: RFR:
8234525: enable link-time section-gc for linux s390x to remove unused code
Hi,
we discussed doing the opposite for Mac OS X recently, where
mber 2019 23:35
> To: Doerr, Martin ; Baesken, Matthias
> ; Erik Joelsson ;
> 'build-dev@openjdk.java.net' ; 'hotspot-
> d...@openjdk.java.net'
> Subject: Re: building libjvm with -Os for space optimization - was : RE: RFR:
> 8234525: enable link-time section-gc for linux s390x
Hi Martin,
On 2019-11-27 19:03, Doerr, Martin wrote:
Hi Claes,
that kind of surprises me. I'd expect files which rather benefit from -O3 to be
far less than those which benefit from -Os.
Most performance critical code lives inside the code cache and is not dependent
on C++ compiler
building libjvm with -Os for space optimization - was : RE: RFR:
> 8234525: enable link-time section-gc for linux s390x to remove unused code
>
> Hi,
>
> we discussed doing the opposite for Mac OS X recently, where builds are
> currently set to -Os by default. -O3 helped various
Hi,
we discussed doing the opposite for Mac OS X recently, where builds are
currently set to -Os by default. -O3 helped various networking
(micro)benchmarks by up to 20%.
Rather than doing -Os by default and then cherry-pick things over to -O3
on a case-by-case basis, I'd suggest the opposite:
Hello Martin, I checked building libjvm.so with -Os (instead of -O3) .
I used gcc-7 on linux x86_64 .
The size of libjvm.so dropped from24M (normal night make with -O3)
to 18M ( test make with -Os) .
(adding the link-time gc might reduce the size by another ~ 10 % ,
On 2019-11-26 04:53, Baesken, Matthias wrote:
Erik, may I add you as a reviewer too ?
Yes.
/Erik
Hi Martin ,
> Hi Matthias and Erik,
>
> I also think this is an interesting option.
>
> I like the idea to generate smaller libraries. In addition to that, I could
> also
> imagine building with -Os (size optimized) by default and only select -O3 for
> performance critical files (e.g. C2's
mber 2019 16:01
> To: Erik Joelsson ; 'build-dev@openjdk.java.net'
> ; core-libs-...@openjdk.java.net
> Subject: RE: RFR: 8234525: enable link-time section-gc for linux
> s390x to remove unused code
>
> Hi Erik,
>yes it makes the build more chatty -
> our linux s390
Hi Erik,
yes it makes the build more chatty -
our linux s390 product build log of jdk/jdk goes from ~ 60.000
lines to ~ 123.000 lines with the patch.
However the change is linux s390 only so I guess it will not disturb other
people ( in case we bring it to more platforms
Hello Matthias,
This looks like an interesting change. If you want to enable this for
s390x, I'm ok with it. If it works out well, perhaps we can find a way
to expand this to other architectures.
Do you really want to set --print-gc-sections by default? I would assume
that makes the build
Hello,
gcc and ld can be instructed to work together to "garbage collect" unused input
sections.
This feature eliminates unused code from native libraries. As a prerequisite to
take full advantage of the feature,
the source files need to be compiled with "-ffunction-sections -fdata-sections".
21 matches
Mail list logo
