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

[Marco Gidde]

"Juan Jose Garcia-Ripoll"
<jjgarcia at users.sourceforge.net> writes:
>> 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 association itself can be a hash table. Bear in mind that the
> garbage collector has two kinds of allocated memory: atomic and
> non-atomic. The former is not scanned for pointers. This also relates
> to your second question/
>
>> 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.
>
> You do not need GC_general_register... to hide a pointer. It suffices
> to allocate an object using alloc_atomic() or the equivalent
> Boehm-Weiser function. It is then _ECL's_ responsibility to ensure
> that the value in the allocated memory is correct. But if we use
> finalizers to clean that value ourselves, that's fine.
>
> Another reason why I like the idea of keeping all weak pointers in
> some association is that it adapts well to other approaches, such as
> inserting our own sweep phase and cleaning the pointers ourselves.
> This is just a hypothetical step, but it would be just one line of
> code to change the Boehm-Weiser GC to let us do so.

The meaning of alloc_atomic() and GC_general_register_disappearing_link
was already clear - I used them in my weak pointer patch. It seems there
is some disagreement between us concerning who should do the "dirty"
work of cleaning up the references: my idea was that if there is no need
for finalizers to implement the hash table, the clean up could just as
well be done by the GC (e.g. GC_general_register..). As I understand it,
GC_general_register.. is nothing more than a specialized finalizer that
nullifies a pointer if some other object is garbage collected. 

On the other side you would like to control the cleanup from within ECL,
which is also OK, but not what I would do. But in the end you are the
maintainer and I guess you have some further ideas how to optimize the
GC for ECL's purposes. :-)

One technical problem I see is using the hash table to implement the
association for the weak pointers. It seems that you have to support
three different kinds of hash keys then: regular pointers, weak pointers
for the weak hashes and some kind of hidden pointers for the
implementation of the weak pointers. Or would you use some
simplified/special purpose hash implementation only for the latter?

>>  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.
>
> I had a look at the code and it is possible to make not too intrusive
> implementation. The idea is that the notion of weak hash tables is
> only used in thre places:
> - When extracting the hash key
> - When comparing two keys
> - When using the key value in things like maphash
>
> The first two are solved by adding three more hash table kinds:
> htt_weak_eq, htt_weak_eql, htt_weak_equal, htt_weak_equalp and
> changing the associated switch statements. The last one must be
> handled by some magic in the si_hash_table_iterate and cl_maphash.

My impression was that it might be even possible to simply integrate
t_weakpointer in the _hash_eq.. functions. However it's done, additional
to that ecl_search_hash (and cl_maphash/si_hash_table_iterate) would
probably be responsible for removing hash entries with a garbage
collected value.

Seems we're getting closer to an implementation ;-)


Regards, Marco