tree 31648cbd1b6aa6bd7552c4d2664214626b702004
parent bf75c5cf32a47eecadcc5e4a324237c1f1d09cde
author Sebastien Hertz <shertz@google.com> 1416247237 +0100
committer Sebastien Hertz <shertz@google.com> 1416404128 +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
logs when choosing the appropriate deoptimization kind.

Bug: 18407046
Change-Id: I5212c1fd2f72e06c79e7871db15696824d37dc0b