Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
runtime: GC behavior in non-steady mode #10064
Currently GC allows heap to grow to 2x of live memory during the previous GC. This can play badly with spiky memory usage. Consider that in steady state program has live set X. GC will allow heap to grow to 2X and then collect it back to X, and so on. Now consider that there is a 1.5X spike in memory usage. If GC happens after the spike (when live set is again X), then GC will collect X memory (garbage generated during the spike) and set heap limit to 2X as before. Now if GC happens to happen during the spike (when live set is 1.5X), then GC will collect only 0.5X and set heap limit to 3X.
Basically bad timing can increase maximum heap (RSS) by up to 2x.
Memory-constrained environments, like browsers, pay a great deal of attention to this problem. The idea is to set smarter GC threshold when heap grows/shrinks.
I did not work out a solution. But what I have in mind is: if heap grows, and especially if the next threshold (next_gc) will be larger than the current RSS (heap_sys - heap_released), then set next_gc to, say, heap_inuse * (1 + GOGC/100) * 0.75.
I believe this is also true for 1.4 so it isn't a problem we are
That said I do believe that constrained memory GC is an important part of
On Tue, Mar 3, 2015 at 2:29 AM, Dmitry Vyukov firstname.lastname@example.org
As Rick mentioned, I think my GC scheduler design should help with this.