Garbage Collection catch-22 with blocks - Further complications

Peter Smet peter.smet at flinders.edu.au
Sun Jul 4 11:29:38 UTC 1999


Alan - and anyone else with an interest in blocks.
About the weakMethodContext:

>>Briefly, the solution involves defining a new subclass of MethodContext,
>>called WeakMethodContext, that uses a WeakArray to hold on to the
>>receiver.  A MethodContext will answer a new WeakMethodContext
>>with the same state in response to the message #asWeakContext.
>>Sending the message #beWeak to a BlockContext causes it to
>>replace its "home" context with "homeContext asWeakContext."
>>
>>I tested this briefly, and it seems to work.


I did some further testing, and found some interesting consequences. One is
that messages can get sent to the WeakArray rather than the receiver
contained in the WeakArray. I went through your new methods with a fine
tooth comb, and it seems to me you have all bases covered. Any calls to
receiver should be caught by your new method that returns the first element
in the WeakArray. I end up with a bizarre situation in the debugger caused
by a WeakArray not understanding a message. When I look at the 'self' that
the message is directed to it is the object contained in the WeakArray. This
can't be right, or the error would not have occurred in the first place. I
can only guess that there must be some optimization where the home context
receiver VARIABLE is accessed directly for doing the message send.
Unfortunately, I cannot see where this is happening. Does anyone know if
this guess is correct? Does the method context always use the receiver
method, or is direct variable access invoked by the compiler somewhere. How
would I override this?

I can send code that demonstrates the problem if needed.

Thanks for any help

Peter





More information about the Squeak-dev mailing list