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.
David
/Erik
David
Bug: https://bugs.openjdk.java.net/browse/JDK-8210352
webrev:
http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8210352/webrev.01/
Thanks,
Severin
