Idea about memory management. Game related.

[Sean Kelly]

pragma wrote:
> In article <e6kd4u$300u$1 at digitaldaemon.com>, Chad J says...
>> Once it executes A = B, the memory held by what was once A is leaked 
>> until a garbage collection occurs.  I'm not sure, but this could mean 
>> longer and more frequent garbage collections, unless you avoid 
>> allocating on the gc heap altogether for the rest of the program's 
>> execution.  This would call for some manual management, like so:
>>
>> byte[] A = new byte[128];
>> byte[] B = new byte[64];
>> delete A;
>> A = B;
> 
> Wouldn't it be safe to say that if one were very pedantic about manually
> deleting everything they weren't using, that any pending GC cycle would be
> marginalized considerably?  After all, the GC spends a lot of its time figuring
> out what we already know at the point of deletion - that is, what is in use and
> what is not.

Yes.  And passing some type information to the GC would also help 
considerably.  Currently, the GC must assume all data could potentially 
be a pointer, while at the very least it should be possible for the GC 
to avoid scanning array data if the arrays don't contain object 
references or pointer types.  For games, such bulk data probably makes 
up a significant chunk of allocated storage.


Sean