> So a proper Tcl GC would have to be incredibly pessimistic about what it considers to be roots of the object graph - basically, any substring that looks like

> So a proper Tcl GC would have to be incredibly pessimistic about what it considers to be roots of the object graph - basically, any substring that looks like an object reference, has to be considered as one. Now imagine just how much string scanning such a GC would have to do in a non-trivial app for a single sweep! This is how the garbage collector in Jim Tcl works. It scans the string representation of all objects [1] for the reference syntax [2]. In practice, it does not cause performance problems. Since Jim Tcl is intended as a smaller, more easily embedded counterpart to Tcl 8, nobody runs it with a large heap. How slow is it? I have just tried a naive benchmark on a first-gen Raspberry Pi Model B. With a live list of one millions strings and 50 thousand references garbage collection took around 750 ms. On a Core 2 Duo laptop running Linux it took around 120 ms. . for {set i 0} {$i < 1000000} {incr i} { set v$i "<reference.<--NOT padding padding $i" } . for {set i 0} {$i < 50000} {incr i} { set r$i [ref $i test] } . time collect 5 ;# Average of five runs 765443 microseconds per iteration The tracing garbage collector only affects references. Normal strings are reference-counted like in Tcl 8. References are the low-level basis of Jim's OO system, which is implemented in pure Tcl. [1] "Objects" in the sense of Jim_Obj (Tcl_Obj). https://github.com/msteveb/jimtcl/blob/da293a1eef2ddd709f10b63744032302ca3597d3/jim.c#L5483 https://github.com/msteveb/jimtcl/blob/da293a1eef2ddd709f10b... [2] http://jim.tcl.tk/fossil/doc/trunk/Tcl_shipped.html#_garbage_collection_references_lambda_function http://jim.tcl.tk/fossil/doc/trunk/Tcl_shipped.html#_garbage...