RFR: 8346888: [ubsan] block.cpp:1617:30: runtime error: 9.97582e+36 is outside the range of representable values of type 'int'

[Vladimir Kozlov]

On Sat, 15 Mar 2025 03:59:07 GMT, Dean Long <dlong at openjdk.org> wrote:

>> Yes, CFGLoop::scale_freq() is turning a 0 _freq value into MIN_BLOCK_FREQUENCY, which is 1.e-35f.  Dividing by such a small number can overflow a 32-bit int.  Maybe this is a never-taken out edge of an infinite loop?  It might be a bug to give this edge an effectively infinite frequency percentage.  This will cause CFGEdge::to_infrequent() to report false, when maybe it should return true.  I don't understand this code well enough to decide.  Maybe a loop expert can tell us if having this frequency overflow here is harmless or not.  Tagging @rwestrel and @TobiHartmann
>
> This code seems to be really old, from https://bugs.openjdk.org/browse/JDK-6743900.  Tagging reviewers @tkrodriguez and @vnkozlov .  To me, the formula for `to_pct` looks wrong.  I would expect `b->_freq` and `target->_freq `to be multiplied together, not divided.

Block::_freq is number of times this block is executed per each call of the method. It could be big number for blocks in loop and very small on not frequent path.

`succ_prob()` is calculated based on frequencies of two block and/or corresponding branch probability: [gcm.cpp#L2100](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/opto/gcm.cpp#L2100)

`freq = b->_freq * b->succ_prob(j)` is number of times we take this outgoing path. So to calculate probability of taking this path in `target` block we divide `freq` on number of times `target` block is executed.

This assumes that `b->_freq` <= `target->freq`. Which seems not true in this case and indicate a bug in how we calculate and update blocks frequencies.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23962#discussion_r1997687585