RFR: 8333098: ubsan: bytecodeInfo.cpp:318:59: runtime error: division by zero

[Igor Veresov]

On Fri, 16 Aug 2024 19:44:58 GMT, Dean Long <dlong at openjdk.org> wrote:

>> When running test
>> compiler/classUnloading/methodUnloading/TestOverloadCompileQueues.java
>> with ubsan enabled binaries we run into the issue reported below.
>> Reason seems to be that we divide by zero in the code in some special cases (we should instead check for `CompilationPolicy::min_invocations() == 0 `and handle it separately).
>> 
>> /jdk/src/hotspot/share/opto/bytecodeInfo.cpp:318:59: runtime error: division by zero
>>     #0 0x7f5145c0dda2 in InlineTree::should_not_inline(ciMethod*, ciMethod*, int, bool&, ciCallProfile&) src/hotspot/share/opto/bytecodeInfo.cpp:318
>>     #1 0x7f51466366d7 in InlineTree::try_to_inline(ciMethod*, ciMethod*, int, JVMState*, ciCallProfile&, bool&) src/hotspot/share/opto/bytecodeInfo.cpp:382
>>     #2 0x7f514663d36b in InlineTree::ok_to_inline(ciMethod*, JVMState*, ciCallProfile&, bool&) src/hotspot/share/opto/bytecodeInfo.cpp:596
>>     #3 0x7f51470dffd6 in Compile::call_generator(ciMethod*, int, bool, JVMState*, bool, float, ciKlass*, bool) src/hotspot/share/opto/doCall.cpp:189
>>     #4 0x7f51470e18ab in Parse::do_call() src/hotspot/share/opto/doCall.cpp:641
>>     #5 0x7f514887dbf1 in Parse::do_one_block() src/hotspot/share/opto/parse1.cpp:1607
>>     #6 0x7f514887fefa in Parse::do_all_blocks() src/hotspot/share/opto/parse1.cpp:724
>>     #7 0x7f514888d4da in Parse::Parse(JVMState*, ciMethod*, float) src/hotspot/share/opto/parse1.cpp:628
>>     #8 0x7f51469d8418 in ParseGenerator::generate(JVMState*) src/hotspot/share/opto/callGenerator.cpp:99
>>     #9 0x7f5146d99cff in Compile::Compile(ciEnv*, ciMethod*, int, Options, DirectiveSet*) src/hotspot/share/opto/compile.cpp:793
>>     #10 0x7f51469d5ebf in C2Compiler::compile_method(ciEnv*, ciMethod*, int, bool, DirectiveSet*) src/hotspot/share/opto/c2compiler.cpp:142
>>     #11 0x7f5146db0274 in CompileBroker::invoke_compiler_on_method(CompileTask*) src/hotspot/share/compiler/compileBroker.cpp:2303
>>     #12 0x7f5146db2826 in CompileBroker::compiler_thread_loop() src/hotspot/share/compiler/compileBroker.cpp:1961
>>     #13 0x7f51478d475a in JavaThread::thread_main_inner() src/hotspot/share/runtime/javaThread.cpp:759
>>     #14 0x7f51491620ea in Thread::call_run() src/hotspot/share/runtime/thread.cpp:225
>>     #15 0x7f51487ac201 in thread_native_entry src/hotspot/os/linux/os_linux.cpp:846
>>     #16 0x7f514e5cf6e9 in start_thread (/lib64/libpthread.so.0+0xa6e9) (BuildId: 2f8d3c2d0f4d7888c2598d2ff6356537f5708a73)
>>     #17 0x7f514db1550e in clone (/lib64/libc.so.6+0x11850e) (BuildId: ...
>
> src/hotspot/share/opto/bytecodeInfo.cpp line 321:
> 
>> 319:       int cp_min_inv = CompilationPolicy::min_invocations();
>> 320:       if (cp_min_inv == 0) {
>> 321:         min_freq = MinInlineFrequencyRatio;
> 
> Doesn't this need to be 1.0 or infinity to preserve the existing behavior?
> However, I'm not convinced the existing behavior is correct.  If min_invocations decreases, shouldn't that make it easier to inline, not harder?  @veresov, do you agree?

I think the existing behavior is correct - the goal is to compute a minimum call freq that is considered for inlining. `1.0/min_invocations()` means call site was reached at least once before the method was submitted for a C2 compile. 

The question is what should we do if min_invocations() is 0. That basically means that there was no profiling. I would probably just return false in that case, which would mean "we can't really say that's low frequency, because we don't have data". It's a meaningless mode of operation regardless though...

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20615#discussion_r1720334554