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

Roland Westrelin roland.westrelin at oracle.com
Fri Nov 13 13:56:09 UTC 2015


> Would some one help review this patch? 

Sorry Hui, forgot about that one. That looks good to me. I will have it go through testing and if it looks good I’ll push it (I’ll maybe tweak the comments a bit).

Roland.

> 
> Regards
> Hui
> 
> On 8 November 2015 at 22:12, Hui Shi <hui.shi at linaro.org> wrote:
> Thanks Vladimir!  
> 
> Yes,  isStableEnabled and isServerWithStable variable can be deleted from test case.
> 
> New patch in  http://cr.openjdk.java.net/~hshi/8139758/webrev_v4/
> 
> Keep "othervm" in tag same with other StableTest and use @run main/othervm/bootclasspath 
> 
> Regards
> Shi Hui
> 
> On 5 November 2015 at 22:01, Vladimir Ivanov <vladimir.x.ivanov at oracle.com> wrote:
> Thanks for the test case!
> 
> You don't need TestStableMemoryBarrier, since isStableEnabled and isServerWithStable aren't used anywere.
> 
> After you eliminate it, you can use @run main/bootclasspath. For example, see [1].
> 
> Best regards,
> Vladimir Ivanov
> 
> [1] http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/file/tip/test/compiler/unsafe/UnsafeGetConstantField.java
> 
> 
> On 11/5/15 4:23 PM, Hui Shi wrote:
> 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 <mailto: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 hotspot-compiler-dev mailing list