Re: Studying defobj and Zones and thinking about memory leaks

[glen e. p. ropella]

At 09:46 AM 10/29/99 -0500, you wrote:
> But there is a danger of memory leaks using this approach, because if
> you drop the newAgent, and don't individually eliminate the objects it
> has created, then you cause a leak.

Well, once again, it's good programming practice that
should save the day, here.  The ... ahem... proper use
of the Drop method recommends that you override the implementation
of drop in your Agent class such that, when called, it walks
through the agent's instance variables and drops each one,
in turn.  So, the *risk* of memory leaks lies in the assumption
that the computer knows more than it really does.  You have
to tell it how to drop agents.

Now, Zones can be used to aid you in telling the computer how
to do that.  If, for each agent, you instantiate a Zone as
one of it's instance variables, and then all objects you
allocate as part of that agent get allocated in that zone,
then all your drop method has to do is drop that zone.

<Philosophy>
Of course, the question arises as to why we don't just
FORCE all swarm modelers to do this by installing it
permanently into the infrastructure...  Well, the caveat,
here is that something allocated and "owned" by one
agent (say, A) can be accessed by another agent (say,
B) either by agent A explicitly sending the pointer
to B or by B instantiating a probe into A.  The probe
case is already handled by defobj's drop notification
mechanism.  But, in the explicit passing case, unless
agent B subscribes to the drop notification list, you
stand the chance of seg faults if B tries to access the
dropped object.

We could also push a mechanism for that down into the
infrastructure; but, if we go that far, we may as well
implement a general garbage collection mechanism.  And
none of these issues are easy to implement in such a
way as to *aid the modeler*, which is Swarm's overriding
goal for any "feature" of the system.  Restrictions on
how memory is allocated and accessed may very well aid
the programmer and a lack of restrictions may very well
inhibit the programmer.... but do they aid or inhibit
the modeler?

This kind of "transparent boundary," loose-OO is both
good and bad, of course.  Suffice it to say that it's done
that way to provide the most flexible modeling platform
possible.  Swarm purposefully teeters on the edge between
modeling and programming.  The finer and finer we can
nail that edge, the more successful we'll be.  We don't
want to go whole hog one way or the other or ignore the
fact that the edge exists.  We wouldn't be any different
from any other software package, if we did that.
</Philosophy>

glen

--
glen e. p. ropella =><= Feeding the hamster wheel.  Hail Eris!
Home: http://www.trail.com/~gepr                (505) 424-0448
Work: http://www.swarm.com                      (505) 995-0818

                 ==================================
  Swarm-Support is for discussion of the technical details of the day
  to day usage of Swarm.  For list administration needs (esp.
  [un]subscribing), please send a message to <address@hidden>
  with "help" in the body of the message.