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

[Marco Gidde]

"Juan Jose Garcia-Ripoll"
<jjgarcia at users.sourceforge.net> writes:

> On Thu, Apr 24, 2008 at 9:32 PM, Marco Gidde <marco.gidde at tiscali.de> wrote:
>>  ... the user can easily turn of the internal object finalization
>>  (ie. closing streams) with
>
> Yes, that is a feature, not a big issue. You should set it to T if you
> want the default finalizing code. But perhaps this semantics is not
> very clear.

The problem IMHO is that user code might do it unintentionally: one
might register a finalizer as some kind of safety net. Later, under
certain conditions, it might be possible to explicitly call the
finalizer and - to avoid the GC overhead - unregister it again. It can't
be expected that users know those types, for which ECL defines its own
finalizers, so to be sure, user code always had to (SET-FINALIZER T) or
check it with GET-FINALIZER before registering its own. This behaviour
should at least be made explicit in the documentation because I had not
expected a finalizer on a freshly created object.

>>  Weak pointers on the other hand seem to be quite simple: define a new
>>  type with a pointer to cl_object, allocate this cell with malloc_atomic
>>  and let GC_general_register_disappearing_link nullify it if appropriate.
>>  With these building blocks implementing weak hash tables is still some
>>  amount of work, but at least doable.
>
> My understanding is that this is not efficient and that disappearing
> links should be avoided if possible. I got this feedback from the GC
> mailing list long ago. Now I am not sure what they meant, as having a
> look at the garbage collector's code, they are implemented just like
> finalization.

I didn't take efficiency into account for the moment, just looked what
is there and what might be possible with that. Currently the situation
is just like this: if an application requires weak pointers or hashes,
ECL is not a choice, which is a bit sad.

> However, the real problem is that for scalable weak hashes it is not
> enough to have weak pointers. This is described here:
> http://www.haible.de/bruno/papers/cs/weak/WeakDatastructures-writeup.html
> and here http://www.haible.de/bruno/papers/cs/weak/WeakDatastructures-presentation.pdf

Thanks for the pointer. I see there is more about weak data structures
than I naively expected, but on the other side: with a level 2
implementation ECL would be in pretty good company. :-)

> Perhaps the simplest solution is, since we do not have control over
> the "sweep" phase in the collector, to go for finalization. One could
> add an "internal" finalization phase as you describe, storing objects
> with weak pointer references in a hash table and updating this table
> and clearing the associated pointers and conses when the object is
> finalized.

This seems to be all we can do with an external garbage collector.

But now I ask myself how to add weak hashes without messing up the code
in hash.d with lots of checks for weak keys/values and letting the user
pay for a feature he/she usually don't want. Still have to think and
maybe start with the simple things, but don't hold your breath - time is
scarce over here :-/


Regards, Marco