D on next-gen consoles and for game development

[Nick Sabalausky]

On Sat, 25 May 2013 01:16:47 +1000
Manu <turkeyman at 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/