RFR: 8224162: assert(profile.count() == 0) failed: sanity in InlineTree::is_not_reached

Vladimir Ivanov vladimir.x.ivanov at oracle.com
Tue May 21 14:30:45 UTC 2019 

> The updated webrev: http://cr.openjdk.java.net/~jiefu/8224162/webrev.02/
> 
> The call site count is < 0 for a typecheck profile[1][2].
> Please review it and give me some advice.

It doesn't explain the failure since the assert is hit while parsing 
invoke* bytecode while type check failures are recorded for checkcast, 
aastore, and instanceof. Am I missing something important here?

Best regards,
Vladimir Ivanov

> On 2019年05月20日 23:36, Vladimir Kozlov wrote:
>> Hi Jie
>>
>> Please, send updated webrev. It is confusing to which changes this 
>> should be applied.
>>
>> Thanks
>> Vladimir
>>
>>> On May 20, 2019, at 6:21 AM, Jie Fu <fujie at loongson.cn> wrote:
>>>
>>> Hi all,
>>>
>>> A refinement since the profile.count() won't change during compilation.
>>> ----------------------------------------------------
>>> diff -r 13507abf416c src/hotspot/share/opto/bytecodeInfo.cpp
>>> --- a/src/hotspot/share/opto/bytecodeInfo.cpp   Sat May 18 15:42:21 
>>> 2019 +0900
>>> +++ b/src/hotspot/share/opto/bytecodeInfo.cpp   Mon May 20 21:13:13 
>>> 2019 +0800
>>> @@ -334,8 +334,8 @@
>>>    if (caller_method->is_not_reached(caller_bci)) {
>>>      return true; // call site not resolved
>>>    }
>>> -  if (profile.count() == -1) {
>>> -    return false; // immature profile; optimistically treat as reached
>>> +  if (profile.count() <= -1) {
>>> +    return false; // immature or typecheck profile; optimistically 
>>> treat as reached
>>>    }
>>>    assert(profile.count() == 0, "sanity");
>>>
>>> ----------------------------------------------------
>>> Please review this one and give me some advice.
>>>
>>> Thanks.
>>> Best regards,
>>> Jie
>>>
>>>> On 2019年05月20日 18:01, Jie Fu wrote:
>>>> Hi all,
>>>>
>>>> Updated: http://cr.openjdk.java.net/~jiefu/8224162/webrev.01/
>>>>
>>>> In my previous patch, I had lost the case of typecheck profile[1].
>>>> Please review and give me some advice.
>>>>
>>>> Thanks a lot.
>>>> Best regards,
>>>> Jie
>>>>
>>>> [1] 
>>>> https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2019-May/033797.html 
>>>>
>>>>
>>>>> On 2019/5/20 下午4:12, Leonid Mesnik wrote:
>>>>> The failure is still reproduced with patch. I attached full hs_err 
>>>>> to the bug.
>>>>>
>>>>> hs_err
>>>>> #
>>>>> # A fatal error has been detected by the Java Runtime Environment:
>>>>> #
>>>>> #  Internal Error 
>>>>> (open/src/hotspot/share/opto/bytecodeInfo.cpp:343), pid=3096, tid=3128
>>>>> #  assert(profile_count == 0) failed: sanity
>>>>> #
>>>>> # JRE version: Java(TM) SE Runtime Environment (13.0) (fastdebug 
>>>>> build 13-internal+0-2019-05-18-0457052.lmesnik.null)
>>>>> # Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 
>>>>> 13-internal+0-2019-05-18-0457052.lmesnik.null, mixed mode, sharing, 
>>>>> tiered, compressed oops, g1 gc, linux-amd64)
>>>>> # Problematic frame:
>>>>> # V  [libjvm.so+0x6cbf6c]  InlineTree::is_not_reached(ciMethod*, 
>>>>> ciMethod*, int, ciCallProfile&) [clone .constprop.153]+0xbc
>>>>> #
>>>>> # Core dump will be written. Default location: Core dumps may be 
>>>>> processed with "/usr/libexec/abrt-hook-ccpp %s %c %p %u %g %t e %P 
>>>>> %I %h" (or dumping to 
>>>>> /scratch/lmesnik/ws/ks-apps/build/linux-x64/test-support/jtreg_closed_test_hotspot_jtreg_applications_kitchensink_Kit\ 
>>>>>
>>>>> chensink14D_java/scratch/0/core.3096)
>>>>> #
>>>>> # If you would like to submit a bug report, please visit:
>>>>> #   http://bugreport.java.com/bugreport/crash.jsp
>>>>> #
>>>>>
>>>>> ---------------  S U M M A R Y ------------
>>>>>
>>>>> Command Line: -Xbootclasspath/a:. -XX:+UnlockDiagnosticVMOptions 
>>>>> -XX:+WhiteBoxAPI -XX:MaxRAMPercentage=12 -XX:+DeoptimizeALot 
>>>>> -XX:MaxRAMPercentage=50 -XX:+HeapDumpOnOutOfMemoryError 
>>>>> -XX:+CrashOnOutOfMemoryError -Djava.net.preferIPv6Addresses=false 
>>>>> -XX:+DisplayVMOutputToS\
>>>>> tderr -XX:+UsePerfData 
>>>>> -Xlog:gc*,gc+heap=debug:gc.log:uptime,timemillis,level,tags 
>>>>> -XX:+DisableExplicitGC -XX:+StartAttachListener 
>>>>> -XX:NativeMemoryTracking=detail -XX:+FlightRecorder 
>>>>> --add-exports=java.base/java.lang=ALL-UNNAMED 
>>>>> --add-opens=java.base/java.lang=ALL-UNNAME\
>>>>> D 
>>>>> --add-exports=java.xml/com.sun.org.apache.xerces.internal.parsers=ALL-UNNAMED 
>>>>> --add-exports=java.xml/com.sun.org.apache.xerces.internal.util=ALL-UNNAMED 
>>>>> -Djava.io.tmpdir=/scratch/lmesnik/ws/ks-apps/build/linux-x64/test-support/jtreg_closed_test_hotspot_jtreg_applicatio\ 
>>>>>
>>>>> ns_kitchensink_Kitchensink14D_java/scratch/0/java.io.tmpdir 
>>>>> -Duser.home=/scratch/lmesnik/ws/ks-apps/build/linux-x64/test-support/jtreg_closed_test_hotspot_jtreg_applications_kitchensink_Kitchensink14D_java/scratch/0/user.home 
>>>>> -agentpath:/scratch/lmesnik/ws/ks-apps/build/\
>>>>> linux-x64/images/test/hotspot/jtreg/native/libJvmtiStressModule.so 
>>>>> applications.kitchensink.process.stress.Main 
>>>>> /scratch/lmesnik/ws/ks-apps/build/linux-x64/test-support/jtreg_closed_test_hotspot_jtreg_applications_kitchensink_Kitchensink14D_java/scratch/0/kitchensink.fin\ 
>>>>>
>>>>> al.properties
>>>>>
>>>>> Host: Intel(R) Xeon(R) CPU E5-2690 0 @ 2.90GHz, 4 cores, 14G, 
>>>>> Oracle Linux Server release 7.5
>>>>> Time: Sun May 19 05:15:11 2019 PDT elapsed time: 111312 seconds (1d 
>>>>> 6h 55m 12s)
>>>>>
>>>>> ---------------  T H R E A D  ---------------
>>>>>
>>>>> Current thread (0x00002ae4e83bc000):  JavaThread "C2 
>>>>> CompilerThread0" daemon [_thread_in_native, id=3128, 
>>>>> stack(0x00002ae522de2000,0x00002ae522ee3000)]
>>>>>
>>>>>
>>>>> Current CompileTask:
>>>>> C2:111312036 146944       4 
>>>>> spec.benchmarks.derby.DerbyHarness$Client::handleResultSet (77 bytes)
>>>>>
>>>>> Stack: [0x00002ae522de2000,0x00002ae522ee3000], 
>>>>> sp=0x00002ae522edf650,  free space=1013k
>>>>> Native frames: (J=compiled Java code, A=aot compiled Java code, 
>>>>> j=interpreted, Vv=VM code, C=native code)
>>>>> V  [libjvm.so+0x6cbf6c]  InlineTree::is_not_reached(ciMethod*, 
>>>>> ciMethod*, int, ciCallProfile&) [clone .constprop.153]+0xbc
>>>>> V  [libjvm.so+0x6d12e0]  InlineTree::ok_to_inline(ciMethod*, 
>>>>> JVMState*, ciCallProfile&, WarmCallInfo*, bool&)+0x1950
>>>>> V  [libjvm.so+0xb6e075]  Compile::call_generator(ciMethod*, int, 
>>>>> bool, JVMState*, bool, float, ciKlass*, bool, bool)+0x905
>>>>> V  [libjvm.so+0xb6f6b9]  Parse::do_call()+0x469
>>>>> V  [libjvm.so+0x1441b70]  Parse::do_one_bytecode()+0xff0
>>>>> V  [libjvm.so+0x1432520]  Parse::do_one_block()+0x650
>>>>> V  [libjvm.so+0x1432a23]  Parse::do_all_blocks()+0x113
>>>>> V  [libjvm.so+0x14348e4]  Parse::Parse(JVMState*, ciMethod*, 
>>>>> float)+0xc54
>>>>> V  [libjvm.so+0x803d0c] ParseGenerator::generate(JVMState*)+0x18c
>>>>> V  [libjvm.so+0x9c08b4]  Compile::Compile(ciEnv*, C2Compiler*, 
>>>>> ciMethod*, int, bool, bool, bool, DirectiveSet*)+0xe74
>>>>> V  [libjvm.so+0x801d9d]  C2Compiler::compile_method(ciEnv*, 
>>>>> ciMethod*, int, DirectiveSet*)+0x10d
>>>>> V  [libjvm.so+0x9cd17d] 
>>>>> CompileBroker::invoke_compiler_on_method(CompileTask*)+0x46d
>>>>> V  [libjvm.so+0x9ce1d8] CompileBroker::compiler_thread_loop()+0x418
>>>>> V  [libjvm.so+0x16c0baa]  JavaThread::thread_main_inner()+0x26a
>>>>> V  [libjvm.so+0x16c9267]  JavaThread::run()+0x227
>>>>> V  [libjvm.so+0x16c62f6]  Thread::call_run()+0xf6
>>>>> V  [libjvm.so+0x13e0d5e]  thread_native_entry(Thread*)+0x10e
>>>>>
>>>>> Leonid
>>>>>
>>>>>> On May 18, 2019, at 5:40 PM, Jie Fu <fujie at loongson.cn> wrote:
>>>>>>
>>>>>> Thanks Vladimir Ivanov and Vladimir Kozlov for your review.
>>>>>> Let's wait for Leonid's test result.
>>>>>>
>>>>>> Thanks.
>>>>>> Best regards,
>>>>>> Jie
>>>>>>
>>>>>>> On 2019年05月19日 00:15, Vladimir Kozlov wrote:
>>>>>>> Hi Jie,
>>>>>>>
>>>>>>> So the counter was incremented while this code is executed. And 
>>>>>>> you fixed it by caching initial value.
>>>>>>> Looks good.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Vladimir
>>>>>>>
>>>>>>>> On 5/17/19 6:37 PM, Jie Fu wrote:
>>>>>>>> Hi all,
>>>>>>>>
>>>>>>>> JBS:    https://bugs.openjdk.java.net/browse/JDK-8224162
>>>>>>>> Webrev: http://cr.openjdk.java.net/~jiefu/8224162/webrev.00/
>>>>>>>>
>>>>>>>> I'm sorry to introduce this assertion failure.
>>>>>>>> Please review the suggested fix and give me some advice.
>>>>>>>>
>>>>>>>> Leonid, could you please help to test the patch?
>>>>>>>> I don't have the reproducer you mentioned in the JBS.
>>>>>>>>
>>>>>>>> Thanks a lot.
>>>>>>>> Best regards,
>>>>>>>> Jie
>>>>>>>>
>>>>>>>>
>>>
> 
>

More information about the hotspot-compiler-dev mailing list