[MUD-Dev] New Beginings

Lars Duening lars at bearnip.com
Wed Jun 5 10:10:23 CEST 2002


David B. Held wrote on Tuesday, June 04 2002, 20:33:24:
> From: "Lars Duening" <lars at bearnip.com>

>> Every time a programmer uses a tracking mechanism for memory
>> allocations - and this includes manually managed reference
>> counters - he or she is using a GC. So for a complex program like
>> a MUD engine, the question is not whether to use GC or not, but
>> rather where to use it and how to give it optimum efficiency.

> I disagree that refcounting == GC.

> The point of GC is that you *don't* know how many references to a
> given object exist until you manually check.

Nope. The point of GC is to enable a program to detect and reclaim
unused memory on its own. How it does this and who wrote the code is
an implementation detail.

> In a sufficiently vague sense you could say that refcounting is a
> form of GC, but I don't see that as being very useful.

The usefulness lies in the realisation of the difference between the
purpose (Garbage Collection) and the implementation (reference
counting). And making this difference is crucial to chosing the
appropriate implementation for a given program (reference counting
doesn't work well with cyclic datastructures).

>> Furthermore, when freeing deeply nested datastructures there is
>> always the chance of the driver running out of stack space and
>> crash (it did happen!).

> I seriously doubt this is a flaw of refcounting.  It is most
> likely an artifact of your implementation.

It is a flaw inherent to the traditional recursive implementation of
refcounting, which is also the most straightforward one. Of course
it is possible to devise an iterative implementation, but it comes
with the cost of higher heap memory usage.

--
Lars Duening; lars at bearnip.com
PGP Key: http://www.bearnip.com/lars/pgp-lars.asc

_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev



More information about the mud-dev-archive mailing list