RFR: 8365047: Remove exception handler stub code in C2
Ruben
duke at openjdk.org
Mon Aug 11 08:41:12 UTC 2025
On Fri, 8 Aug 2025 20:12:08 GMT, Dean Long <dlong at openjdk.org> wrote:
>> The C2 exception handler stub code is only a trampoline to the generated exception handler blob. This change removes the extra step on the way to the generated blob.
>>
>> According to some comments in the source code, the exception handler stub code used to be patched upon deoptimization, however presumably these comments are outdated as the patching upon deoptimization happens for post-call NOPs only.
>
> This looks good. How much testing have you done?
>
> Maybe we can get rid of CodeOffsets::DeoptMH next.
Thank you for the reviews, @dean-long, @dafedafe,
> How much testing have you done?
> Did you run some testing (on the touched platforms)?
I've run tier1-tier3 tests, however only on AArch64 and x86-64.
I can run more tests on these platforms if that might be useful.
> I doubt that there is anything perceivable but, out of curiosity, did you notice any performance change?
I've not measured performance impact of the patch separately. It is a part of a bigger effort to reduce memory footprint of compiled code. The cumulative effect from this and similar patches is expected to be a noticeable performance improvement, however I wouldn't expect a significant observable effect from this patch only.
The decrease for C2-compiled code on AArch64 should be 4-12 bytes (depends on size of code cache) per nmethod, however the nmethod's alignment requirement might hide some of these improvements. I'm also exploring possibility to reduce footprint of the deoptimization handler stub codes.
> Maybe we can get rid of CodeOffsets::DeoptMH next.
I will look into this. I have a proof-of-concept patch reducing each deoptimization handler stub code to 1 instruction each on AArch64 - that instruction traps and the rest of the deoptimization handler logic continues in signal handler. However, I would agree it would be preferable to remove the stub code completely if possible.
-------------
PR Comment: https://git.openjdk.org/jdk/pull/26678#issuecomment-3173773194
More information about the hotspot-dev
mailing list