[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 13:53:11 UTC 2015


Would some one help review this patch?

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 aarch64-port-dev mailing list