Re: Larry Wall, on Tcl

On Sat, 15 Dec 2007 18:42:08 -0500,
Alan Anderson <aranders@xxxxxxxxxxxxx> wrote:

Please give me an example. I'd prefer one that doesn't involve
extensions written in something other than Tcl, since I figure those
would be outside the scope of any potential Tcl garbage collection
system.

I've been trying to identify a problem with using Tcl that garbage
collection could help solve. So far, I've seen nothing to help me in
that goal. The assurances and explanations of its general goodness
all seem to assume that I already know that GC is a good idea, and
that I already know how to use it effectively.

About the only place in TCL that I can think of which isn't already
GC'd, is OOP... If you create an object, the only kind of reference
TCL allows is a rather flimsy string token.

I have an OOPish application that constructs a "context" by sticking
several object references together in a list. For reasons a little too
complex to go into here, there couldn't be any spaces within the list,
so I used a double-colon separated list. A single colon, or any other
separator character, would have worked just fine too, but the
double-colon let me use [namespace tail] and friends, with the only
down-side being a few empty list elements when using [split]. The
components of the context are ordered due to being built up as the data
packet is unraveled layer by layer. So the namespace commands (I was
actually initially going to use file system naming) worked out quite
neatly.

The question is, though, how do you GC that...?!? How's a GC supposed
to know that "::foo1::bar2::cow3" contains a reference to the objects
named ::foo1, ::bar2 and ::cow3? Or even just this [join
[list foo1 bar2 cow3] .] would likely be enough to throw an object GC
off the scent, causing it to collect objects that aren't in fact,
garbage. And if it isn't, then there's a good chance that the objects
will never be collected at all because the GC is so sensitive that it
finds some other reference somewhere that isn't.


Mind you GC here would be very handy. I have come across a number of
times when it would be handy to be able to return an object reference,
and have the object just disappear if it's not needed. Normally, you
need to return the object with a reference, and either trust the user to
release that reference if it's not needed (which is quite often a lot
of unnecessary bother, and prone to leakage), or have an idle timer
release the initial reference (which I've done also, but sometimes
you can quite rapidly accumulate extra references and their
associated idle timers doing it this way).

I ended up handling that case in the above-mentioned application myself,
with a pretty major modification to the "future" package [1] found in
the wiki. In my version, [future] with a single argument, works exactly
as [future] in the wiki package. [future] with two arguments, however,
pre-loads the Tcl_Obj's string representation with the string rep of
the second argument. By modifying the futureUpdateString() function to
also release the internal representation (effectively degrading it from
a futureType to a simple string), I could then rig the
futureFreeIntRep() function to invoke the script in the same manner as
futureUpdateString(). And since futureUpdateString() generally only
gets called if there's no string representation already (although it
does check for, and simply return, if the string rep is already set),
this provides an "unset" trap. I've actually taken it further, to
provide both future (aka late or lazy) evaluation and unset evaluation,
but that's a superfluous issue here, and resulted in a total re-write.

Where this becomes handy, is it allows me to do this:
return [future $self [list unref $self]]

The net result is that if your script ignores the return value, one
reference is removed from the object sometime in the (usually) near
future. If you want to continue using it, then you simply add an
extra reference in your script as you would normally. My [ref]
function also returns the result of [append token ""], instead of
returning the object token directly (which would preserve the "magic
unref" properties of the original returned value), so wrapping the
original call in [ref] quite neatly adds your own ref, while at the
same time releasing the magic one (although the string returned by
[ref] is the same as the one that went in, it's actually a copy and so
the only remaining use of the magic reference will be the one in [ref]s
argument list).


Still... While all this works quite well, and is even reasonably
quick (I have considered re-implementing [ref] and [unref] in C,
since [future] is already a C extension)... It's a long way to go for
simple GC, and even further from being portable. ;) It'll be
interesting to see if built-in OO can make any of this easier.
Personally, I'd very much like to see the unset feature of my [future]
command added into TCL core, even with all its gotcha's. For use on
transient data like this, it is exceedingly handy, and quite safe as
long as you remember that its lifetime is essentially implementation
dependant and hence unpredictable.


Fredderic


[1] http://wiki.tcl.tk/12095
.

Relevant Pages

  • Re: memory leak or not?
    ... MyJonObject is not instanced in this method. ... string A = MyJonObject.ToString; ... As it had been a "normal" reference type the object would in my idea ... a pool somewhere so won't be garbage collected until the application ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: memory leak or not?
    ... MyJonObject is not instanced in this method. ... holds outside the method no reference anymore. ... string A = MyJonObject.ToString; ... the fact that strings are immutable is irrelevant to their garbage ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Larry Wall, on Tcl
    ... inform the need to garbage collect seems impossible in Tcl. ... reference counting in Tcl_Objs. ... the C level, where pointers exist you can do this, if you expose ...
    (comp.lang.tcl)
  • Re: can you return an object from a proc?
    ... a reference which you ... then use to manipulate the object. ... object creation call uses that string to reference the ... This sort of thing is why many OO systems for Tcl allow you to create ...
    (comp.lang.tcl)
  • Re: Complex Specified Information - Pitman Formula
    ... Therefore a significant match between a reference and a test ... string is good evidence of non-random production. ... and there are no finite algorithms to compute their digits. ... probabilities of the different symbols the information source can produce. ...
    (talk.origins)