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

Hui Shi hui.shi at linaro.org
Sat Nov 14 08:17:32 UTC 2015


Thanks!

Regards
Hui

On 14 November 2015 at 04:37, Vladimir Ivanov <vladimir.x.ivanov at oracle.com>
wrote:

>
>
> On 11/13/15 6:30 PM, Hui Shi wrote:
>
>> Thanks Vladimir & Roland!
>>
>> Test is cleaned up and new patch in
>> http://cr.openjdk.java.net/~hshi/8139758/webrev_v5/
>>
> Looks good.
>
> I think "@build TestStableMemoryBarrier" is redundant (sorry for not
> noticing that before), but no need to send new webrev for that.
>
> BTW, What is the advantage to write test in "@runmain/bootclasspath"
>> form?  There still some tests written as "@run
>> main/othervm -Xbootclasspath/a:."  under hotspot/test.
>>
> As I remember, @run bootclasspath works only if the test resides in a
> single source file. If there are multiple Java sources involved, you have
> to use @build + ClassFileInstall + @run /othervm -Xbootclasspath/a.
>
> Best regards,
> Vladimir Ivanov
>
>
>> Regards
>> Hui
>>
>> On 13 November 2015 at 22:22, Vladimir Ivanov
>> <vladimir.x.ivanov at oracle.com <mailto: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>
>>         <mailto: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>
>>         <mailto: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>>
>>                      <mailto: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