Idea about memory management. Game related.

Daniel Keep daniel.keep.lists at
Tue Jun 13 17:27:31 PDT 2006

Sean Kelly wrote:
> pragma wrote:
>> In article <e6kd4u$300u$1 at>, 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.


More information about the Digitalmars-d mailing list