JDK-8353815 : [ubsan] compilationPolicy.cpp: division by zero related to tiered compilation flags
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 17,21,25
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2025-04-07
  • Updated: 2025-06-24
  • Resolved: 2025-06-24
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 26
26 masterFixed
Related Reports
Blocks :  
Causes :  
Description
When running with ubsan-enabled binaries, the hs jtreg tests
runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java#id8  (-XX:Tier3LoadFeedback=0)
runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java#id9   (sets -XX:Tier4LoadFeedback=0)

show a division by zero in the following code; this seems to be related to the feedback_k  factor 0 set by Tier3LoadFeedback/Tier4LoadFeedback  ;

double CompilationPolicy::threshold_scale(CompLevel level, int feedback_k) {
  int comp_count = compiler_count(level);
  if (comp_count > 0) {
    double queue_size = CompileBroker::queue_size(level);
    double k = (double)queue_size / ((double)feedback_k * (double)comp_count) + 1;   // <----- division by zero

Message is :

TEST FAILED: Error processing option Tier3LoadFeedback with valid value '-server -XX:+UseG1GC -XX:Tier3LoadFeedback=0'! JVM exited with unexpected error code = 134 [0x86]
stdout content[]
stderr content[/priv/jenkins/client-home/workspace/openjdk-jdk-weekly-macos_aarch64-opt/jdk/src/hotspot/share/compiler/compilationPolicy.cpp:308:35: runtime error: division by zero
    #0 0x1065c1990 in CompilationPolicy::threshold_scale(CompLevel, int) compilationPolicy.cpp:308
    #1 0x1065c54ec in LoopPredicate::apply(methodHandle const&, CompLevel, int, int) compilationPolicy.cpp
    #2 0x1065c47a4 in CompLevel CompilationPolicy::common<LoopPredicate>(methodHandle const&, CompLevel, bool) compilationPolicy.cpp:1042
    #3 0x1065c4584 in CompilationPolicy::call_event(methodHandle const&, CompLevel, Thread*) compilationPolicy.cpp:1110
    #4 0x1065c3324 in CompilationPolicy::method_invocation_event(methodHandle const&, methodHandle const&, CompLevel, nmethod*, JavaThread*) compilationPolicy.cpp:1148
    #5 0x1065c3100 in CompilationPolicy::event(methodHandle const&, methodHandle const&, int, int, CompLevel, nmethod*, JavaThread*) compilationPolicy.cpp:736
    #6 0x106bba260 in InterpreterRuntime::frequency_counter_overflow_inner(JavaThread*, unsigned char*) interpreterRuntime.cpp:1074
    #7 0x106bb9fdc in InterpreterRuntime::frequency_counter_overflow(JavaThread*, unsigned char*) interpreterRuntime.cpp:1023
    #8 0x1396038c0  (<unknown module>)
    #9 0x13960090c  (<unknown module>)
    #10 0x13960090c  (<unknown module>)
    #11 0x13960090c  (<unknown module>)
    #12 0x13960090c  (<unknown module>)
    #13 0x13960090c  (<unknown module>)
    #14 0x13960090c  (<unknown module>)
    #15 0x13960090c  (<unknown module>)
    #16 0x13960081c  (<unknown module>)
    #17 0x13960081c  (<unknown module>)
    #18 0x13960081c  (<unknown module>)
    #19 0x1395fc150  (<unknown module>)
    #20 0x106bcc724 in JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*) javaCalls.cpp:415
    #21 0x106bcbaac in JavaCalls::call_static(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, JavaThread*) javaCalls.cpp:250
    #22 0x106bcbb90 in JavaCalls::call_static(JavaValue*, Klass*, Symbol*, Symbol*, JavaThread*) javaCalls.cpp:256
    #23 0x107444030 in call_initPhase1(JavaThread*) threads.cpp:298
    #24 0x107443424 in Threads::initialize_java_lang_classes(JavaThread*, JavaThread*) threads.cpp:382
    #25 0x107444ec8 in Threads::create_vm(JavaVMInitArgs*, bool*) threads.cpp:671
    #26 0x106cb7de4 in JNI_CreateJavaVM jni.cpp:3678
    #27 0x102566510 in JavaMain java.c:494
    #28 0x10256d53c in ThreadJavaMain java_md_macosx.m:679
    #29 0x1936fef90 in _pthread_start+0x84 (libsystem_pthread.dylib:arm64e+0x6f90)
    #30 0x1936f9d30 in thread_start+0x4 (libsystem_pthread.dylib:arm64e+0x1d30)

Comments
Changeset: f6ff38ab Branch: master Author: Manuel Hässig <mhaessig@openjdk.org> Date: 2025-06-24 06:55:05 +0000 URL: https://git.openjdk.org/jdk/commit/f6ff38ab4292762a35fb151b6886e58df60824d5
24-06-2025

A pull request was submitted for review. Branch: master URL: https://git.openjdk.org/jdk/pull/25902 Date: 2025-06-19 15:15:16 +0000
19-06-2025

[~iveresov] suggested > I think we should check for 0 and produce the result to the effect of +Inf
20-05-2025

Right, I think this code needs to be revisited.
10-04-2025

> I think we want 0 to be allowed to disable any feedback, right? I am not sure, maybe this was intended. But the description from src/hotspot/share/compiler/compiler_globals.hpp says : "Tier 3 thresholds will increase twofold when C1 queue size reaches this amount per compiler thread" "Tier 4 thresholds will increase twofold when C2 queue size reaches this amount per compiler thread" Maybe the description should be improved ? Currently I do not get how this feedback disabling matches the description, but I am not a JIT expert.
08-04-2025

[~mbaesken] I think we want 0 to be allowed to disable any feedback, right?
08-04-2025

> due to division by zero, with non-default *LoadFeedback flags, use > 0 value for *LoadFeedback = MLM = P4 Hi [~thartmann] , the threshold load feedback flags e.g. Tier3LoadFeedback https://github.com/openjdk/jdk/blob/9844c1c52b9b7b6959d4e5cc626495c83f4aa9d4/src/hotspot/share/compiler/compiler_globals.hpp#L235 currently check range(0, max_jint) ; so should 0 be not allowed somehow ?
08-04-2025

Code comes from JDK-8251462 in JDK 17. ILW = Undefined behavior in compile threshold scaling (benign) due to division by zero, with non-default *LoadFeedback flags, use > 0 value for *LoadFeedback = MLM = P4
08-04-2025

Seems there is another / similar issue, shown as well by jtreg test runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java#id9 : TEST FAILED: Error processing option TieredRateUpdateMinTime with valid value '-server -XX:+UseG1GC -XX:TieredRateUpdateMinTime=0'! JVM exited with unexpected error code = 134 [0x86] stdout content[] stderr content[/priv/jenkins/client-home/workspace/openjdk-jdk-weekly-macos_aarch64-opt/jdk/src/hotspot/share/compiler/compilationPolicy.cpp:846:39: runtime error: division by zero #0 0x1052c2a50 in CompilationPolicy::update_rate(long, methodHandle const&) compilationPolicy.cpp:846 #1 0x1052c3a64 in CompilationPolicy::compile(methodHandle const&, int, CompLevel, JavaThread*) compilationPolicy.cpp:814 #2 0x1052c3100 in CompilationPolicy::event(methodHandle const&, methodHandle const&, int, int, CompLevel, nmethod*, JavaThread*) compilationPolicy.cpp:736 #3 0x1058ba260 in InterpreterRuntime::frequency_counter_overflow_inner(JavaThread*, unsigned char*) interpreterRuntime.cpp:1074 #4 0x1058b9fdc in InterpreterRuntime::frequency_counter_overflow(JavaThread*, unsigned char*) interpreterRuntime.cpp:1023 #5 0x1176f38c0 (<unknown module>) #6 0x1176f090c (<unknown module>) #7 0x1176f090c (<unknown module>) #8 0x1176f090c (<unknown module>) #9 0x1176f090c (<unknown module>) #10 0x1176f090c (<unknown module>) #11 0x1176f090c (<unknown module>) #12 0x1176f090c (<unknown module>) #13 0x1176f081c (<unknown module>) #14 0x1176f081c (<unknown module>) #15 0x1176f0a8c (<unknown module>) #16 0x1176f081c (<unknown module>) #17 0x1176ec150 (<unknown module>) #18 0x1058cc724 in JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*) javaCalls.cpp:415 #19 0x1058cbaac in JavaCalls::call_static(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, JavaThread*) javaCalls.cpp:250 #20 0x1058cbb90 in JavaCalls::call_static(JavaValue*, Klass*, Symbol*, Symbol*, JavaThread*) javaCalls.cpp:256 #21 0x106144030 in call_initPhase1(JavaThread*) threads.cpp:298 #22 0x106143424 in Threads::initialize_java_lang_classes(JavaThread*, JavaThread*) threads.cpp:382 #23 0x106144ec8 in Threads::create_vm(JavaVMInitArgs*, bool*) threads.cpp:671 #24 0x1059b7de4 in JNI_CreateJavaVM jni.cpp:3678 #25 0x101286510 in JavaMain java.c:494 #26 0x10128d53c in ThreadJavaMain java_md_macosx.m:679 #27 0x1936fef90 in _pthread_start+0x84 (libsystem_pthread.dylib:arm64e+0x6f90) #28 0x1936f9d30 in thread_start+0x4 (libsystem_pthread.dylib:arm64e+0x1d30) Seems it is coming from this divison : method->set_rate((float)delta_e / (float)delta_t); // Rate is events per millisecond
07-04-2025