[gclist] CORBA C++ bindings and garbage collection

[Bryan O'Sullivan]

j> Does IDL to C++ language mapping rule out the use of garbage
j> collector in designing and implementing an ORB?

It's not the language mapping that rules out GC, it's the programming
model and the wire protocol.  IIOP has no facility for tracking the
number of clients talking to a server.  In order for a client be able
to talk to an object over the wire, it has to be explicitly exported
on the server side.

j> If the mapping does rule it out, then wasn't it a mistake for the
j> original mapping designers to not to consider garbage collection?

I don't think so.  Distributed garbage collection is a nice idea in
the abstract, but it comes with far too many problems to be something
you really want in a commercial setting.  Also, at the time CORBA was
being agglutinated, there were no commercially-noticeable languages
that supported GC in existence.

As to my claims of problems with distributed GC:

1. See figure 1.

2. No matter what algorithm you choose, it's really, really hard to
   get right.  I have never seen a distributed GC (and I've worked
   with, and near, several) that didn't have serious bugs, no matter
   how bright the people were who worked on it.  Of course, the bugs
   only show up in situations where you can't even log the problems,
   much less reproduce them later.  See figure 1.

3. Beyond simple reference counting (and its problems with messaging
   overhead and cyclic structures), any of the DGC algorithms I used
   to look at back when I stayed abreast of the literature were
   really, really hard to even understand.  None of the professors or
   grad students I knew around 1993 or so claimed to understand the
   most widely-respected DGC algorithm of the day (written, as I
   recall, by John Hughes).  See figure 1.

4. Since #2 means that everyone (to a first approximation) uses
   reference counting with heartbeats or lease renewals and a few
   other frills, you end up with a lot of cross-chatter in a large
   network that is nominally idle.  If your network gets busy, GC
   traffic starts to add appreciable overhead.  Oh, and now you have
   to think about debugging GC bugs in a 16-node cluster of live stock
   market trading servers.  See figure 1.

Perhaps you're getting the picture.  DGC is still a fruitful source of
research papers.  This should scare you.

The last project I worked on that used DGC was BEA's WebLogic Server,
a very profitable web application server.  When I left BEA, we had
been talking seriously for several months about turning off DGC
altogether.  The Enterprise JavaBeans programming model didn't require
DGC, even though it was nominally implemented on top of RMI, and EJB
has almost entirely displaced RMI as the distributed programming model
of choice for large Java apps.  The popularity of EJB made it very
tempting to kill off all of our DGC infrastructure and its horrible
Heisenbugs.

Prior to WLS, I worked on Jini (remember that?), where we effectively
handwaved away the intractable problems of DGC in large, semi-coherent
systems by requiring that clients explicitly maintain leases to server
objects.

j> When I was programming a bit with Java RMI and C++ CORBA, and I
j> kept thinking how simple memory cleanup task for Java RMI is,
j> compared to C++ CORBA ORB I was using.

There's no doubt that DGC makes programming seem nicer.  Right up
until it breaks irreproducibly in deployment or doesn't scale beyond a
handful of participants, at which point you can take your app out back
and shoot it.

j> I will appreciate any comments, answers and perspectives, unless
j> this topic has been beaten on before -- in which case I will be
j> happy and grateful just to be directed to an existing mail archive
j> dungeon.

Actually, I haven't seen much written about the theory-vs-practice
dichotomy in the DGC world.  Am I merely scaring the kids, or have
others also found it to be a tremendous headache in non-trivial cases?

	<b




(P.S.  Wondering where figure 1 was?
http://www.parc.xerox.com/csl/members/dourish/goodies/see-figure-1.html)