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

[Andrew Haley]

On Thu, 30 Oct 2025 10:14:43 GMT, Ruben <duke at openjdk.org> wrote:

> > We shouldn't leave such fragile code in once we've noticed it. IMO it's a false economy to avoid SafeFetch on efficiency grounds. If needs be, there are ways to make it faster.
> 
> @theRealAph, I agree - there should be a mechanism to ensure the function can't cause a crash connected to reading outside the code blob.
> 
> Would it be suitable if this is handled as a separate issue and PR dedicated to resolving it?

Perhaps. I'm not sure it needs it, though.

> One aspect I'm still unsure about, when considering the `SafeFetch`-based approach: as far as I'm aware, there is no guarantee that a code outside a code blob can't ever have a NOP+MOVK sequence (though of course chances of that are very low) and, certainly, there is no guarantee that an arbitrary data outside code blob would not match the pattern.

No, but when we have stack corruption it's better that we don't crash while unwinding. All we're doing by using SafeFetch is adding a little robustness. We're not making things worse.

[ As an aside, I believe we should use SafeFetch during unwinding a lot more than we do at present. A corrupted stack often results in a crash during printing a diagnostic trace, and it's good to catch such errors sooner than later. ]

> If it is possible for the `check` to happen for a location outside code blob and that would happen to result in a false-positive match, then the retrieved information would be unreliable and might lead to further issues including assumption that an arbitrary instruction sequence or data is interpreted as a `CodeBlob`.

Indeed so. One error would lead to another. 

> There is a special case of potentially having a call instruction right at the end of the code blob. As far as I understand, it is not currently possible for platforms for which continuations are enabled because every call is followed by the post-call NOP sequence.

If you step through the stack unwinding code you will encounter calls
without post-call NOPs.

> In case it actually might happen in some case, the `SafeFetch` would guarantee there is no crash, however in my understanding the code might still be fragile: if there instead happens to be another `CodeBlob` next to the current one, the `check` will try to interpret the header data as a post-call NOP sequence.

It's possible, but it's far more likely that we'll get a usable stack trace in a crash dump.

> There can be a false-positive match - as there is no guarantee the data in the header will never match with the post-call NOP sequence pattern. In that case, similarly to the more generic case, an arbitrary data or code could be interpreted as a `CodeBlob` leading to an unpredictable behaviour.

All of this is true, but you are almost implying that we shouldn't make this thing over here robust because there is this other thing over there that needs fixing too.

I'm reminded of the Hubble Space Telescope. The testing error that led to the focussing problem was so gross - about a millimetre - that it could have been detected with a school ruler. It wasn't measured, perhaps because the tolerances to which it was supposed to have been built were much tighter than that.

> I'd like to solve the issue with fragility of the post-call NOP check, however it does appear to me that only adding `SafeFetch` might not fully resolve the concern: it would prevent faults but wouldn't address the false positive matches. If, however, another guarantee is added that post-call NOP check never looks beyond the code blob of the call site, then `SafeFetch` would not be required. What do you think about this perspective?

It may not be possible. Post-call NOPS exist only to make stack unwinding as fast as possible, and if I recall correctly there's already a debug-mode consistency check.

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

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