Some updates about this feature:

The proposal I mentioned above actually may not be suitable for production use, because keeping the frame data accessible will limit YJIT's optimisation options.
On the other hand, the current implementation using TracePoint.new(:raise) actually doesn't cancel YJIT's optimisation. This is because unlike :line or :call's implementations, :raise event's doesn't trigger YJIT's invalidation logic.
- Since it's not intentional to skip this event, there's no guarantee that it will always be like this. But it also doesn't look like it's going to change anytime soon.

So to summarise what we have now:

I'm not sure if you're aware of it, but the current implementation ONLY captures the closest 1 frame's local variables, not the whole stack's. This is because we don't have a good way to access the frames on the stack. And based on the potential conflict with YJIT, there may never be one.
Even though the current implementation doesn't cancel YJIT's optimisation, I think it's safer to do more production testing before turning it on by default.

I also want to say that cancelling YJIT's optimisation in the above case probably won't the end of the world. It's still largely depending on:

If it's a whole/partial cancellation.
- My original concern about using TracePoint would've been a total cancellation, so that's why I was very worried.
How significant would the cancelled optimisation be.
Is there a good middle ground to let us trade the extra frame info with losing only few YJIT optimisation.

Deprecate capture_exception_frame_locals in favour of includeLocalVariables #1986

Description