[8u] RFR: 8210352: [hotspot] --with-extra-cxx-flags should not lower optimization

[Severin Gehwolf]

On Wed, 2018-09-05 at 07:38 +1000, David Holmes wrote:
> On 5/09/2018 7:29 AM, Erik Joelsson wrote:
> > On 2018-09-04 14:06, David Holmes wrote:
> > > Hi Severin,
> > > 
> > > On 5/09/2018 1:36 AM, Severin Gehwolf wrote:
> > > > Hi,
> > > > 
> > > > Could I please get reviews of this JDK 8-only change?
> > > > 
> > > > The issue at hand is that the JDK 8 build seems to be inconsistent with
> > > > later JDK builds (9+). When somebody passes
> > > > --with-extra-c{,xx}-flags="-O2" to the OpenJDK build on JDK 9+ the JVM
> > > > will get compiled with -O3 for a release type build. Not so on JDK 8.
> > > > It gets compiled with -O2. The reason we are passing extra C flags via
> > > > configure is to: a) get distro-wide optimization done b) allow for
> > > > hardened builds. Without the --with-extra-c{,xx}-flags="-O2" flag,
> > > > libjsig, libsaproc will get compiled with no optimization. That's what
> > > > I'd like to fix. The proposed patch allows one to force -O2 for the JVM
> > > > via OPT_EXTRAS make variable if so desired. Omitting OPT_EXTRAS=-O2
> > > > allows one to get hotspot libraries optimized with -O2 and better.
> > > > Thoughts?
> > > 
> > > I don't understand the motivation for this change. Compatibility with 
> > > future versions is not a usual compatibility we care about. I'd also 
> > > argue the behaviour in 8 seems more correct. If I set an extra cflag I 
> > > expect it to be applied to all compilations - cross-compilation would 
> > > be broken if that were not the case. I don't see why -On should be 
> > > treated any differently.
> > > 
> > 
> > I do agree with you, sort of. All user added flags are applied 
> > everywhere. The reason the optimization isn't overridden is because of 
> > the order the flags are applied on the command line. In JDK 9 (and in 8 
> > for JDK libs) we apply optimization flags after the custom flags from 
> > the user. (For Hotspot in 8 it seems the custom flags are added after 
> > the optimization flags.) IIRC we did this intentionally in the "new 
> > build" with the reasoning that we are pretty particular with the 
> > optimization flags in many cases so a global override is probably not a 
> > good idea.
> > 
> > The suggested patch, filtering specific -O flags from the user supplied 
> > flags does not look good to me. I would however be ok with changing the 
> > ordering of flags for libjvm so that the same behavior as in 9 and later 
> > (and as for JDK libs in 8) is achieved.
> 
> Okay - but such a change should be considered an enhancement request, 
> not a bug fix, and must then go through the enhancement request process 
> for 8u. My concern is that this may fix Severin's issue but may break 
> others who do custom builds of 8u code. The 8u maintainers would have to 
> make the decision to accept this change or not.

Fair enough. I'll get this process started then.

Thanks,
Severin

> > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8210352
> > > > webrev: 
> > > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8210352/webrev.01/
> > > > 
> > > > Thanks,
> > > > Severin
> > > >