Re: How should we deal with weak refs to finalizable objects? (was: Re: [PATCH] Bugfix and drop weak references to finalizable objects (was: Re: [PATCH] thread-safe handling of asynchronous events))

[Andy Bennett]

Hi,

> I think this clears things sufficiently up.

Please excuse me if I am missing some details...


> Strong references are already ensured to be gone
> and weak references are cleared using the incantations that sjamaan
> (in his wisdom) proposed

What is the definition of a weak reference in this case?


One definition is that weak references only refer to the object if there 
are one or more strong references to the object.

In this case, all the strong references are gone before the finaliser runs 
and therefore all the weak references are semantically invalid already.

Whilst the finaliser is running there are no strong references to the 
object but it's possible (if the finaliser decides to resurrect the object) 
that there will once again be a strong reference to the object (e.g. if the 
finaliser set!s it).

But then, as you say, it's reincarnated: a new object that will never be 
more than equal? (and certainly not eqv? or eq?) to the old one.

Everything's consistent in this model because the references that the GC 
has to objects are neither "weak" nor "strong" but merely an implementation 
detail hidden from the outside.

This seems to be the definition that sjamaan is using.



Another definition is that weak references can refer to an object that is 
still "in memory".

This way lies disaster because then the semantics of weak references are 
dependent on specific implementation details.




I think here we're struggling with the atomicity of the garbage collector 
because the finaliser is special user code that executes inside the garbage 
collector's "transaction" and that code has all the power and capabilities 
of any other scheme code.



What happens if there are a circular list of objects all of which have 
finalisers?

The CHICKEN GC usually handles circular lists well, but when this one is 
collected (i.e. there are no external strong references to the list 
anymore) all its members come up for finalisation at the same time.

Which order are the finalisers called in?

...and which of the other objects can be seen from the object that is 
finalised first?


This is similar to the argument above about the correct definition of weak 
pairs.

To preserve atomicity there needs to be no "happens before" or "happens 
after" relationships between things that happen in a single GC cycle 
(transaction).

If weak pairs are not *already* invalid by the time the finaliser runs then 
it's possible to see into the GC transaction because the weak pair 
invalidation can be observed to "happen after" the GC cycle.

When the managed memory for the circular list is freed it does not matter 
precisely which order it is freed in because there are no side effects of 
freeing it and it all happens in a single GC cycle.

But when the finalisers are run the user's code will see these objects in 
various different states depending on the order.


So how can we finalise a circular list of objects all of which have 
finalisers and still maintain atomicity?

The docs say the order is "undefined".
It seems that the best way to finalise this structure is to explicitly 
break all the strong references between components of the list (as we do 
for external weak references) before any of the finalisers are called.



It may also improve the memory model if we define the object that the 
finaliser receives as a "copy" of the object that has ("already") been 
garbage collected.





Best wishes,
@ndy

--
andyjpb@ashurst.eu.org
http://www.ashurst.eu.org/
0x7EBA75FF