home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / compiler / 1402 < prev    next >
Encoding:
Text File  |  1992-08-18  |  3.1 KB  |  68 lines
  1. Newsgroups: comp.compilers
  2. Path: sparky!uunet!think.com!spdcc!iecc!compilers-sender
  3. From: tmb@arolla.idiap.ch (Thomas M. Breuel)
  4. Subject: Re: Adding garbage collection to C++
  5. Reply-To: tmb@arolla.idiap.ch (Thomas M. Breuel)
  6. Organization: IDIAP (Institut Dalle Molle d'Intelligence Artificielle
  7.     Perceptive)
  8. Date: Tue, 18 Aug 1992 17:18:07 GMT
  9. Approved: compilers@iecc.cambridge.ma.us
  10. Message-ID: <92-08-101@comp.compilers>
  11. References: <92-08-092@comp.compilers> <92-08-093@comp.compilers>
  12. Keywords: GC, parallel
  13. Sender: compilers-sender@iecc.cambridge.ma.us
  14. Lines: 52
  15.  
  16. In article <92-08-093@comp.compilers> tmb@idiap.ch writes:
  17.  
  18.    You don't need a language extension, nor do you need "garbage
  19.    collection only [to] happen if [you] specifically ask for it". Simply
  20.    retain a pointer to the object in the address space of A. In fact, you
  21.    can encapsulate this behavior nicely inside your "send" procedure.
  22.  
  23. The moderator replies:
  24.  
  25.    [So how do you ever collect storage that's ever been shared between two
  26.    threads?  In fairness, this isn't unique to C -- it'd be a problem in any
  27.    situation where you have a shared heap with unshared pointers. -John]
  28.  
  29. That's less a language problem and more a "political" problem.
  30.  
  31. In the threaded case (lightweight) processes, there is generally no
  32. problem (except for the implementor), since the GC knows about threads
  33. (examples are Lucid CommonLisp and Parc's PCR).
  34.  
  35. In the shared memory case, a GC (in particular, a conservative GC) will be
  36. happy to scan the stack/heap of the other process for potential references
  37. to its own data. It helps, of course, if the valid addresses in each
  38. process' address space are non-overlapping...
  39.  
  40. If processes can't easily examine each other's memory, in particular, if
  41. there is a slow network connection between the two processes, you may want
  42. to use other kinds of mechanism. For example, when process 1 sends a
  43. reference to an object in process 1's address space to process 2, process
  44. 1 may promise to keep that data alive until process 2 tells process 1 that
  45. it's OK to get rid of it. To automate reclamation inside process 2,
  46. process 2 can put the reference to the object in process 1 into an object
  47. with some GC finalization procedure; the finalization procedure informs
  48. process 1 that the object is no longer needed.
  49.  
  50. This kind of protocol is actually already used routinely. For example,
  51. X resources held by languages with garbage collection are often freed
  52. explicitly by GC finalization.
  53.  
  54. This may sound as if the presence of GC complicates threading, shared
  55. memory, or network communications. I think that impression is false.
  56.  
  57. As I said in my posting quoted above, you can always and trivially disable
  58. GC for some object by holding on to a pointer to it; this gets you back to
  59. the non-GC case. But if you do have GC in your language, it turns out that
  60. you have a variety of mechanisms (some of which are given above) at your
  61. disposal to make it work even across process and network mechanisms, which
  62. I find is a plus, not a minus.
  63.  
  64.                     Thomas.
  65. -- 
  66. Send compilers articles to compilers@iecc.cambridge.ma.us or
  67. {ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
  68.