Hi Claes, yeah, that makes sense. > Hopefully we don't have to do one RFE per file.. :-) 😊 I should have written set of files or directories or whatever.
Thanks for your input. Best regards, Martin > -----Original Message----- > From: Claes Redestad <claes.redes...@oracle.com> > Sent: Mittwoch, 27. November 2019 23:35 > To: Doerr, Martin <martin.do...@sap.com>; Baesken, Matthias > <matthias.baes...@sap.com>; Erik Joelsson <erik.joels...@oracle.com>; > 'build-dev@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 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 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. > > that might very well be the end result, and once/if we've gone down this > path long enough to see that -O3 becomes the exception, we can re- > examine the default. Changing the default and then trying to recuperate > would be hard/impossible to do incrementally. > > > > > 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 > Hopefully we don't have to do one RFE per file.. :-) > > /Claes
