Idea about memory management. Game related.
daniel.keep.lists at gmail.com
Tue Jun 13 17:27:31 PDT 2006
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;
>>> byte B = new byte;
>>> 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
>> 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.
I believe the Boehm GC has such an alloc function. I think they call it
"atomic" data or somesuch.
Unlike Knuth, I have neither proven or tried the above; it may not even
More information about the Digitalmars-d