[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-build-dev
Subject:    Re: building libjvm with -Os for space optimization - was : RE: RFR: 8234525: enable link-time secti
From:       Ioi Lam <ioi.lam () oracle ! com>
Date:       2019-11-30 1:13:37
Message-ID: e3b7cedc-7054-627f-9ad2-30335ee85fae () oracle ! com
[Download RAW message or body]



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


[prev in list] [next in list] [prev in thread] [next in thread]