Re: Is garbage collection here yet?
- From: Neil Madden <nem@xxxxxxxxxxxxx>
- Date: Wed, 15 Mar 2006 07:33:56 GMT
jrw32982@xxxxxxxxx wrote:
I thought I'd check in on tcl to see if garbage collection (of
"objects", not just strings) was available in the core yet. Without GC
of objects, I don't consider tcl to be a fully higher-level language.
Tcl has so many other cool features (vfs, for example) and such a clean
implementation, it's a pity that it can't be used for OO-style
implemention without jumping through the hacks required to destroy
objects explicitly. Are there any near-future plans to implement GC?
A google search brings up Jim References. Any chance that they'll make
it into the core in the near future?
Short answer: No. Tcl does not support garbage collection of stateful objects yet.
As others have answered, Tcl does do ref-counting GC of its values, which works fine for strings as they can't contain circular references and are stateless/immutable. Adding support for garbage collection of stateful references is much harder. Basically, it's hard to distinguish a reference (to an object) from any other string, which makes it difficult to know when it is safe to delete something. Therefore, mostly people either explicitly destroy objects, or tie them to the lifespan of a variable using traces, so that when the var goes out of scope the object is destroyed (similar to techniques used in C++). However, if you want to return an object then this is a pain. There isn't really a good solution for this yet. My TOOT experiment, mentioned elsewhere in this thread, allows for "objects" which are GC'ed by Tcl, but these are stateless (functional) objects. TOOT is also very slow at present.
You *can* implement GC'ed references in Tcl (see e.g. Salvatore Sanfilippo's work [1]), so long as you take care. For instance, if you tried the following:
set a [ref ...]
set b [string range $a 1 end]
set c [string index $a 0]
unset a
set d $c$b
puts "Value of reference is [ref get $d]"
Then it would fail if the GC ran before d was created. By breaking up the reference you violate the guarantee needed by the GC that any valid references be recognisable as such when the GC runs. Other languages enforce this guarantee by not allowing references to be decomposed in this way to begin with. Tcl however, doesn't support such enforced guarantees, preferring instead to leave this down to programmer discretion, i.e., Don't Do That! I think that's fair enough -- it seems unlikely that anyone would accidentally use string operations on a reference.
However, such a GC mechanism potentially requires scanning lots of strings for matching references, which is inefficient. I *think* an efficient implementation could be made without violating Tcl's semantics, but it would require clever tinkering on the C level (perhaps using some of Paul Duffin's old Feather ideas [2]). Probably would have to wait for the mythical Tcl 9 though, if it is feasible at all.
[1] "Tcl References in Tcl": http://wiki.tcl.tk/9549
[2] "Feather: Teaching Tcl Objects to Fly": http://www.usenix.org/publications/library/proceedings/tcl2k/duffin.html
-- Neil
.
- Follow-Ups:
- Re: Is garbage collection here yet?
- From: Neil Madden
- Re: Is garbage collection here yet?
- References:
- Is garbage collection here yet?
- From: jrw32982
- Is garbage collection here yet?
- Prev by Date: Re: Tk8.4 chooseDir and vfs::ftp latency
- Next by Date: Re: Is garbage collection here yet?
- Previous by thread: Re: Is garbage collection here yet?
- Next by thread: Re: Is garbage collection here yet?
- Index(es):
Relevant Pages
|
Loading
