Update how deoptimization from runtime methods is supported

We need to support deoptimization when returning from runtime methods
- To support setting break points or other debug related features for
  long running loops we should be able to deopt at suspend points.
- To deoptimize the full stack when we have runtime functions like
  art_quick_to_interpreter_bridge on the stack.
- To deoptimize the optimized code after redefining the class. Once
  we redefine the class the offsets of the fields could change
  because the field offsets are grouped together by type when
  allocating. This would invalidate all optimized code and
  deoptimization cannot be pushed to a later point.

Earlier this was achieved by instrumenting the stack and updating
the return pcs of the runtime functions to instrumentation exit
stub, so we could deoptimize the method. However runtime methods
can be called in different scenarios which complicated the logic
and was inaccurate in some scenarios.

This CL changes the approach to check if a deoptimization is
required before returning from the slow path of runtime functions
that can suspend. Checking for deopts only at suspend points is not
sufficient because of the class redefinition support as mentioned
earlier.

Bug: 204766614,208587492
Test: art/test.py
Change-Id: Ia655d957bae4ff891f8f32a0f3110c80e7a80bfd

0 files changed, 0 insertions, 0 deletions