On 11/27/19 10:03 AM, 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 optimizations.
I'd expect GC code, C2's register allocation and a few runtime files to be the
most performance critical C++ code.
So the list of files for -Os may become long.
Class loading/verification/resolution are also sensitive to C++ speed.
Thanks
- Ioi
Yeah, I think we should use native profiling information to find out what's
really going on.
Your idea to change file by file and check for performance regression makes
sense to me, though.
Best regards,
Martin
-----Original Message-----
From: Claes Redestad <claes.redes...@oracle.com>
Sent: Mittwoch, 27. November 2019 18:57
To: Baesken, Matthias <matthias.baes...@sap.com>; Doerr, Martin
<martin.do...@sap.com>; Erik Joelsson <erik.joels...@oracle.com>; 'build-
d...@openjdk.java.net' <build-dev@openjdk.java.net>; 'hotspot-
d...@openjdk.java.net' <hotspot-...@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 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: keep -O3 as the
default, start evaluating -Os on a case-by-case basis. This allows for
an incremental approach where we identify things that are definitely not
performance critical, e.g., never shows up in profiles, and switch those
compilation units over to -Os. Check for harmful performance impact and
expected footprint improvement; rinse; repeat.
$.02
/Claes
On 2019-11-27 17:36, Baesken, Matthias wrote:
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 from 24M (normal night make with -O3)
to 18M ( test make with -Os) .
(adding the link-time gc might reduce the size by another ~ 10 % , but
those 2 builds were without the ltgc )
Cannot say much so far about performance impact .
Best regards, Matthias
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 register allocation, some gc code, ...).
If we want to go into such a direction for all linux platforms and want to
use
this s390 only change as some kind of pipe cleaner, I think this change is
fine
and can get pushed.
Otherwise, I think building s390 differently and not intending to do the
same
for other linux platforms would be not so good.
We should only make sure the exported symbols are set up properly to
avoid
that this optimization throws out too much.
My 50 Cents.
Best regards,
Martin
