On Sat, 25 May 2013 01:16:47 +1000 Manu <turkey...@gmail.com> wrote: > > Errr, well, 1ms is about 7% of the frame, that's quite a long time. > I'd be feeling pretty uneasy about any library that claimed to want > 7% of the whole game time, and didn't offer any visual/gameplay > benefits... Maybe if the GC happened to render some sweet water > effects, or perform some awesome cloth physics or something while it > was at it ;)
Heh, I think that'd be nobel-prize territory. "Side Effect Oriented Developement" It'd be like old-school optimization, but maintains safety and developer sanity. :) > > I think 2% sacrifice for simplifying memory management would probably > get through without much argument. > That's ~300µs... a few hundred microseconds seems reasonable. Maybe a > little more if targeting 30fps. > If it stuck to that strictly, I'd possibly even grant it permission > to stop the world... > Perhaps a naive idea, but Would running the GC in a fiber be a feasible approach? Every time the GC fiber is activated, it checks the time, and then has various points where it yields if the elapsed time passes a threshold value. I see two problems though: 1. The state of GC-controlled heaps can change while the GC fiber is yieled. Don't know how much that could screw things up, or if the issue is even solvable. 2. Does a fiber context-switch take too long? If so, what about a stackless fiber? Ex: http://dunkels.com/adam/pt/