tree ad4231ee8a812e7702ddefdf6c9b9061a178d674
parent e1910f1d802dff79bba5ef61e1c4fd0b95f6e5b0
author Sebastien Hertz <shertz@google.com> 1399983341 +0200
committer Sebastien Hertz <shertz@google.com> 1400138748 +0200

Register debugger for interesting instrumentation events only

This avoids the overhead of notifying events (like method entry/exit, field
read/write, ...) from the interpreter when they are not requested on the JDWP
side. It also avoids burning JDWP ids for objects and classes before we find
out we do not need to report the event.

When we register a JDWP event (like a breakpoint), we add the debugger as
a listener for the corresponding instrumentation event (like kDexPcChanged).
On the other hand, when a JDWP event is cleared, we remove the debugger as a
listener for the corresponding instrumentation event. To control we add/remove
the debugger as listener only once per instrumentation event, we use reference
counting.

Like deoptimization, we can update instrumentation listeners only when when all
mutator threads are suspended. To add or remove the debugger as listener, we
extend the support of deoptimization requests to a more general support dealing
with instrumentation requests.
We add kRegisterForEvent and kUnregisterForEvent request kinds, respectively to
add or remove the debugger as a listener for a given instrumentation event.
Note: we will rename the related classes, methods, ... to avoid pollution in
the code review.

This CL also fixes Instrumentation::IsActive to take field read/write events
into account.

Bug: 14401699
Bug: 14826953
Change-Id: Ic896469e82a8589de419ebea4b9dc3116925f3ab