[8u] Request for enhancement backport approval for 8210352: [hotspot] --with-extra-cxx-flags should not lower optimization

[Andrew Hughes]

On Wed, 5 Sep 2018 at 09:55, Severin Gehwolf <sgehwolf at redhat.com> wrote:
>
> Hi,
>
> I've been asked to proceed with the enhancement request process[1] for
> this proposed JDK 8u fix.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8210352
>
> Currently JDK 8 and JDK 9+ behave differently in terms of hotspot
> libjvm optimization flags. In JDK 8 they can be overridden by
> --with-extra-c{,xx}-flags configure options. In JDK 9+ this cannot be
> done as libjvm optimization flags come after any extra C flags from
> configure. This enhancement request for JDK 8 asks for the build of the
> JVM to behave the same as JDK 9+.
>
> The rationale why we'd wanted such behaviour is as follows. In Fedora
> distribution wide config exists which sets C flags. Hooks are in place
> so that all natives get compiled with these C flags. One goal is to
> ensure all distro libraries and programs are being optimized at at
> least a certain threshold, say >= -O2. This includes OpenJDK.
>
> While there is a way to fix the build system to compile each and every
> library with some optimization level the risk is that there might not
> be a one-size-fits-all downstream distribution consumers. The easier
> and more flexible case is to allow for this via extra C flags which can
> be passed to the build. This is currently possible.
>
> The exception to this rule should be libjvm. Optimization levels for
> the JVM have been thoroughly tested and to some extent been lowered via
> a by-object overrides. Example case is
> sharedRuntimeTrans.o and sharedRuntimeTrig.o which have -O0
> settings[2]. The point is that for the JVM optimization flags have been
> thoroughly crafted to a point where they are today. Letting the user
> override this to some other value, like -O2, via a simple configure
> option seems dangerous. Currently in JDK 8 it's possible to override
> JVM optimization flags via --with-extra-c{,xx}-flags configure option.
>
> OK to move ahead with this enhancement for JDK 8u?
>
> Thanks,
> Severin
>
> [1] http://mail.openjdk.java.net/pipermail/build-dev/2018-September/023064.html
> [2] http://hg.openjdk.java.net/jdk8u/jdk8u-dev/hotspot/file/80ee2541504e/make/linux/makefiles/amd64.make#l25
>

I tend to agree with David's comment:

"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." [0]

and we've encountered the same issue in Gentoo in the past [1].

Your example seems a little disingenuous, especially given you're
proposing to remove
those -O0 examples in another bug [2]. Given that the code is
generally compiled with -O3,
the more common effect of overriding the optimisation  is going to be
to lower it.

The optimisations selected by these options are not static. They vary
from compiler to
compiler, and between versions of the same compiler. Just check the output of
gcc -Q --help=optimizers. It's perfectly possible that -O3 produces a
working build
on one compiler, but enables optimisations that causes crashes on another. Thus,
disabling the user's ability to tone down the optimisation seems wrong to me. I
wasn't aware that this had changed in 9 and, given it's barely a year
old, it may
still come as a surprise to others. I definitely don't think it should
be changed in
a four year old stable version.

The right solution here seems to me to be to add optimisations to
those areas that
lack it, in appropriate build modes. It seems likely to me that jsig
and saproc were
overlooked because of the use of separate makefiles in the old HotSpot
build more
than anything else (as seems to have been the case with execstack in 8187045).
Are they optimised in 9? Or is there any evidence of breakage caused by
using optimisation there?

[0] http://mail.openjdk.java.net/pipermail/build-dev/2018-September/023060.html
[1] https://bugs.gentoo.org/356991
[2] https://bugs.openjdk.java.net/browse/JDK-8210425
-- 
Andrew :)

Senior Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Web Site: http://fuseyism.com
Twitter: https://twitter.com/gnu_andrew_java
PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222