[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