On Tue, Jul 30, 2013 at 4:07 PM, Raoul Duke <[email protected]> wrote:
> like, gc sucks especially hard when the memory gets too tight. there's > got to be some factor 2x, 4x, whateverX more free memz to keep the gc > from thrashing, it would seem. What we think we want is a production implementation of the C4 collector, since it doesn't world-stop.... and I'm starting to see that for some scenarios maybe a region concept to help relieve pressure. In current production JVM/CLR/Lua/V8 GCs, it's a thorny beast. If you fill and thrash the tenured generation, the only way to reclaim it is a world-stop and full-heap-mark, followed by collection phases. The problem with this is that there is no "headroom" that fixes it unless you have enough headroom to not collect. The bigger your heap is, the larger the pause is when you finally reach it. The solutions with today's GC are *basically* (with lots of details omitted) (a) use a ridiculously GC tiny heap by getting big things out of it (to block-buffers, value-types, unsafe data), (b) reduce allocation and use a giant heap so big you can hopefully survive until a time where you can afford a really long pause, (c) stop churning the tenured generation by either ending allocation, or making all churn short lived. so (a) getting that factor down would be nice. but (b) nobody knows how > much their program will demand until they run it, so we're a bit in the > dark. You didn't describe your program but you did mention games. One solution to this if you are on a GC VM with value-type-arrays (like CLR or V8 typed-arrays), is to decide how many "dynamic" objects your game engine can truly handle at the limit, and make global arrays for all of them. Then manage the slots of those global arrays yourself manually. However, they can't contain "real" pointers or they have to be traced, and you can't hold pointers to value-types anyhow, so reference other array-objects with array indicies instead.
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
