MOO-cows Mailing List Archive
[Prev][Next][Index][Thread]

Re: Operators

>>>>> "Jefferson" == Jefferson M Dubrule <Jefferson.M.Dubrule@Dartmouth.EDU> writes:

    Jefferson> --- "Robert J. Brown" wrote: C++ has the idea of a
    Jefferson> "copy constructor" and uses it to instantiate temporary
    Jefferson> objects on the stack frame of the currently active
    Jefferson> procedure.  These objects have their destructor invoked
    Jefferson> when that procedure exits, since that is the end of the
    Jefferson> lifespan of the temporary object.  --- end of quoted
    Jefferson> material --- Hmm.  I was thinking of using
    Jefferson> x:_plus(y,temp), passing temp (a copy of x) to the
    Jefferson> function to use as a return value, and it would be
    Jefferson> recycled if unneeded.  This would be cool, but what if
    Jefferson> a real object got returned?  Would it be recycled, or
    Jefferson> would a temporary flag exist?  If a temporary flag
    Jefferson> existed, what if it got assigned to a property.  Would
    Jefferson> the temp flag disappear?  What if it were removed from
    Jefferson> the prop.  It should be recycled, right?  Should a
    Jefferson> reference count be kept, which recycles the object when
    Jefferson> references = 0?  It has to interface with some sort of
    Jefferson> recycler, as having invalid object numbers is
    Jefferson> considered bad form.  After carefully considering this,
    Jefferson> I got scared and ran away :) I'll consider it after all
    Jefferson> the other stuff I have already planned out is done.

Everything you have described here is why Lisp has an automatic
garbage collector.  Lisp is the grandaddy of all object oriented
languages, being the language that introduced the term "object" into
progamming jargon.  

Back in the good old days, memories were small, being measured in
kilobytes, and garbage collection proceeded by a mark and sweep
algorithm.  Now that memories are measured in tens or even hundreds of
megabytes, and applications are interactive, the lag caused by the
garbage collector is unacceptable.

With the development of "ephemeral" garbage collectors, this is no
longer such a problem.  I have worked for days on a Lisp machine
without doing a full fledged garbage collect, letting the ephemeral
garbage collector reclaim 90% of the garbage without intruding upon my
activities at all.  

A full fledged mark and sweep was an overnight pain in the neck, and
was only done after everything was definately working, and only after
a back-up copy of the pre-garbage collected program had been safely
saved to disk.  After the mark and sweep finished, the image was saved
again, then loaded and tested.  If it passed, it was used for
production.

Since a MOO is kept up for days, weeks, or even months (if you are
lucky!), and is used by many simultaneous users, a mark and sweep is
out of the question.  I do not know how effective an ephemeral-only
garbage collection would be in such a situation.  Perhaps the
literature can help here.

The problem, of course, is that a language and programming environment
must be designed from the beginning for a garbasge collector of this
sort to work.  That advantage is that nothing gets reclaimed unless it
is truly not referenced by anything.  Reference counts are not
reliable where you can have self referential structures, such as
circular lists, and recursive algorithms represented as data.  

Garbage collectors are for sloppy programmers.  Neat programmers spend
most of their time avoiding or fixing memory leaks.  Sloppy
programmers spend most of their time doing creative work.  :-)

-- 
-----------  "...  And the men went up and viewed Ai."  [Jos 7:2]  -----------
Robert Jay Brown III  rj@eli.wariat.org  http://eli.wariat.org  1 847 705-0370
Elijah Laboratories Inc;  759 Independence Drive;  Suite 5;  Palatine IL 60074
-----  M o d e l i n g   t h e   M e t h o d s   o f   t h e   M i n d  ------
References:
Home | Subject Index | Thread Index