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

Dean Long dlong at openjdk.org
Thu Mar 20 01:36:21 UTC 2025


On Mon, 17 Mar 2025 18:05:11 GMT, Tom Rodriguez <never at openjdk.org> wrote:

>> 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.
>
> I agree with Vladimir that it seems like something is wrong with the block probabilities.  In product it would be fine to simply clamp these values in the range of 0..100 since they are just used to compute `CFGEdge::_infrequent` so the worst thing you get is a less good layout.  Refactoring the expressions so it's more clear what the requirements wouldn't hurt either.

There may be a bug in frequency propagation.  I don't understand the connector/non-connector logic, but when I reproduce this, the successor has a loop block with high _freq, but then we use non_connector_successor() to get the successor, and that gives us instead a different block which originally had 0 _freq, but got changed to MIN_BLOCK_FREQUENCY by CFGLoop::scale_freq().

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

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


More information about the hotspot-compiler-dev mailing list