Re: Adding garbage collection to C++

In article 92-08-093 tmb@idiap.ch writes:


      You don't need a language extension, nor do you need "garbage
      collection only [to] happen if [you] specifically ask for it". Simply
      retain a pointer to the object in the address space of A. In fact, you
      can encapsulate this behavior nicely inside your "send" procedure.


The moderator replies:


      [So how do you ever collect storage that's ever been shared between two
      threads? In fairness, this isn't unique to C -- it'd be a problem in any
      situation where you have a shared heap with unshared pointers. -John]


That's less a language problem and more a "political" problem.


In the threaded case (lightweight) processes, there is generally no
problem (except for the implementor), since the GC knows about threads
(examples are Lucid CommonLisp and Parc's PCR).


In the shared memory case, a GC (in particular, a conservative GC) will be
happy to scan the stack/heap of the other process for potential references
to its own data. It helps, of course, if the valid addresses in each
process' address space are non-overlapping...


If processes can't easily examine each other's memory, in particular, if
there is a slow network connection between the two processes, you may want
to use other kinds of mechanism. For example, when process 1 sends a
reference to an object in process 1's address space to process 2, process
1 may promise to keep that data alive until process 2 tells process 1 that
it's OK to get rid of it. To automate reclamation inside process 2,
process 2 can put the reference to the object in process 1 into an object
with some GC finalization procedure; the finalization procedure informs
process 1 that the object is no longer needed.


This kind of protocol is actually already used routinely. For example,
X resources held by languages with garbage collection are often freed
explicitly by GC finalization.


This may sound as if the presence of GC complicates threading, shared
memory, or network communications. I think that impression is false.


As I said in my posting quoted above, you can always and trivially disable
GC for some object by holding on to a pointer to it; this gets you back to
the non-GC case. But if you do have GC in your language, it turns out that
you have a variety of mechanisms (some of which are given above) at your
disposal to make it work even across process and network mechanisms, which
I find is a plus, not a minus.


Thomas.
--

Return to the comp.compilers page.
Search the comp.compilers archives again.