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

[Vladimir Ivanov]

Sorry, Hui. I planned to write you, but bogged down in other activities.

I suggest to do some additional cleanups in the test.

After you switch to bootclasspath these lines shouldn't be needed:
   31  * @run main ClassFileInstaller
   32  *           java/lang/invoke/TestStableMemoryBarrier
   33  *           java/lang/invoke/TestStableMemoryBarrier$NotDominate

Also, othervm is redundant for bootclasspath:
   35  * @run main/othervm/bootclasspath -Xcomp 
-XX:CompileOnly=::testCompile
   36  *                   java.lang.invoke.TestStableMemoryBarrier

Best regards,
Vladimir Ivanov

On 11/13/15 4:53 PM, Hui Shi wrote:
> Would some one help review this patch?
>
> Regards
> Hui
>
> On 8 November 2015 at 22:12, Hui Shi <hui.shi at linaro.org
> <mailto: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 <mailto: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>
>             <mailto: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.
>
>
>
>