TabManager: Remove a redundant log line which produces excessive log.

chrome/browser/memory/tab_manager_delegate_chromeos.cc

Index: chrome/browser/memory/tab_manager_delegate_chromeos.cc
diff --git a/chrome/browser/memory/tab_manager_delegate_chromeos.cc b/chrome/browser/memory/tab_manager_delegate_chromeos.cc
index aef50dcc4be7c6adde7c9fdb10ef878aa93d62de..39a0f0cb50049b8a70f0d4c4847fb22da97faa94 100644
--- a/chrome/browser/memory/tab_manager_delegate_chromeos.cc
+++ b/chrome/browser/memory/tab_manager_delegate_chromeos.cc
@@ -636,8 +636,6 @@ void TabManagerDelegate::LowMemoryKillImpl(
         MemoryKillsMonitor::LogLowMemoryKill("TAB", estimated_memory_freed_kb);
         MEMORY_LOG(ERROR) << "Killed " << *it << ", estimated "
                           << estimated_memory_freed_kb << " KB freed";
-      } else {
-        MEMORY_LOG(ERROR) << "Failed to kill " << *it;

[Yusuke Sato, 2017/05/12 20:47:08]

What about changing this to VLOG? For debugging purposes, we might still want to
see it.

[cylee1, 2017/05/12 21:04:40]

Personally I don't think so. 
Particularly a tab is always in |candidates| no matter discarded or not. It
means for example there're 20 tabs and 10 of them are already discarded. For
each of following low memory event, those 10 tabs would still be scanned, each
producing a spam log line. 
For it to be informative, I think we should print the exact reason why it can't
be discarded (e.g., already discarded? active tab ? audio tab? etc). I think
it's not our priority at this stage.

       }
     }
   }