Replace MemBarRelease for final field write with MemBarStoreStore

[Hui Shi]

Could anyone help review and comments this change?  This change involves
memory barrier, escape analysis and maybe PPC.

In C2 compiler, MemBarRelease node is generated at end of method if it
writes final/stable field. Is it better to use MemBarStoreStore here?
Reasons are:
1. MemBarRelease represents loadstore + storestore barrier, it costs more
than MemBarStoreStore on RMO(Relax Memory Order) platforms like aarch64.
    For attached small case TestWriteFinal_MemoryBarrier.java, with
storestore memory barrier it is 40% faster on aarch64.
2. According to JSR133 cook book, it only requires storestore barrier. Are
there some corner cases needs loadstore barrier?
3. In C1 implementation (GraphBuilder::method_return), it only inserts
storestore barrier (lir_membar_storestore), barrier for stable field in C1
is missing, maybe we need add memory barrier in C1 too for stable field?

Browsing hotspot repository history, is this an early conservative handling
which not updated yet?
1. MemBarRelease is used for final field store since first hotspot version.
At that time, MemBarStoreStore is not defined yet.
2 .MemBarStoreStore is added later for barrier after object allocation and
array copy (
http://hg.openjdk.java.net/aarch64-port/jdk8/hotspot/rev/1dc233a8c7fe)


Only MemBarRelease created for final/stable field store can have
MemBarNode::Precedent input and optimized in Escape analysis.  Replacing
MemBarRelease with MemBarStoreStore requires combining escape analysis
optimization for both nodes.  MemBarStoreStore node's Precedent input is
always its allocation node's proj_out(AllocateNode::RawAddress) , checking
LibraryCallKit::copy_to_clone and LibraryCallKit::generate_arraycopy.
Escape analysis also assumes this.

In ConnectionGraph::optimize_ideal_graph
  while (storestore_worklist.length() != 0) {
    Node *n = storestore_worklist.pop();
    MemBarStoreStoreNode *storestore = n ->as_MemBarStoreStore();
    Node *alloc = storestore->in(MemBarNode::Precedent)->in(0);
    *assert (alloc->is_Allocate(), "storestore should point to
AllocateNode");   // assertion on expected MemBarNode::Precedent input*
    if (not_global_escape(alloc)) {
     .... replace with Op_MemBarCPUOrder node
    }
  }

This is not true for MemBar node after final fields store, whose
MemBarNode::Precedent input is initialized with _alloc_with_final. Checking
Parse::do_put_xxx
1. _alloc_with_final might not be set. For example object type is not boxed
type.
2. _alloc_with_final is set with store obj node, this usually is
CheckCastPP instead of allocation->proj_out(AllocateNode::RawAddress). if
not align with MemBarStoreStore 's assumption, this will trigger assertion
in above ConnectionGraph::optimize_ideal_graph code.

In attached patch, changes include:
1. Replace MemBarRelease with MemBarStoreStore after final field/stable
store.  (src/share/vm/opto/parse1.cpp)
2. New MemBarStoreStore node's Precedent input is initialized with
allocation node’s proj_out(AllocateNode::RawAddress).
(src/share/vm/opto/parse3.cpp)
3. In escape analysis, only process MemStoreStore with Precedent node.
(src/share/vm/opto/escape.cpp)
4. Remove code handling MemBarRelease with Precedent input.
(src/share/vm/opto/escape.cpp, src/share/vm/opto/memnode.cpp and
src/share/vm/opto/compile.cpp)

Another uncertainty is if this works for PPC, PPC also inserts
MemBarRelease for volatile write in initializer. Is MemBar here also
ordering volatile write and escape shared reference store and is
MemBarStoreStore also enough? Could PPC people (Goetz) help comments?

Andrew Dinn, would you please confirm if this change will not affect your
MembarRelase pattern optimization in aarch64 backend?  In my understanding,
your optimization targets Membars for volatile field reference.

Regards
Shi Hui
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20150902/ec74ea03/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: final_store_memory_barrier.patch
Type: application/octet-stream
Size: 3842 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20150902/ec74ea03/final_store_memory_barrier.patch>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: TestWriteFinal_MemoryBarrier.java
Type: application/octet-stream
Size: 884 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20150902/ec74ea03/TestWriteFinal_MemoryBarrier.java>