tree ee9e4a99f234892ff07a815850cef94a0236d435
parent 807140048f82a2b87ee5bcf337f23b6a3d1d5269
author Sebastien Hertz <shertz@google.com> 1416247237 +0100
committer Sebastien Hertz <shertz@google.com> 1416910575 +0100

JDWP: only deoptimize when it is required

We don't need to deoptimize anything when we forced the use of the
interpreter (-Xint). In this case, no compiled code is executed
(except native methods which are not concerned by deoptimization).
Therefore we even don't need to enable/disable deoptimization support
in instrumentation.

We also don't need to deoptimize a method that hasn't been compiled.
Since it will run with interpreter, there is no point deoptimizing
it. However this method may be inlined in a compiled caller method
so we still need to deoptimize everything in this case.

This CL updates breakpoint support by storing the required kind of
deoptimization for a particular method. There are 3 cases:
- kNothing: the method does not require deoptimization.
- kSelectiveDeoptimization: the method needs to be deoptimized.
- kFullDeoptimization: we must deoptimize everythinig.
When uninstalling a breakpoint, we need to do the reverse operation.

Also fixes the SanityCheckExistingBreakpoints function to control
breakpoints related to the given method only and adds extra verbose
ilogs when choosing the appropriate deoptimization kind.

Includes a partial cherry-pick of commit
87553c9fa1298ffb40127b2bb6413859fd3f79df to use method
ClassLinker::GetOatMethodQuickCodeFor.

Bug: 18407046

(cherry picked from commit f3928794a10516e2ac0ffe2686a10891788d4b9c)

Change-Id: I50853cc5fc5c52650485785a1198d35ea0f7fb8e