Adjust sticky GC ergonomics.
Added an adjustment factor that causes sticky GC to occur more often.
Currently, we adjust the throughput by 5 / 4 comapred to the non
sticky GC. This improves the MemAllocTest score by 50-100. I believe
this happens since the sticky GC uses less memory bandwidth than
partial/full GC. No benchmark score regression on
EvaluateAndApplyChanges though total GC time is increased by ~0.5s.
Bug: 13818507
Change-Id: Ic721a1bff069ddaf8acc55e776b8bc26e171d46e
diff --git a/runtime/gc/heap.cc b/runtime/gc/heap.cc
index feb7a48..34a122f 100644
--- a/runtime/gc/heap.cc
+++ b/runtime/gc/heap.cc
@@ -77,6 +77,10 @@
// Minimum amount of remaining bytes before a concurrent GC is triggered.
static constexpr size_t kMinConcurrentRemainingBytes = 128 * KB;
static constexpr size_t kMaxConcurrentRemainingBytes = 512 * KB;
+// Sticky GC throughput adjustment, divided by 4. Increasing this causes sticky GC to occur more
+// relative to partial/full GC. This is desirable since sticky GCs interfere less with mutator
+// threads (lower pauses, use less memory bandwidth).
+static constexpr double kStickyGcThroughputAdjustment = 1.25;
Heap::Heap(size_t initial_size, size_t growth_limit, size_t min_free, size_t max_free,
double target_utilization, size_t capacity, const std::string& image_file_name,
@@ -2548,7 +2552,7 @@
// We also check that the bytes allocated aren't over the footprint limit in order to prevent a
// pathological case where dead objects which aren't reclaimed by sticky could get accumulated
// if the sticky GC throughput always remained >= the full/partial throughput.
- if (collector_ran->GetEstimatedLastIterationThroughput() >=
+ if (collector_ran->GetEstimatedLastIterationThroughput() * kStickyGcThroughputAdjustment >=
non_sticky_collector->GetEstimatedMeanThroughput() &&
non_sticky_collector->GetIterations() > 0 &&
bytes_allocated <= max_allowed_footprint_) {