RFR(S): 8212673: jtreg/applications/runthese/RunThese30M.java fails in C2 with "assert(!had_error) failed: bad dominance"

[Per Liden]

After JDK-8213487 has been pushed I rebased and re-ran tier1-3 with 
Rolands patch, and still see a number of failures where 
compiler/gcbarriers/EqvUncastStepOverBarrier.java throws 
"java.lang.RuntimeException: Method compilation failed".

Reproducible with:

$ make run-test TEST=compiler/gcbarriers/EqvUncastStepOverBarrier.java 
JTREG="VM_OPTIONS=-XX:CompileThreshold=100"

and:

$ make run-test TEST=compiler/gcbarriers/EqvUncastStepOverBarrier.java 
JTREG="VM_OPTIONS=-XX:+UnlockExperimentalVMOptions -XX:+EnableJVMCI 
-XX:+TieredCompilation -XX:+UseJVMCICompiler -Djvmci.Compiler=graal"

/Per

On 11/7/18 5:21 PM, Tobias Hartmann wrote:
> It's https://bugs.openjdk.java.net/browse/JDK-8213487
> 
> Best regards,
> Tobias
> 
> On 07.11.18 17:10, Per Liden wrote:
>> Ah, I think you're right. Something that just want into jdk/jdk (JDK-8213414 or JDK-8213347) seem to
>> have caused this.
>>
>> Thanks,
>> Per
>>
>> On 11/07/2018 05:02 PM, Tobias Hartmann wrote:
>>> I think these are unrelated failures (probably due to JDK-8213414), I also see them in our CI.
>>>
>>> Best regards,
>>> Tobias
>>>
>>> On 07.11.18 16:52, Per Liden wrote:
>>>> Hi Roland,
>>>>
>>>> On 10/24/2018 11:14 AM, Roland Westrelin wrote:
>>>>>
>>>>> http://cr.openjdk.java.net/~roland/8212673/webrev.00/
>>>>
>>>> Heads up. I grabbed this patch and ran it through tier1-3 on linux-x64 and got 125 test failures
>>>> (all of them in tier3).
>>>>
>>>> Here are a handful of the tests that failed:
>>>>
>>>> compiler/types/TestMeetIncompatibleInterfaceArrays.java
>>>> compiler/types/TestMeetIncompatibleInterfaceArrays.java
>>>> runtime/verifier/PrimIntArray.java
>>>> runtime/verifier/popTopTests/PopDupTop.java
>>>> runtime/stackMapCheck/StackMapCheck.java
>>>> runtime/verifier/PrimIntArray.java
>>>> runtime/verifier/popTopTests/PopDupTop.java
>>>> runtime/stackMapCheck/StackMapCheck.java
>>>> compiler/types/TestMeetIncompatibleInterfaceArrays.java
>>>> compiler/types/TestMeetIncompatibleInterfaceArrays.java
>>>> runtime/logging/ClassInitializationTest.java
>>>> runtime/handlerInTry/LoadHandlerInTry.java
>>>> compiler/types/TestMeetIncompatibleInterfaceArrays.java
>>>> ...
>>>>
>>>> All these failed on the same assert. Like this:
>>>>
>>>> # To suppress the following error report, specify this argument
>>>> # after -XX: or in .hotspotrc:  SuppressErrorAt=/allocation.cpp:218
>>>> #
>>>> # A fatal error has been detected by the Java Runtime Environment:
>>>> #
>>>> #  Internal Error
>>>> (/scratch/opt/mach5/mesos/work_dir/slaves/2dd962d0-8988-479b-a804-57ab764ada59-S1324/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/73c9153d-50f8-4618-9677-367c32a5c956/runs/e70e9adb-5acd-44a1-89da-0244974d5dd2/workspace/open/src/hotspot/share/memory/allocation.cpp:218),
>>>>
>>>> pid=22982, tid=22997
>>>> #  assert(~(_allocation_t[0] | allocation_mask) != (uintptr_t)this || !is_type_set()) failed:
>>>> embedded or stack only, this(0x00007f6ee803d870) type 1 a[0]=(0xffff809117fc278e)
>>>> a[1]=(0x00007f6ee803d881)
>>>> #
>>>> # JRE version: Java(TM) SE Runtime Environment (12.0) (fastdebug build
>>>> 12-internal+0-2018-11-07-1353526.per.liden.zgc)
>>>> # Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug
>>>> 12-internal+0-2018-11-07-1353526.per.liden.zgc, mixed mode, sharing, tiered, compressed oops,
>>>> parallel gc, linux-amd64)
>>>> # Core dump will be written. Default location:
>>>> /scratch/opt/mach5/mesos/work_dir/slaves/2dd962d0-8988-479b-a804-57ab764ada59-S1300/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/9506a9ad-7631-4642-aec7-8cb47a50b26b/runs/45c78358-d71d-48fd-a0dc-f901e68def30/testOutput/test-support/jtreg_open_test_hotspot_jtreg_hotspot_runtime/scratch/1/core.22982
>>>>
>>>>
>>>> #
>>>> # An error report file with more information is saved as:
>>>> #
>>>> /scratch/opt/mach5/mesos/work_dir/slaves/2dd962d0-8988-479b-a804-57ab764ada59-S1300/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/9506a9ad-7631-4642-aec7-8cb47a50b26b/runs/45c78358-d71d-48fd-a0dc-f901e68def30/testOutput/test-support/jtreg_open_test_hotspot_jtreg_hotspot_runtime/scratch/1/hs_err_pid22982.log
>>>>
>>>>
>>>> #
>>>> # If you would like to submit a bug report, please visit:
>>>> #   http://bugreport.java.com/bugreport/crash.jsp
>>>> #
>>>>
>>>>
>>>> It doesn't seem to matter which GC is used. I don't have time to dig deeper right now, but I'll
>>>> double check and re-run some of these later tonight, just to make sure I didn't mess something up on
>>>> my side. Maybe you can see if any of these failures are reproducible on your side.
>>>>
>>>> cheers,
>>>> Per
>>>>
>>>>
>>>>>
>>>>> In PhiNode::Ideal():
>>>>>
>>>>>      Node* uin = unique_input(phase, false);
>>>>>      if (uin == NULL && can_reshape) {
>>>>>        uncasted = true;
>>>>>        uin = unique_input(phase, true);
>>>>>      }
>>>>>
>>>>> can find a unique input by looking trough cast. But code below:
>>>>>
>>>>>          if ((is_loop && !uin->eqv_uncast(in(LoopNode::EntryControl))) ||
>>>>>              (!is_loop && is_unsafe_data_reference(uin))) {
>>>>>
>>>>> eqv_uncast can fail because it looks through casts and load barriers if
>>>>> the unique input is a load barrier. This then causes a valid input to a
>>>>> Phi to be set to top.
>>>>>
>>>>> I propose to backout JDK-8212603 and add calls to step_over_gc_barrier()
>>>>> to locking optimization code only instead (which was the motivation for
>>>>> JDK-8212603).
>>>>>
>>>>> Roland.
>>>>>