Avoid instrumentation stack corruption.

While debugging a throwing exception, we may end up updating instrumentation
stack frame after having already walked the native stack. This leads to not pop
instrumentation frames prior to catch handler (or upcall if exception is not
caught) and get it desynchronized with the native stack.

To solve this issue, we need to walk the stack again after having reporting the
exception to the instrumentation listener (for example: the debugger) which
may push new instrumentation stack frames. However we do it only when we know
instrumentation is enabled to not slow down exception delivery when executing
code without instrumentation.

Here are the main changes:
- Creates InstrumentationStackVisitor to compute the number of instrumentation
frames to pop (previously done in CatchBlockStackVisitor). We only count frames
prior to catch handler (or upcall). Popping instrumentation frames is done
after having reported the exception to the instrumentation listener.
- Updates the CatchBlockStackVisitor to remove instrumentation frame handling
and focus only on finding the catch handler and prepare deoptimization.
- Creates CatchFinder class to control both visitors and do the long jump.

Change-Id: I29b3871403f297bfb8c087e27f1330b002f5d56d

0 files changed, 0 insertions, 0 deletions