Improve sticky GC ergonomics
Before we scheduled a partial GC after 10 sticky GC had been run to
prevent excessive heap growth and fragmentation. The issue with this is
that it was just a ballpark estimate which was not based on reality. The
new behaviour has that we do sticky GC until we have less space remaining
than minimum free after the GC. When this occurs, we set the next GC to be a
partial GC. After a partial / full GC we grow the heap and set the next GC to
be a sticky GC. This prevents the heap from always growing more than the target
utilization, while ensuring that we do sticky GC often.
dumpsys meminfo: ~450Mb -> 420Mb. Slight slowdown in GCBench.
Change-Id: Ifd865123f7d4ae39914fda44c9225a6731d27890
diff --git a/src/gc/heap.h b/src/gc/heap.h
index d86c7dc..790ab02 100644
--- a/src/gc/heap.h
+++ b/src/gc/heap.h
@@ -424,7 +424,7 @@
// Given the current contents of the alloc space, increase the allowed heap footprint to match
// the target utilization ratio. This should only be called immediately after a full garbage
// collection.
- void GrowForUtilization(uint64_t gc_duration);
+ void GrowForUtilization(collector::GcType gc_type, uint64_t gc_duration);
size_t GetPercentFree();
@@ -488,6 +488,7 @@
// Last Gc type we ran. Used by WaitForConcurrentGc to know which Gc was waited on.
volatile collector::GcType last_gc_type_ GUARDED_BY(gc_complete_lock_);
+ collector::GcType next_gc_type_;
// Maximum size that the heap can reach.
const size_t capacity_;
@@ -502,12 +503,6 @@
// it completes ahead of an allocation failing.
size_t concurrent_start_bytes_;
- // Number of back-to-back sticky mark sweep collections.
- size_t sticky_gc_count_;
-
- // After how many sticky GCs we force to do a partial GC instead of sticky mark bits GC.
- const size_t sticky_to_partial_gc_ratio_;
-
// Since the heap was created, how many bytes have been freed.
size_t total_bytes_freed_ever_;