JDK-8349139 : C2: Div looses dependency on condition that guarantees divisor not zero in counted loop
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 24,25
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2025-01-31
  • Updated: 2025-05-16
  • Resolved: 2025-04-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 25
25 b21Fixed
Related Reports
Blocks :  
Causes :  
Causes :  
Relates :  
Relates :  
Relates :  
Description
I found this during work on JDK-8340093.

I took the test added by JDK-8263971: TestLostDependencyOnZeroTripGuard.java
And only changed the limit 3 -> 2.
https://github.com/openjdk/jdk/pull/3190

It could be a JDK24 regression of JDK-8334724, was the initial guess by [~chagedorn].
https://github.com/openjdk/jdk/pull/19831

-------------------- How to Reproduce ---------------------

On latest JDK24 or JDK25 (did not reproduce on JDK23).

/oracle-work/jdk-25/fastdebug/bin/java -Xcomp -XX:-TieredCompilation -XX:CompileOnly=Test::* -XX:+UnlockDiagnosticVMOptions -XX:+StressGCM -XX:UseAVX=2 -XX:StressSeed=139899009 -XX:CompileCommand=printassembly,*::mainTest Test.java

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGFPE (0x8) at pc=0x00007ff0009728af, pid=273793, tid=273794
#
# JRE version: Java(TM) SE Runtime Environment (25.0+8) (fastdebug build 25-ea+8-LTS-843)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 25-ea+8-LTS-843, compiled mode, sharing, compressed oops, compressed class ptrs, g1 gc, linux-amd64)
# Problematic frame:
# J 88 c2 Test.mainTest([Ljava/lang/String;)V (115 bytes) @ 0x00007ff0009728af [0x00007ff000972760+0x000000000000014f]
#
# Core dump will be written. Default location: Core dumps may be processed with "/usr/share/apport/apport -p%p -s%s -c%c -d%d -P%P -u%u -g%g -- %E" (or dumping to /oracle-work/jdk-fork5/core.273793)
#
# An error report file with more information is saved as:
# /oracle-work/jdk-fork5/hs_err_pid273793.log
#
# If you would like to submit a bug report, please visit:
#   https://bugreport.java.com/bugreport/crash.jsp
#
Aborted (core dumped)


From my first assessment, it looks exactly like the bug from:
https://github.com/openjdk/jdk/pull/3190

A DivI sits in the main-loop. But that main-loop eventually is fully unrolled, and loses its loop structure. Before this, the DivI had to be scheduled after the loop-phi of the main-loop. But after the loop structure removal, the DivI can float up, even inside the pre-loop with StressGCM.

https://github.com/openjdk/jdk/pull/3190
Should have fixed this with the CastII.

But then the CastII was removed again by:
https://github.com/openjdk/jdk/pull/19831
(needs to be confirmed, this is only speculation at this point)
Comments
Changeset: be6e4406 Branch: master Author: Roland Westrelin <roland@openjdk.org> Date: 2025-04-24 09:10:43 +0000 URL: https://git.openjdk.org/jdk/commit/be6e4406d8c9024bb368ed9dc22d4a6df2a0846a
24-04-2025

Note that only platforms are affected on which div instructions raise a signal. I've linked JDK-8299857.
14-02-2025

A pull request was submitted for review. Branch: master URL: https://git.openjdk.org/jdk/pull/23617 Date: 2025-02-13 16:30:20 +0000
13-02-2025

Roland, could you please have a look? Thanks.
31-01-2025

Looks like a regression in JDK 24 b14, so most likely it's indeed from JDK-8334724. Narrowing it down ... UPDATE: Confirmed. It's a regression from JDK-8334724, or at least triggered by that change.
31-01-2025

ILW = Same as JDK-8263971 = P3
31-01-2025