summaryrefslogtreecommitdiffstats
path: root/runtime/jdwp
diff options
context:
space:
mode:
authorSebastien Hertz <shertz@google.com>2014-09-18 10:20:42 +0200
committerSebastien Hertz <shertz@google.com>2014-09-18 11:49:59 +0200
commitf272af4b9dcd39cdd50fa6655601a26e837eaea9 (patch)
tree31e57bb86fadf00aeb05de3f4211320d7a281bf4 /runtime/jdwp
parentd41491adb23764f28a80cbb7f2bd7af6491cd892 (diff)
downloadart-f272af4b9dcd39cdd50fa6655601a26e837eaea9.tar.gz
art-f272af4b9dcd39cdd50fa6655601a26e837eaea9.tar.bz2
art-f272af4b9dcd39cdd50fa6655601a26e837eaea9.zip
Move spammy logs to JDWP verbose mode
We are spammed by warning messages when debugging, especially each time we suspend/resume all threads (to update instrumentation or collect monitor info). It's common to get into the cases where these warnings are logged so they shouldn't be warning but debug messages. This CL moves these LOG(WARNING) to VLOG(jdwp) to not disturb developers when debugging their app (especially when looking for specific messages in logcat). We keep them in JDWP verbose mode because they help knowing when we initiate these sequences of "suspend/resume all threads". Also adds debug suspend count in the log message for more context. Bug: 17524544 Bug: 17170697 Change-Id: Ic87985ac6913151d15fd89849e41bde61092c3dd
Diffstat (limited to 'runtime/jdwp')
-rw-r--r--runtime/jdwp/jdwp_event.cc9
1 files changed, 5 insertions, 4 deletions
diff --git a/runtime/jdwp/jdwp_event.cc b/runtime/jdwp/jdwp_event.cc
index fc39cc48d0..3b1cfd742f 100644
--- a/runtime/jdwp/jdwp_event.cc
+++ b/runtime/jdwp/jdwp_event.cc
@@ -295,9 +295,6 @@ void JdwpState::UnregisterEvent(JdwpEvent* pEvent) {
/*
* Remove the event with the given ID from the list.
*
- * Failure to find the event isn't really an error, but it is a little
- * weird. (It looks like Eclipse will try to be extra careful and will
- * explicitly remove one-off single-step events.)
*/
void JdwpState::UnregisterEventById(uint32_t requestId) {
bool found = false;
@@ -317,7 +314,11 @@ void JdwpState::UnregisterEventById(uint32_t requestId) {
if (found) {
Dbg::ManageDeoptimization();
} else {
- LOG(WARNING) << StringPrintf("Odd: no match when removing event reqId=0x%04x", requestId);
+ // Failure to find the event isn't really an error. For instance, it looks like Eclipse will
+ // try to be extra careful and will explicitly remove one-off single-step events (using a
+ // 'count' event modifier of 1). So the event may have already been removed as part of the
+ // event notification (see JdwpState::CleanupMatchList).
+ VLOG(jdwp) << StringPrintf("No match when removing event reqId=0x%04x", requestId);
}
}