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

Hui Shi hui.shi at linaro.org
Fri Nov 13 15:30:54 UTC 2015


Thanks Vladimir & Roland!

Test is cleaned up and new patch in
http://cr.openjdk.java.net/~hshi/8139758/webrev_v5/

BTW, What is the advantage to write test in "@run main/bootclasspath"
form?  There still some tests written as "@run
main/othervm -Xbootclasspath/a:."  under hotspot/test.

Regards
Hui

On 13 November 2015 at 22:22, Vladimir Ivanov <vladimir.x.ivanov at oracle.com>
wrote:

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


More information about the aarch64-port-dev mailing list