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