Idea about memory management. Game related.

[Chad J]

Sean Kelly wrote:
> 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

Sounds like my decision to use arrays instead of pointers-to-data for 
all of my data (graphics and stuff traditionally done with pointers) is 
not just good, but very very good.  I originally decided on using arrays 
just to be able to use bounds-checking during a debug phase, but I take 
this as meaning it could be a big speed boost too!