RFR: 8177346: hotspot change for 8176513 breaks jdk9 build on Ubuntu 16.04

Phil Race philip.race at oracle.com
Tue Mar 21 19:40:04 UTC 2017

Please review a small JDK 9 build fix for a build failure due to

hotspot/src/share/vm/opto/library_call.cpp:2578:3: error: ‘need_mem_bar’ 
may be used uninitialized in this function [-Werror=maybe-uninitialized]
    if (need_mem_bar) insert_mem_bar(Op_MemBarCPUOrder);


I can't explain why GCC 5.4 woke up and decided to start reporting this 
warning when
nothing logically changed that would trigger it. However I think it 
should already have
been triggered -  it is clear to me that the compiler has a point.

The fix is simple and provided in-line below :-

hg diff src/share/vm/opto/library_call.cpp
diff --git a/src/share/vm/opto/library_call.cpp 
--- a/src/share/vm/opto/library_call.cpp
+++ b/src/share/vm/opto/library_call.cpp
@@ -2372,7 +2372,7 @@
    // the barriers get omitted and the unsafe reference begins to "pollute"
    // the alias analysis of the rest of the graph, either 
    // or Compile::must_alias will throw a diagnostic assert.)
-  bool need_mem_bar;
+  bool need_mem_bar = false;
    switch (kind) {
        case Relaxed:
            need_mem_bar = mismatched && !adr_type->isa_aryptr();


In fact this initialisation pattern is already used in other nearly 
identical cases in
the same function.
eg this one about 20 lines before my update
   bool mismatched = false;

and this one about 20 lines after ..
   bool requires_atomic_access = false;

So there is ample precedent.

I will get the appropriate RDP2 approvals to push once code review is 
I also anticipate that by the time this happens I will need to push it to
as per the email here :

Let me know if you think otherwise.

JPRT is being used to build/test the fix.


More information about the hotspot-runtime-dev mailing list