tcl and conservative GC?

kurt_stephens@black_guard.swissbank.com (Kurt Stephens)
Fri, 1 Jul 1994 18:40:20 GMT

          From comp.compilers

Related articles
tcl and conservative GC? kurt_stephens@black_guard.swissbank.com (1994-07-01)
Re: tcl and conservative GC? chrisa@world.std.com (1994-07-02)
| List of all articles for this month |

Newsgroups: comp.lang.tcl,comp.compilers
From: kurt_stephens@black_guard.swissbank.com (Kurt Stephens)
Keywords: interpreter, GC
Organization: Swiss Bank Corporation CM&T Division
Date: Fri, 1 Jul 1994 18:40:20 GMT

    From what I can gather from Ousterout's TCL book and package examples,
TCL cannot be used as a command language for systems that use conservative
garbage collectors (CGCs).


    This is due to the fact that TCL "values" are stored as null-terminated
strings; such strings cannot hold all machine pointers in a natural binary
form. (See thread "'conservative' GC == 'risky' GC" in comp.compilers.)


    Any "packages" which encode pointers to gc-allocated "objects" as
strings "throw away" the pointer that a conservative collector might find
to indicate a reference to the object.


    For example: imagine an "action-oriented" package that allocates new
objects from a CGC and encodes the object's pointer as a string:


    A TCL command "gc-alloc" invokes a C procedure that allocates (from a
GC) a pointer to an object and encodes it as a string by using
sprintf(interp-> result, "ptr@%p", gcmalloc(size)); an object allocated at
address 0x12345678 might be encoded as "ptr@0x12345678"; the binary
sequence for pointer 0x12345678 is lost and the object might be collected
while an encoded pointer still exists.


    Here are a few solutions I came up with:


1. The CGC supports programmer-defined mark callbacks, the callback could
scan each marked object for embedded strings in the form "ptr@xxxxxxxx"
and try to mark any gc-allocate objects at 0xXXXXXXXX. Roots should be
scanned in the same manner.


2. TCL encodes values as explict-length strings. Pointers can be encoded
as "ptr@xxxxxxxx\0XXXX" where "xxxxxxxx" is hex string for the pointer,
and the XXXX is the binary bytes of the 32-bit pointer. This format could
still be interpreted as a null-terminated array ("ptr@xxxxxxxx\0") for
printing, comparision, etc. Will the GC will only find binary pointers at
an expected alignment? What about pointer alignments in TCL arrays?
Yikes!!! Changing TCL to use explict-length strings would be too much
work.


    TCL also needs an API for specifing memory management system hooks;
replacements for malloc(), realloc(), and free(); something for TCL7.4?


Any comments or workarounds? Post responses to comp.lang.tcl.


Kurt A. Stephens
ION, Inc. @ Swiss Bank Corp Chicago
stephens@il.us.swissbank.com
--


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.