Idea about memory management. Game related.

[Chad J]

Walter Bright wrote:
> The gc will pause all threads when it does a collection, even if those 
> threads are in another language.
> 
> Some thoughts:
> 
> 1) The gc will only pause threads it knows about. So you can create a 
> thread that is unknown to the gc by calling the operating system thread 
> creation APIs directly. However, if you do this, then those threads must 
> not manipulate or reference any gc allocated data.
> 

Ah, good to know!  I take this as implying that I can do my idea without 
touching a line of C code, which is great.

> 2) Using C++ new or malloc is no guarantee of latency. Neither of them 
> have any constraints on how long they take to call, and (due to 
> fragmentation) can cause a significant pause.
> 
> 3) To deal with (2), professional game programmers I've talked to will 
> "preallocate" all the data they'll need before running the task that 
> cannot be paused.
> 
> 4) It is very important to realize that the gc will not collect at some 
> random time. It will ONLY collect during calls to new. No calls to new, 
> no collections.
> 
> 5) Therefore, to avoid pausing during critical times in the game, avoid 
> calling new during those times. You can call malloc() instead if 
> necessary. Calling malloc() won't cause the gc to run.
> 

Sounds to me like just use C++ style manual memory management.  That's 
fine for stuff that's under the hood in my game, but for the stuff that 
modders will be working on, it is not acceptable.

If the GC can finish its collections within 50-100 millisecs, on an ARM 
Xscale processor, I'm happy.  I am going to use some manual memory 
management to hopefully help it out.  I don't think players will notice 
such a short pause.  A collection that would take several seconds 
though, would not work.

In another response Marcio wrote about a GC that makes the app run about 
5% slower but gets rid of long pauses.  That is a tradeoff I would take 
in an instant.  Being able to do fully automatic memory management while 
not worrying about pauses would be awesome, even if it causes some 
performance loss.  Hell I'd even try pushing something like 20%, but I 
like 5% better :)

 > 6) Collection pauses can be minimized by running the gc collector during
 >  idle loops, such as waiting for user input.

I will do that of course, anything that helps, but it's no general 
solution.  I can't count on the player routinely going to the options 
menu or some such in a clockwork fashion.  There may be idle time in a 
few minutes, or a few hours, or a few days.  The game has to be able to 
run without relying on that.

btw, Thanks for the killer language Walter!