adjust some gc heuristics

[JeffBezanson]

An attempt to do something about #32472 and #28986 (also helps #29740 a bit).

In #28986, we basically see a live size alternating between x and 2x, and each x->2x transition was triggering an unnecessary full collection. What I'd like to do instead is full collect if (1) the heap has grown a lot since the last full collection, and (2) minor collections are not succeeding at reducing it. I tried to implement that by monitoring the live_bytes variable and looking for growth that lasts a couple minor collections.

In #32472 we have very long pause times (for both major and minor, some nearly 500ms on my system), probably due to marking large numbers of Tasks. We have been keeping the collection interval a fairly small constant as long as minor collections are succeeding at freeing all new objects. That makes sense if minor collections are basically free, but if they get slow we need to back off the interval. I've been trying to do something timing-based, but it gets fairly unpredictable and complex. A simple approach I found was to allow the minor collect interval to be some fraction (half) of live_bytes. In many workloads, the collect interval is actually much larger than the number of live bytes, so allowing it to scale this way seems reasonably conservative to me.

Finally, for some reason we were resetting the interval to default_collect_interval / 2. Does anybody know why? I traced that to 7c8acce (5 years ago). I mean, it's called default_collect_interval, not twice_default_collect_interval.

[JeffBezanson]

@nanosoldier runbenchmarks(ALL, vs=":master")

[StefanKarpinski]

I imagine that @yuyichao might be a good person to review if he's willing.

[JeffBezanson]

Indeed. The reviewers box isn't letting me select him, which is maybe some sort of github problem?

[StefanKarpinski]

Yeah, I'm not sure, his user name also never autocompletes, so maybe some privacy setting?

[nanosoldier]

Your benchmark job has completed - possible performance regressions were detected. A full report can be found here. cc @ararslan

[vtjnash]

Nice, it looks like there’s a chance you might have made some of the “problems” faster without affecting much else!

[JeffBezanson]

I'll merge this for now; can certainly revert or revise if any objections or problems arise.