Garbage Collection and other things (belated)

[attila stalphonsos com]

[stuff by Owen and Michael re GC snipped]

This entire issue seems to be something that lots of groups trip over,
and everyone seems to go through exactly the same process.  In a
previous life, I implemented a C-based object representation with
a virtual machine and garbage collection, and stripped Tcl out of Tk
and embedded it into this representation, which had the interesting
property of being able to "wrap" C++ classes seamlessly, so that
we could use our own prototype-based object environment (ala SELF)
to build user interfaces with our objectified Tk for C++ classes which
had no clue that they were living in this garbage-collected environment.

Sound familiar?  Of course, gtk is a lot nicer than Tk, and gtk's
way of making it easy to integrate with other languages is different
and, I think, quite nifty.

Several points I'd like to raise:

+ Garbage collection is Hard.  Reference counts sound appealing, but
  they end up actually not being a good idea except in very specific
  circumstances.  Our environment started with a reference-count
  system, and we went through the entire process of realizing that
  this wasn't as good an idea as it sounds (and then found out that
  lots of people had found this out before -- take a good look at the
  GC literature).  We ended up with a much more sophisticated tri-color
  scheme with some modifications for dealing with the fact that we had
  objects that were "native" to different languages and object models,
  and that the entire environment was inherently multi-threaded.
  This sounds like it's more overhead, it but turns out that it performs
  much better, gives you more levers to tweak, and saves memory.  There
  is a lot of literature to suggest that GC'ed environments can
  out-perform explicit memory allocation.

+ There are tools out there that specifically attack the problem of GC,
  and do it pretty well.  The Boehm garbage collector from Xerox Parc
  comes to mind as being the most general. In retrospect, though I
  learned a lot by implementing several different kinds of GC, I
  would've have been better off had I just used Boehm's GC from the
  start.  It works with C and C++, threads, and will more or less do
  exactly what you want so long as you don't violate a few invariants,
  which are very clearly stated in his excellent papers.  It's worth
  looking at even if you don't use it.

+ It sounds to me like gtk and it's subsidiary libraries are slowing
  tending towards having ambitions much like the thing I built, with
  the exception of providing a VM for representing byte code: an
  object-oriented environment that easily integrates into a variety of
  languages and provides a rich, extensible pallate of UI components.
  The difference is that gtk started from the UI point of view, and is
  only object-oriented in a very loose sense, whereas we started from
  the point of view of the object representation, and merged an exiting
  UI toolkit into it.  Gtk is clearly more useful at this early stage
  in its development than our environment was for quite some time, and
  the open development model being followed is clearly superior to the
  one I fell into.  The entire object model issue, however, is only
  going to get more prominent, as people want to start adding widgets
  and using widgets the wrote in other languages, and the GC issue
  is definitely going to get worse the larger and more diverse the
  application base becomes.  I think that the core gtk people (and I'm
  not even sure who they are!) should seriously be thinking about these
  things, if they aren't already, and I encourgage them strongly to
  look very closely and deeply at the published literature.  Lots and
  lots of people have been down this and very closely related roads
  before, and I already see some previous pitfalls start to crop up.
  Don't reinvent the wheel, especially when others before you have
  found that it's not a good one (i.e. reference counts).

Pax,
	:: Sean Levy <attila@stalphonsos.com>

P.S. The environment I worked on was called BOS, the Basic Object
     System. It had a long and colorful, though woefully
     under-documented life.  The OOPSLA 97 procedings should have
     one of the more definitive papers on it, and I'm sure there
     are a couple of technical reports from ICES.CMU.EDU, nee
     EDRC.CMU.EDU.

	:: S.