[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: GC puzzler...
- From: Mark Hamburg <mhamburg@...>
- Date: Tue, 15 Feb 2005 12:44:27 -0800
Fixing the semi-weak table circularity problem would, I think, be a big win.
It makes encapsulation easier to implement. It makes it easier to associate
Lua data with userdata objects.
That being said, it's a messy problem as Rici Lake's messages point out. The
contingency list approach is probably the best bet and it isn't exactly
simple or lightweight to implement.
That being said, if we consider the common case where an object needs to be
the key in exactly one weak-keyed table, there are workarounds that
generally involve per-object metatables that either contain the value side
or contain a link to the value side. For example, the encapsulation
technique I posted to the Wiki a few weeks ago relies on using the following
construct to link a proxy object to the implementation object:
1. A protected metatable per proxy containing a pointer to the
implementation. This exists so that the GC will mark the implementation if
it marks the proxy.
2. A fully-weak table mapping proxy objects to implementation objects. This
exists since a protected metatable is protected even from the code that
created it.
If it isn't feasible to fix the general problem, are there things that could
be done to fix the more specialized problem of wanting one link without
overloading the metatable mechanism? (If you have a lot of entries in the
metatable, you may not want to make a copy of it per object.) Options might
include:
* Recursive searching of metatables -- i.e., use standard indexing rather
than raw indexing to look for metamethods. This would make per object
metatables cheaper from a space standpoint though they would be more
expensive from a runtime standpoint.
* An additional link per object to an associated object. For space reasons,
this could be handled via a table that the GC knew about rather than
spending the space for an additional pointer in every object.
* A metatable entry __assoc that would lead to a fully weak table. When
marking an object, the GC would also mark obj.mt.__assoc[ obj ] (where
obj.mt is the object metatable). This could be made reasonably efficient by
using the same logic as the other fast metamethods.
Mark