Hi Erik,
Please note that this 8187676 seems to be related to 8160404.
https://bugs.openjdk.java.net/browse/JDK-8160404
(RelocationHolder constructors have bugs)
As per the latest notes comments added for 8160404-jbs, I will submit
webrev/RFR soon and will request help confirm similar issues with latest
gcc7 gets solved.
Thanks,
Rahul
On Tuesday 19 September 2017 07:07 PM, Erik Helin wrote:
Hi all,
with gcc 7.1.1 from Fedora 26 on x86-64 there are warnings about the
potential usage of maybe uninitialized memory in
src/hotspot/cpu/x86/assembler_x86.cpp and in
src/hotspot/cpu/x86/interp_masm_x86.cpp.
The problems arises from the class RelocationHolder in
src/hotspot/share/code/relocInfo.hpp which has the private fields:
enum { _relocbuf_size = 5 };
void* _relocbuf[ _relocbuf_size ];
and the default constructor for RelocationHolder does not initialize the
elements of _relocbuf. I _think_ this is an optimization,
RelocationHolder is used *a lot* and setting the elements of
RelocationHolder::_relocbuf to NULL (or some other value) in the default
constructor might result in a performance penalty. Have a look in
build/linux-x86_64-normal-server-fastdebug/hotspot/variant-server/gensrc/adfiles
and you will see that RelocationHolder is used all over the place :)
AFAICS all users of RelocationHolder::_relocbuf take care to not use
uninitialized memory, which means that this warning is wrong, so I
suggest we disable the warning -Wmaybe-uninitialized for
src/hotspot/cpu/x86/assembler_x86.cpp.
The problem continues because the class Address in
src/hotspot/cpu/x86/assembler_x86.hpp has a private field,
`RelocationHolder _rspec;` and the default constructor for Address does
not initialize _rspec._relocbuf (most likely for performance reasons).
The class Address also has a default copy constructor, which will copy
all the elements of _rspec._relocbuf, which will result in a read of
uninitialized memory. However, this is a benign usage of uninitialized
memory, since we take no action based on the content of the
uninitialized memory (it is just copied byte for byte).
So, in this case too, I suggest we disable the warning -Wuninitialized
for src/hotspot/cpu/x86/assembler_x86.hpp.
What do you think?
Patch:
http://cr.openjdk.java.net/~ehelin/8187676/00/
--- old/make/hotspot/lib/JvmOverrideFiles.gmk 2017-09-19
15:11:45.036108983 +0200
+++ new/make/hotspot/lib/JvmOverrideFiles.gmk 2017-09-19
15:11:44.692107277 +0200
@@ -32,6 +32,8 @@
ifeq ($(TOOLCHAIN_TYPE), gcc)
BUILD_LIBJVM_vmStructs.cpp_CXXFLAGS := -fno-var-tracking-assignments
-O0
BUILD_LIBJVM_jvmciCompilerToVM.cpp_CXXFLAGS :=
-fno-var-tracking-assignments
+ BUILD_LIBJVM_assembler_x86.cpp_CXXFLAGS := -Wno-maybe-uninitialized
+ BUILD_LIBJVM_interp_masm_x86.cpp_CXXFLAGS := -Wno-uninitialized
endif
ifeq ($(OPENJDK_TARGET_OS), linux)
Issue:
https://bugs.openjdk.java.net/browse/JDK-8187676
Testing:
- Compiles with:
- gcc 7.1.1 and glibc 2.25 on Fedora 26
- gcc 4.9.2 and glibc 2.12 on OEL 6.4
- JPRT
Thanks,
Erik
