[REDO] Elide more final field's write memory barrier with escape analysis result

Hui Shi hui.shi at linaro.org
Thu Nov 5 13:23:42 UTC 2015

Thanks Roland!

I wrote a test case and put it together with fix in
In hotspot/test/compiler/stable/TestStableMemoryBarrier.java, stable
field’s object allocation doesn’t dominate method exit. This will trigger
assertion when verify dominance. This issue doesn’t exist in current code,
can be exposed when MemBarPrecedent is added for stable field write’s
MemBarRelease node (with following patch).

--- a/src/share/vm/opto/parse3.cpp      Mon Nov 02 12:34:27 2015 +0000
+++ b/src/share/vm/opto/parse3.cpp      Wed Nov 04 15:02:31 2015 +0800
@@ -313,9 +313,8 @@
     // Preserve allocation ptr to create precedent edge to it in membar
     // generated on exit from constructor.
-    if (C->eliminate_boxing() &&
-        adr_type->isa_oopptr() &&
adr_type->is_oopptr()->is_ptr_to_boxed_value() &&
-        AllocateNode::Ideal_allocation(obj, &_gvn) != NULL) {
+    if (AllocateNode::Ideal_allocation(obj, &_gvn) != NULL) {

Run with debug build on linux amd64 platform “jtreg/bin/jtreg
hotspot/test/compiler/stable/TestStableMemoryBarrier.java “ Assertion can
be reproduced.

*** Use 167 isn't dominated by def 170 ***
# To suppress the following error report, specify this argument
# after -XX: or in .hotspotrc:  SuppressErrorAt=/loopnode.cpp:3235
# A fatal error has been detected by the Java Runtime Environment:
#  Internal Error
pid=23461, tid=23513
#  assert(!had_error) failed: bad dominance
# JRE version: OpenJDK Runtime Environment (9.0) (build
# Java VM: OpenJDK 64-Bit Server VM
(1.9.0-internal-debug-shihui_2015_10_20_07_17-b00, compiled mode, tiered,
compressed oops, g1 gc, linux-amd64)
# Core dump will be written. Default location: Core dumps may be processed
with "/usr/share/apport/apport %p %s %c %P" (or dumping to
Unsupported internal testing APIs have been used.

# An error report file with more information is saved as:
# /home/shihui/jdk9-hs-comp/src/jdk9/JTwork/scratch/hs_err_pid23461.log

Shi Hui

On 31 October 2015 at 00:04, Roland Westrelin <roland.westrelin at oracle.com>

> > webrev: http://cr.openjdk.java.net/~hshi/8139758/webrev_v2/
> Thanks for re-submitting this.
> So you’re fixing an existing bug in the process. Nice. We usually need a
> test case for every bug fix. Can you write such a test case that triggers
> that bug. test/compiler/stable has example regression test cases for
> @Stable.
> Roland.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20151105/244e428f/attachment.html>

More information about the hotspot-compiler-dev mailing list