home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / compiler / 1407 < prev    next >
Encoding:
Text File  |  1992-08-18  |  2.3 KB  |  48 lines
  1. Newsgroups: comp.compilers
  2. Path: sparky!uunet!zaphod.mps.ohio-state.edu!darwin.sura.net!jvnc.net!yale.edu!yale!mintaka.lcs.mit.edu!spdcc!iecc!compilers-sender
  3. From: pardo@cs.washington.edu (David Keppel)
  4. Subject: GC across address spaces (WAS: Adding garbage collection to C++)
  5. Reply-To: pardo@cs.washington.edu (David Keppel)
  6. Organization: Computer Science & Engineering, U. of Washington, Seattle
  7. Date: Wed, 19 Aug 1992 00:09:51 GMT
  8. Approved: compilers@iecc.cambridge.ma.us
  9. Message-ID: <92-08-106@comp.compilers>
  10. References: <92-08-092@comp.compilers> <92-08-093@comp.compilers>
  11. Keywords: C, GC, parallel
  12. Sender: compilers-sender@iecc.cambridge.ma.us
  13. Lines: 33
  14.  
  15. >bill@amber.ssd.csd.harris.com (Bill Leonard) writes:
  16. >>[How to garbage collect multi-threaded programs where some pointers to
  17. >> shared memory are kept in per-thread private storage]
  18.  
  19. tmb@idiap.ch writes:
  20. >[You don't need "garbage collection only if specifically asked for.
  21. > Just retain a pointer to the object in the address space of A.
  22. > In fact, you can encapsulate this behavior nicely inside your "send"
  23. > procedure.]
  24.  
  25. One of the big reasons for using GC is that it frees the programmer from
  26. managing object lifetimes explicitly.  Some parallel programming
  27. practicioners say (I think correctly) that figuring out lifetimes is, in
  28. general, substantially harder with parallelism than without.
  29.  
  30. Explicitly retaining a pointer will solve the problem but defeats one of
  31. the reasons for having GC in the first place.  Now the programmer of
  32. address space A must decide when address space B has finished with the
  33. memory and the pointer in A can be destroyed.  Some of the mental overhead
  34. can be masked by various protocols, but the pointer still comes at the
  35. programmer's expense.
  36.  
  37. The technique of ``keeping a pointer'' to prevent GC is good.  So is
  38. promoting storage from gc'able to non-gc'able.  Ideally, you keep a
  39. uniform programming model and the underlying implementation is optimized.
  40. In practice, you probably keep a uniform programming model but the
  41. implementors of libraries, stubs, etc., are forced to worry about the
  42. performance issues and choose implementations accordingly.
  43.  
  44.   ;-D on  ( Sharing memory with every process that's shared it )  Pardo
  45. -- 
  46. Send compilers articles to compilers@iecc.cambridge.ma.us or
  47. {ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
  48.