[aarch64-port-dev ] [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
http://cr.openjdk.java.net/~hshi/8139758/webrev_v3/
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) {
       set_alloc_with_final(obj);
     }
   }

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
(/home/shihui/jdk9-hs-comp/src/jdk9/hotspot/src/share/vm/opto/loopnode.cpp:3235),
pid=23461, tid=23513
#  assert(!had_error) failed: bad dominance
#
# JRE version: OpenJDK Runtime Environment (9.0) (build
1.9.0-internal-debug-shihui_2015_10_20_07_17-b00)
# 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
/home/shihui/jdk9-hs-comp/src/jdk9/JTwork/scratch/core.23461)
#
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


Regards
Shi Hui

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

> > 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.
>
>


More information about the aarch64-port-dev mailing list