RFR: 8346888: [ubsan] block.cpp:1617:30: runtime error: 9.97582e+36 is outside the range of representable values of type 'int'
Tom Rodriguez
never at openjdk.org
Thu Mar 20 15:47:10 UTC 2025
On Thu, 20 Mar 2025 01:33:58 GMT, Dean Long <dlong at openjdk.org> wrote:
>> 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().
Could the problem be inconsistent use of non_connector_successor? Isn't there some logic which forces deopt blocks to have low frequencies? It it's only setting the non_connector_successor frequency then you'd get inconsistent results if you didn't use non_connector_successor for examining successors. Maybe it should be adjusting the frequency of all blocks leading to the non_connector_successor?
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/23962#discussion_r2005942687
More information about the hotspot-compiler-dev
mailing list