Idea about memory management. Game related.

[Sean Kelly]

Chad J wrote:
> I intend to use D for game programming, and I will probably be facing a 
> lot of the memory management problems that other D game programmers seem 
> to be facing.  I've read some good posts about this, like the one that 
> cropped up here a few days ago.  Anyhow, I came up with this idea, and I 
> thought I'd run it by you folks.
> 
> My idea is to spawn a thread in C/C plus plus to handle the graphics, 
> audio, and anything else that needs to run smoothly no matter what.  I'd 
> use a C thread because it would (I think) not be paused when D runs a 
> garbage collection.  Then I could use the D program to do the other 
> stuff that would benefit from the GC, like GUI, skillsystem, AI, etc. 
> That way I can have uninterrupted working of the parts that need it, yet 
> still have development speedup from GC for everything else.

Just be aware that if you use mutex-protected shared data for 
communication with that thread, a GCed thread could be suspended during 
a collection while it holds the lock and effectively block your 
"real-time" thread from making progress.  Test-acquire might be handy 
here, which means you wouldn't be using the 'synchronized' statement either.
> If this sort of thing would work well, it'd be nice to see 
> language/library support for this.  Seems like a waste of perfectly good 
> man-hours to have to do all that C coding just to get a thread that 
> isn't paused by garbage collection.  Perhaps some sort of thread-level 
> control over what style of memory management is used would work? 

I've considered it in the past, but issues like the above have stopped 
me from going ahead with the idea.  Between that and resource tracking 
difficulties when some roots are unavailable for scanning and it's 
simply too easy for the user to make a mistake.  I'd prefer to have a 
specialized GC for this purpose--incremental perhaps, so threads are 
rarely/never suspended.

> Also, correct me if I'm wrong, but it seems to me that something like 
> automatic reference counting would be much better for games than 
> mark-and-sweep garbage collection, and would still easy to use.  Maybe 
> not as efficient as doing it by hand or using mark-and-sweep, but 
> probably worth it in development time.

Perhaps, but without object copy semantics in D, rc-pointers are not the 
panacea they are in Cpp.  I wouldn't worry too much about garbage 
collection in D for now, as I suspect performance and such will improve 
before too terribly long.


Sean