RFR: 8365047: Remove exception handler stub code in C2 [v2]

Andrew Dinn adinn at openjdk.org
Thu Aug 28 17:05:53 UTC 2025


On Thu, 28 Aug 2025 16:27:15 GMT, Ruben <duke at openjdk.org> wrote:

>> Ruben has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address review comments
>
> One of these checks is at `frame::get_deopt_original_pc` - based on the result `frame::setup` determines whether a deoptimization is in progress.
> - https://github.com/openjdk/jdk/blob/2d8012a392265781a90b2c3e1ea0bce14efbd41b/src/hotspot/share/runtime/frame.inline.hpp#L74-L82
> - https://github.com/openjdk/jdk/blob/2d8012a392265781a90b2c3e1ea0bce14efbd41b/src/hotspot/cpu/arm/frame_arm.inline.hpp#L114-L130
> 
> There is also a similar check - specifically for AArch32 - to determine value of `SP` at `frame::adjust_unextended_sp`  which wouldn't be affected by the specific issue (at least in `release` build) because it compares with the special case of deoptimization handler stub code used for `MethodHandle` call sites.
> - https://github.com/openjdk/jdk/blob/2d8012a392265781a90b2c3e1ea0bce14efbd41b/src/hotspot/cpu/arm/frame_arm.cpp#L356-L381

@ruben-arm Ah ok, so I guess that's not really just an arm bug then. Previously we always had an exception handler between the end of the code and the deopt handler so the latter could never immediately follow an end-of-code-section call. However, now that we are omitting the exception handler this could happen on any architecture. Which means that shared method `frame::get_deopt_original_pc()` is now no longer reliable.

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

PR Comment: https://git.openjdk.org/jdk/pull/26678#issuecomment-3234269135


More information about the hotspot-dev mailing list