[Home] [Groups] - Message: [Prev in Group] [Next in Group]

nu.kanga.list.mud-dev

24089: Re: [MUD-Dev] New Beginings

[Full Header] [Plain Text]
From: Lars Duening <lars@bearnip.com>
Newsgroups: nu.kanga.list.mud-dev
Date: Wed, 05 Jun 2002 10:10:23 -0600
References: [1] [2] [3] [4] [5] <-newest
Organization: Kanga.Nu
David B. Held wrote on Tuesday, June 04 2002, 20:33:24:
> From: "Lars Duening" <lars@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@bearnip.com
PGP Key: http://www.bearnip.com/lars/pgp-lars.asc

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