[mojo-core] Reduce lingering message queue costs

Incoming messages are stored in a std::vector which we never shrink when
popping off elements. This means its capacity may be allowed to grow
indefinitely, which is bad.

This CL adds a check when popping messages off the queue,
calling shrink_to_fit() if the operation results in the queue crossing
an arbitrary size threshold (multiples of 512 elements).

Bug: 888665
Change-Id: Ie2b89a2104bcd6d3eece29c339e297cdadbd837b
Reviewed-on: https://chromium-review.googlesource.com/1241561
Commit-Queue: Ken Rockot <rockot@chromium.org>
Reviewed-by: Reilly Grant <reillyg@chromium.org>
Cr-Commit-Position: refs/heads/master@{#594104}

mojo/core/ports/message_queue.cc

@@ -6,6 +6,7 @@
 
 #include <algorithm>
 
+#include "base/compiler_specific.h"
 #include "base/logging.h"
 #include "mojo/core/ports/message_filter.h"
 
@@ -53,6 +54,16 @@ void MessageQueue::GetNextMessage(std::unique_ptr<UserMessageEvent>* message,
   total_queued_bytes_ -= (*message)->GetSizeIfSerialized();
   heap_.pop_back();
 
+  // We keep the capacity of |heap_| in check so that a large batch of incoming
+  // messages doesn't permanently wreck available memory. The choice of interval
+  // here is somewhat arbitrary.
+  constexpr size_t kHeapMinimumShrinkSize = 16;
+  constexpr size_t kHeapShrinkInterval = 512;
+  if (UNLIKELY(heap_.size() > kHeapMinimumShrinkSize &&
+               heap_.size() % kHeapShrinkInterval == 0)) {
+    heap_.shrink_to_fit();
+  }
+
   next_sequence_num_++;
 }