RFR: 8224162: assert(profile.count() == 0) failed: sanity in InlineTree::is_not_reached
Jie Fu
fujie at loongson.cn
Mon May 20 13:21:29 UTC 2019
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