# Operators

"Robert J. Brown" (rj@eli.wariat.org)
Fri, 12 Apr 1996 01:01:17 PDT

- Messages sorted by:[ date ][ thread ][ subject ][ author ]

    >>>>> "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  ------