lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]


Roberto Ierusalimschy:
> PS: what about stop arguing about subtleties in the definition of
> "memory leak" and start working on a good algorithm to implement a more
> "desirable behaviour"?

Rici already has proposed one. If I remember correctly...

o Basically, whenever a table that is partially weak (weak-key &
strong-value, or strong-key & weak-value) is marked by the gc, the strong
link may not (yet) be followed if the weak link points to an object that has
not yet been marked (since that object may yet disappear, removing the
key/value pair).

o Instead, the location of the key/value pair is chained into a list in the
header of the weakly referenced table (presumably this list-chain memory
would already be a pre-allocated part of the table structure since this all
occurs during gc).

o Later, when that weakly referenced table is marked, a back-scan is done of
the key/values in its chain to mark the strong links (since the weak link
now points to a marked object that will not disappear).

o At the end of garbage collection, after the gc has traversed all links,
all unmarked objects are removed (standard gc). Additionally, any such
removed tables that still retain a back-link chain will also remove those
key/value pairs from their table (since the the weak link obviously points
to an object that is being removed).

o That handles the weak-strong & strong-weak problem. Presumably a weak-weak
table would also make use of this exisiting back-link list to remove
key/value pairs that have a disappearing weak link.


Sorry if you thought I was suggesting a 'memory leak' per se. What I was
trying to do was add support for Rici's astute observation that the current
weak link system has a certain non-intuitive behaviour under certain
circumstances... with the hope that the authors might consider it worthy of
addition when the Lua5.1 incremental gc is written.

*cheers*
Peter Hill