RFR: 8346989: Deoptimization and re-compilation cycle with C2 compiled code

[Vladimir Ivanov]

On Thu, 20 Mar 2025 12:26:52 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> src/hotspot/share/opto/library_call.cpp line 1963:
>> 
>>> 1961:     set_i_o(i_o());
>>> 1962: 
>>> 1963:     uncommon_trap(Deoptimization::Reason_intrinsic,
>> 
>> What about using `builtin_throw` here? (Requires some tuning on `builtin_throw` side.) How much does it affect performance? Also, passing `must_throw = true` into `uncommon_trap` may help a bit here as well.
>
> I think adapting and re-using `builtin_throw` like you described is reasonable but I let @iwanowww confirm :slightly_smiling_face:

Yes, that's basically what I had in mind.

Currently, the focus of the intrinsic is on well-behaved case (overflows are **very** rare). `builtin_throw()` covers more ground and optimize for scenarios when exceptions are thrown. But it depends on `ciMethod::can_omit_stack_trace()` where `-XX:-OmitStackTraceInFastThrow` mode will suffer from the original problem (continuous deoptimizations), plus a round of recompilations before giving up.

I suggest to improve and reuse `builtin_throw` here and add additional checks in the intrinsic to guard against problematic scenario with continuous deoptimizations. IMO it improves performance model for a wide range of use cases while addressing pathological scenarios.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23916#discussion_r2008427776