Switch InterpreterFrame to deterministic unwinding

[am11]

No description provided.

[dotnet-policy-service]

Tagging subscribers to this area: @BrzVlad, @janvorli, @kg
See info in area-owners.md if you want to be subscribed.

[janvorli]

I don't think this is going to work. We need to know the callee saved registers value in the InterpExecMethod function. The ones we capture in the IntepreterFrame are not necessarily related. Both the ExecuteInterpretedMethod and InterpExecMethod can modify these registers.

[am11]

@janvorli, good point. The TransitionBlock values are from InterpreterStub and can be stale by the time we're in InterpExecMethod. I've reworked this to call ClrCaptureContext from within InterpExecMethod's try block instead, so we get the correct callee-saved register values and an IP that falls within the try range.

[janvorli]

@am11, I still feel like capturing the non-volatile registers on the non-exceptional path is a perf hit that we would not like to take. Especially since it is done on every instruction interpreted where every added instruction counts.
When I've measured the impact of adding capturing just the nonvolatile floating point registers in the InterpreterStub / CallInterpreterFunclet, it was about 5% for the case of calling an interpreted method that contained just "ret". But for that change, this gets amortized the more the longer the callee is. With this change, we would add larger hit due to capturing also general purpose non-volatile registers and it would not get amortized.

As an alternative, I've been recently experimenting with the WASM-like resume after catch, it is much more tricky than I've thought it would be due to the need of adding personality routine to more helpers than just the InterpreterStub, having to manually unwind the frame in that personality routine (as it gets the context in the function the personality routine is attached to and we need the context of the caller so that we can rethrow the exception from there) and there might be more. I didn't have a chance to progress on that experiment recently, but I'd like to finish that.

I still feel like keeping using OS libunwind for Apple OSes wouldn't hurt, as it is always present and it doesn't add any burden over there. And iOS is actually the scenario that needs interpreter and that we care about the most (besides WASM).

[am11]

@janvorli, your alternative approach sounds like a worthwhile direction. I haven’t done performance testing myself yet to understand the impact.

Although we will ship only for iOS at first, we already build this code on all desktop platforms. i.e. we can’t discount it from “last six usages of in-tree libunwind” equation due to linux, FreeBSD and others.

[JulieLeeMSFT]

@janvorli, this is awaiting your review.

[janvorli]

@janvorli, this is awaiting your review.

@JulieLeeMSFT in the comments above, we have agreed to do it differently.

[am11]

Superseded by #128728.