home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / compiler / 1376 < prev    next >
Encoding:
Internet Message Format  |  1992-08-15  |  2.9 KB
  1. Path: sparky!uunet!cis.ohio-state.edu!pacific.mps.ohio-state.edu!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!sdd.hp.com!wupost!gumby!yale!mintaka.lcs.mit.edu!spdcc!iecc!compilers-sender
  2. From: bill@amber.ssd.csd.harris.com (Bill Leonard)
  3. Newsgroups: comp.compilers
  4. Subject: Re: Adding garbage collection to C++
  5. Keywords: C++, GC
  6. Message-ID: <92-08-076@comp.compilers>
  7. Date: 14 Aug 92 21:13:51 GMT
  8. References: <92-08-044@comp.compilers> <92-08-068@comp.compilers>
  9. Sender: compilers-sender@iecc.cambridge.ma.us
  10. Reply-To: bill@amber.ssd.csd.harris.com (Bill Leonard)
  11. Organization: Harris CSD, Ft. Lauderdale, FL
  12. Lines: 42
  13. Approved: compilers@iecc.cambridge.ma.us
  14.  
  15. kelvin@kickapoo.cs.iastate.edu (Kelvin Don Nilsen) writes:
  16. > >[I'd be interested how you trace through unions containing pointers. -John]
  17. > 
  18. > We have implemented copying garbage collection for the C++ language
  19. > standard, making only a few minor restrictions on normal C++ usage.  We
  20. > are able, for example, to compile Gnu groff by fixing fewer than five
  21. > "sloppy" programming tricks.  We handle unions that may contain either
  22. > pointers or raw seething bits by adding an explicit tag to distinguish
  23. > between the two.  Each assignment to one of these unions incurs the cost
  24. > of updating the tag.  We do not check the tag on reads.  Further, we do
  25. > not update the tag if the union is known always to contain pointers, or
  26. > always to contain raw seething bits.
  27.  
  28. This would be a pretty nasty thing to do if one is using the union to map
  29. data stored in an external device, such as data read from a file or in the
  30. case of memory-mapped I/O.  You may consider this a "minor restriction",
  31. but there are many programmers, whose applications would become invalid,
  32. who would disagree with you.
  33.  
  34. We have come across another case wherein garbage collection becomes
  35. difficult, if not impossible.  We have two C++ programs that communicate
  36. through shared memory.  There are some cases where program A allocates an
  37. object, then sends a pointer to that object (through shared memory) to
  38. program B, who stores the pointer in a variable that does not reside in
  39. shared memory.  Program A then forgets about the object (i.e., it retains
  40. no pointers to it).  Program B will randomly send messages to this object
  41. by sending the pointer back over to program A, but otherwise program A
  42. will have no references to this object in *its* address space.
  43.  
  44. I think you basically have to give up on garbage collecting such strange
  45. objects.  But their existence forces me to advocate that garbage
  46. collection only happen if I specifically ask for it (thus begging for
  47. language extensions), rather than automatically.
  48. -- 
  49. Bill Leonard
  50. Harris Computer Systems Division
  51. 2101 W. Cypress Creek Road
  52. Fort Lauderdale, FL  33309
  53. bill@ssd.csd.harris.com
  54. -- 
  55. Send compilers articles to compilers@iecc.cambridge.ma.us or
  56. {ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
  57.