summaryrefslogtreecommitdiff
path: root/compiler/optimizing/graph_visualizer.cc
diff options
context:
space:
mode:
authorSebastien Hertz <shertz@google.com>2014-05-13 14:15:41 +0200
committerSebastien Hertz <shertz@google.com>2014-05-15 09:25:48 +0200
commit42cd43fa593e8f0427eb0ec158bef08814a6180b (patch)
treead4231ee8a812e7702ddefdf6c9b9061a178d674 /compiler/optimizing/graph_visualizer.cc
parente1910f1d802dff79bba5ef61e1c4fd0b95f6e5b0 (diff)
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
Diffstat (limited to 'compiler/optimizing/graph_visualizer.cc')
0 files changed, 0 insertions, 0 deletions