Idea about memory management. Game related.

[Chad J]

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.

This comes from the perspective of writing a game for a PDA, as soon as 
arm-wince-gdc is done.  I am assuming that garbage collection will be 
quite noticeable on an Xscale 400 MHz that has to do software graphics, 
though I won't know for sure until I write the thing.  I want to make 
large parts of my game moddable, and I think C plus plus is probably a 
crappy scripting language.  I think D could do it though, and I'd put 
all the user-modifiable code in a DDL or something so that mods can be 
easily be dropped in after being compiled on a desktop or some such. 
The idea of using a C thread kinda stemmed from my original plan to use 
Java with C to accomplish the same thing.  The lack of good Java VMs for 
PDAs and Java's intense difficulty in talking to C have made me not want 
to do the Java thing though, and D is faster anyways (probably easier 
too).  I really want Garbage Collection for parts of my game because 
imposing manual memory management makes things a good deal harder to 
code, which is very bad for both development time and modability.  The 
graphics, audio, and such can be done C style though because it'll all 
be under the hood.

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? 
Something like this:

Thread GCed = new Thread( GARBAGE_COLLECTED ); /*GC'd memory*/
Thread MMed = new Thread( MANUAL ); /*manually managed, no pauses*/

or maybe

Thread T = new Thread();
gc.disable( T ); /*Main thread is still GCed, but T is not and it will 
never pause*/

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.