No registered users in community xowiki
in last 10 minutes
in last 10 minutes
[Xotcl] Re: [Xotcl] Re: [Xotcl] Garbage Collector in Xotcl
From: Kristoffer Lawson <setok_at_fishpool.com>
Date: Mon, 21 May 2001 20:37:33 +0300 (EEST)
On Mon, 21 May 2001, Uwe Zdun wrote:
> I'm not sure that Tcl_Objs are the best implementation variant for such a GC
> scheme, because of (a) shimmering (which may cause at least heavy performance
> problems) and (b) if some string with the same name exists, the object does
> not get deleted.
I believe shimmering will actually be quite a small problem as in Tcl
objects the string version of an object is kept anyway and if this
does not change, no shimmering should occur at any point. At least
this is how I think it happens.
(b) is also not really a problem. With GCed objects the names should
also be generated and unique and thus not conflict with other objects. Hm,
Tcl should probably provide a way of creating objects which are not shared
on the basis of their string content... Maybe this was one of the changes
Feather was going to make.
By far the most difficult problem is the fact that many callback systems
take strings as scripts and Tcl strings are not currently structured in
any way. So for example:
after 1000 {[MyObject new] dostuff}
This will not work with GCed objects. The new MyObject will be GCed
immediately after the call to "after". OK, this is contrived, but there
are more dangerous situations where this can occur. This was one major
problem with the systems in Feather and has to be taken into account. The
only long-term solution I can think of is for Tcl to structure strings
into trees (sometime in the future) and thus keeping references to objects
even when they become a part of another string (and do not exist
elsewhere).
I do agree that GCed objects would be a good thing. GC simply makes a lot
of things much much easier. I'm not quite sure how critical the above
problems are, but it's worth considering. Object aggregation actually
removes a lot of the need for GC, but it's not perfect either.
- ---------- = = ---------//--+
| / Kristoffer Lawson | www.fishpool.fi|.com
+-> | setok_at_fishpool.com | - - --+------
|-- Fishpool Creations Ltd - / |
+-------- = - - - = --------- /~setok/
Date: Mon, 21 May 2001 20:37:33 +0300 (EEST)
On Mon, 21 May 2001, Uwe Zdun wrote:
> I'm not sure that Tcl_Objs are the best implementation variant for such a GC
> scheme, because of (a) shimmering (which may cause at least heavy performance
> problems) and (b) if some string with the same name exists, the object does
> not get deleted.
I believe shimmering will actually be quite a small problem as in Tcl
objects the string version of an object is kept anyway and if this
does not change, no shimmering should occur at any point. At least
this is how I think it happens.
(b) is also not really a problem. With GCed objects the names should
also be generated and unique and thus not conflict with other objects. Hm,
Tcl should probably provide a way of creating objects which are not shared
on the basis of their string content... Maybe this was one of the changes
Feather was going to make.
By far the most difficult problem is the fact that many callback systems
take strings as scripts and Tcl strings are not currently structured in
any way. So for example:
after 1000 {[MyObject new] dostuff}
This will not work with GCed objects. The new MyObject will be GCed
immediately after the call to "after". OK, this is contrived, but there
are more dangerous situations where this can occur. This was one major
problem with the systems in Feather and has to be taken into account. The
only long-term solution I can think of is for Tcl to structure strings
into trees (sometime in the future) and thus keeping references to objects
even when they become a part of another string (and do not exist
elsewhere).
I do agree that GCed objects would be a good thing. GC simply makes a lot
of things much much easier. I'm not quite sure how critical the above
problems are, but it's worth considering. Object aggregation actually
removes a lot of the need for GC, but it's not perfect either.
- ---------- = = ---------//--+
| / Kristoffer Lawson | www.fishpool.fi|.com
+-> | setok_at_fishpool.com | - - --+------
|-- Fishpool Creations Ltd - / |
+-------- = - - - = --------- /~setok/