[Ecls-list] Finalizer, weak pointer, weak hashes etc.

[Marco Gidde]

"Juan Jose Garcia-Ripoll"
<jjgarcia at users.sourceforge.net> writes:
> On Sun, Apr 27, 2008 at 1:16 PM, Marco Gidde <marco.gidde at tiscali.de> wrote:
>> Found some time yesterday and implemented the suggested stuff. Attached
>>  are two patches, the first implements weak pointers, the other makes
>>  internal and user finalizers distinct.
>
> The second patch will probably be applied without further changes.
> There is one issue left, which is to make sure that the pointer stored
> in the finalizer is considered as a root when garbage collecting:
> otherwise the library will simply ignore it.

In what way is this different from the original implementation? Or do
you refer to the case where the cons is (T . NIL), so only the standard
finalizer is invoked? Should the cons cell in this case be added to
cl_core.to_be_finalized without registering group_finalizer as a
finalizer? 

> Regarding the other things, the implementation I had in mind would
> keep an association from objects to weak pointers. When creating a
> hash table of type weak, for each key we would look up the association
> and use the weak pointer as a key. From time to time these hash tables
> would have to be cleaned up, removing entries with weak pointers that
> are empty. This can be done at lookup time or in some other way.
>
> Such an implementation would not be very obstrussive and would remove
> the need to keep track which objects are stored in which hash tables.
> Because the other alternative is to change the data for the finalizer
> whenever an object is added or removed from a weak hash table.
>
> The biggest inconvenient is that weak hash tables can only be
> associated by EQ -- or perhaps one can change this.
>
> I also find the idea of having unique weak pointers interesting in
> itself. It minimizes the overhead of weak pointers and uses  the fact
> that they should be inmutable structures (at least from the user's
> point of view)

I have a strange gut feeling with your approach, but probably I only
misunderstand something.

First of all I think that weak pointers are a useful data structure in
their own right - whether they are used or not as a building block for
weak hashes is another issue (brought up by me, though). EQ-ness of weak
pointers might be a nice property, but of course it has its price:
creation of a weak pointer would require scanning the association for
the object. The same would be necessary to retrieve the value from the
weak pointer - or the value must be stored in a second place, either
inside the pointer (as I did it) or in a reverse association. In either
case this second place also has to be invisible to the GC and thus must
be handled by GC_general_register_disappearing_link to avoid a dangling
pointer. I think that for most use cases of weak pointers this is too
much trouble: there will probably be only very few (1, 2 maybe 3?) of
them for a given object.

Moving the hash cleanup from the object finalizer to some other place(s)
seems to be a good idea. In fact I was thinking in terms of multiple
finalizers for a single object, like TRIVIAL-GARBAGE provides them, and
so keeping track of which objects are stored in which hash table wasn't
an issue for me. But of course this approach would cons like crazy - not
a good idea.

Restricting weak hash tables to only weak keys and :TEST 'EQ seems a bit
too much. I thought that the usual kinds of weaknesses with the
exception of :KEY-OR-VALUE could and should be supported with the full
range of test functions working on the key/value, not the weak
pointer. But I have to admit I still have no good idea about an
efficient and non intrusive implementation.


Regards, Marco