[gclist] CORBA C++ bindings and garbage collection

[Bryan O'Sullivan]

j> Here, what you are saying is that the collector has no easy way of
j> knowing when there are no more live remote references to servants,
j> right?

Yes.  If one client passes an IOR (CORBA-speak for a reference to a
server-side object) to another, but the second doesn't actually open a
connection to the server, then the server has no way of knowing that
the second has a reference to it.

j> I was just hoping though, that local GCs would be good enough to
j> simplify the semantics of memory allocation/deallocation for C++
j> CORBA systems.

For client-side code, you could simply try linking in something like
Boehm-Weiser and seeing if it worked.  I would be surprised if it
didn't work for purely client-side memory management.

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

j> Does Java RMI suffer from this problem?

Yes.  Jini (which I mentioned in my earlier article) uses leasing of
activatable objects to sidestep the problems of DGC in large RMI
systems.

j> Given that many people have spent much energy over years to tackle
j> distributed computing problems, I wondered whether it was realistic
j> to believe that Java RMI simply made these problems vanish.

Many aspects of RMI are fantastically useful, including DGC.  You just
have to assume that DGC will cause your scalability curve to assume
unexpected and catastrophic shapes after a point, and that said point
will always occur earlier in the curve than you'd like.  If your app
never reaches that point, then all is peachy.

	<b