building libjvm with -Os for space optimization - was : RE: RFR: 8234525: enable link-time section-gc for linux s390x to remove unused code

[Doerr, Martin]

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.redestad at oracle.com>
> Sent: Mittwoch, 27. November 2019 23:35
> To: Doerr, Martin <martin.doerr at sap.com>; Baesken, Matthias
> <matthias.baesken at sap.com>; Erik Joelsson <erik.joelsson at oracle.com>;
> 'build-dev at openjdk.java.net' <build-dev at openjdk.java.net>; 'hotspot-
> dev at openjdk.java.net' <hotspot-dev at 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