Idea about memory management. Game related.

[Daniel Keep]

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

I believe the Boehm GC has such an alloc function.  I think they call it
"atomic" data or somesuch.

	-- Daniel

-- 
Unlike Knuth, I have neither proven or tried the above; it may not even
make sense.

v2sw5+8Yhw5ln4+5pr6OFPma8u6+7Lw4Tm6+7l6+7D
i28a2Xs3MSr2e4/6+7t4TNSMb6HTOp5en5g6RAHCP  http://hackerkey.com/