3.4 event system holding objects?
John W. Sarkela
sarkela at sbcglobal.net
Sat Feb 8 15:22:50 UTC 2003
Well, let's not forget that the system was designed for dependents to
release their dependencies. If one declares *any* kind of dependency,
one should explicitly release that dependency when the object
is no longer being observed. This is as true for #when:send:to: as
it is for #changed:/#update:.
I haven't looked at the SUnit tests that finally made it into the
but when first written they most certainly included tests for all of the
As for comparing message selectors (eg #when:evaluate: v.
it is a dangerous thing to presume implementation consequences.
Messages and selectors are very much language/program design
considerations, considerations which should be completely distinct
from the underlying language/program implementation issues.
I would infer that your real consideration is the use of
rather than evaluable actions in the implementation of actionMaps.
I know of 24/7 apps (written in VSE) using the an evaluableAction
based approach that do not have any memory leaks.
I'm with Bob, let's look at your PointerFinder results and debug
the code that isn't releasing dependencies when it should.
:-}> John Sarkela
On Saturday, February 8, 2003, at 02:26 AM, Bob Arning wrote:
> If events are responsible for keeping garbage around, then there are
> likely two reasons:
> 1. That events are implemented with strong references that need to be
> explicitly released, but are not.
> 2. The events are written in such a way as to carry extra baggage that
> might otherwise have been collected.
> To see which of these might be behind the bloat you are seeing, it
> might help if you posted the result of one of your PointerFinder
> On Sat, 8 Feb 2003 02:33:45 -0500 "Bill Schwab" <schwabw at sprynet.com>
>> I did a little more digging into that bloated image I mentioned a few
>> days ago. First, I verified that I didn't have a large number of
>> lingering Process-es holding things in the image. Then I did some
>> checking with the PointerFinder and it kept leading to events
>> associated with Wonderland actors (the objects that are most
>> notably lingering in the image).
>> Some browsing in 3.4 (the problematic image) and my slightly
>> older 3.2 image reveals that my 3.4 image includes
>> Object>>when:evalaute, and that #when:send:to: and friends are
>> written in terms of it instead of #when:perform: as in 3.2. I find
>> suspicious because #when:evaluate: was removed from Dolphin
>> quite some time ago, specificially because it was causing
>> problems with large networks of objects that were immune to the
More information about the Squeak-dev