Hotspot changes look good.
Vladimir
On 5/3/14 8:24 PM, Mike Duigou wrote:
Hello;
Finally getting back to this issue I have done some cleanup and adjusted the
hotspot gcc.make files to use VARIANT rather than DEBUG_LEVEL.
This version also add support for the "-fsanitize=undefined" undefined
behaviour warnings feature when it is available (Clang and GCC 4.9). The code to emit
the option has been added for Clang but I haven't yet added test for the option's
availability under Clang so currently it will be enabled only for GCC.
https://bugs.openjdk.java.net/browse/JDK-8032045
http://cr.openjdk.java.net/~mduigou/JDK-8032045/6/webrev/
Mike
On Mar 11 2014, at 05:47 , Magnus Ihse Bursie <magnus.ihse.bur...@oracle.com>
wrote:
On 2014-03-11 00:49, Mike Duigou wrote:
I have updated the patch to respond to Magnus's feedback and to accommodate
intervening changes to the configure and hotspot make files.
https://bugs.openjdk.java.net/browse/JDK-8032045
http://cr.openjdk.java.net/~mduigou/JDK-8032045/3/webrev/
This version is, hopefully, almost ready to be pushed.
I have only glanced at the hotspot build changes and can't really say anything
about them. The hotspot team still owns these; I'm cc:ing them now.
The top-level build changes looks fine. Thank you Mike for cleaning things up!
/Magnus
Mike
On Feb 20 2014, at 15:43 , Mike Duigou <mike.dui...@oracle.com> wrote:
Hello all;
This issue is a followon to JDK-8030350
(https://bugs.openjdk.java.net/browse/JDK-8030350) which enhanced the compiler
warnings used for compiling native code. The proposed changes principally
impact the Linux platform.
While 8030350 was focused on compiler warnings which did not impact code
generation, this changeset will, for some configurations, change the native
code generated and likely change performance. These proposed option changes
prevent specific types of relocation table, stack and heap memory corruption in
native code. Preventing these types of memory corruption may be useful for
finding certain kinds of bugs though and do provide some minimal additional
protections against malicious attacks. They aren't, by any means, a substitute
for following appropriate secure coding guidelines.
The rationale behind the implementation is as follows. For release builds
during the initial phase of JDK 9 I would like to enable only compile time
checks. This ends up being similar to the warnings in JDK-8030350. These
options have no runtime impact on footprint or performance and very minimal
additional compile time cost while providing value. **Release builds are not
expected to see any performance or footprint change as a result of this
changeset**
For fast debug builds we can enable linker protections (relro) and static
compile time bounds checks (FORTIFY_SOURCE=1). FORTIFY_SOURCE=1 might be moved
to the production builds as well because it has no runtime cost or executable
size cost.
For slow debug builds we can enable full linker protection (at a potential cost
in startup time), runtime bounds checks and stack protection (FORTIFY_SOURCE=2
-fprotect-stack-all). We will likely enable -fprotect-stack-strong when
available in GCC 4.9
The basis for enabling the additional protections in debug builds is that it
will help us find bugs in our native code and we aren't as concerned in debug
builds with footprint and performance. Since many developers already do their
personal builds in fastdebug or slowdebug mode for testing this will provide
good opportunity to shake out any problems with the options while not impacting
release builds. Should we find that any of the options provide significant
value for their cost we can move them to fastdebug or release. If any of the
options prove too costly they can be demoted or removed entirely.
https://bugs.openjdk.java.net/browse/JDK-8032045
http://cr.openjdk.java.net/~mduigou/JDK-8032045/2/webrev/
Additional to enabling the various compiler options I attempted to rationalize some of
the skew between the various hotspot/make/{platform}/makefiles/gcc.make files while
avoiding changing existing behaviour. I have also introduced the new -Og "optimize
for debugging" option and there are now an explicit C{XX}_O_FLAG_DEBUG definitions
to complement the C{XX}_O_FLAG_{DEBUG|NORM|HI|HIGHEST|NONE} optimization options.
Thanks,
Mike
