Re: Is garbage collection here yet?
Available news archives: comp.lang.tcl - comp.lang.python - comp.security.firewalls - sci.crypt - comp.lang.php - comp.lang.javascript
Google
 
Web news.hping.org


comp.lang.tcl archive

Re: Is garbage collection here yet?

From: Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at>
Date: Wed Mar 15 2006 - 18:31:06 CET

Neil Madden <nem@cs.nott.ac.uk> wrote:
> Andreas Leitgeb wrote:
>> Artur <mail@xdobry.de> wrote:
>>>Working quite long with GC-languages I can say: Also GC-Systems has
>>>memory leaks (circular references)
>> Java does *not* have problems with circular references.

> The deep point here is that every indexed container creates a new way of
> creating references. For instance, if I create a hashtable then the keys
> of that table are "references" to the objects in the table. But how do I
> tell if an object is no longer reachable by any key?

There are two answers:

  The simple one: every collection defines iterators, so you
    can always find all objects that are referenced by the
    Hashtable, even if you had no other ref to some Key-object.

  The complex one: There are so-called Soft- and Weak-References
    in Java (This I only learned between my last posting and this :-)
    They are a bit differently used from normal (strong) references,
    but allow you to keep some Objects available "as long as reasonable"
    without preventing them from being ever gc'ed. An interesting concept.

Anyway, this is irrelevant to Tcl.

If a Program fills up collections with objects it doesn't need,
  this is not a leak, but rather a memory-wasting application.

All Tcl-oo-systems that I'm currently aware of manifest their
objects in some way e.g. as commands, as namespaces, as
array-variables, and each of these types of manifestation
could be searched for leftover objects. So, objects don't
really leak.
  In C/C++ (in contrast) any malloc/new'ed block of memory whose
address is "forgotten" is really lost and thus leaked. (Leaving
aside special bookkeeping overridings of new/malloc)
Received on Sun Apr 30 02:34:15 2006