home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / lang / cplus / 12672 < prev    next >
Encoding:
Internet Message Format  |  1992-08-20  |  4.0 KB
  1. Path: sparky!uunet!kithrup!stanford.edu!snorkelwacker.mit.edu!bloom-beacon!eru.mt.luth.se!lunic!sunic!seunet!appli!niklas
  2. From: niklas@appli.se (Niklas Hallqvist)
  3. Newsgroups: comp.lang.c++
  4. Subject: Re: Garbage Collection for C++
  5. Message-ID: <2138@appli.se>
  6. Date: 20 Aug 92 20:32:43 GMT
  7. References: <1992Aug6.014619.2111@ucc.su.OZ.AU>     <DAVEG.92Aug13025629@synaptx.synaptics.com>     <1992Aug14.021547.15215@news.mentorg.com>     <DAVEG.92Aug14194411@synaptx.synaptics.com> <2009@appli.se>     <TMB.92Aug17204854@arolla.idiap.ch> <2135@appli.se> <DAVEG.92Aug20024
  8. Organization: Applitron Datasystem AB, GOTHENBURG, SWEDEN
  9. Lines: 74
  10.  
  11. daveg@synaptics.com (Dave Gillespie) writes:
  12.  
  13. :In article <2135@appli.se> niklas@appli.se (Niklas Hallqvist) writes:
  14.  
  15. :> >niklas@appli.se (Niklas Hallqvist) writes:
  16.  
  17. :> Of course, this means conservative GC is
  18. :> implementable on architectures where no integer type can hold a void pointer,
  19. :> but otherwise it is NOT.  Do I miss anything in my thinking?
  20.  
  21. :No, it's implementable only if you include some fine print warning that
  22. :such tricks will fool the garbage collector.  After all, there will
  23. :always be *some* things the garbage collector won't be able to get:
  24. :Suppose you allocate an object, mail its hex address to another user,
  25. :and then refer to it later when the user mails back a request including
  26. :that address?  (Not a good idea, I know, but it's a simple example of
  27. :the sorts of unusual cases one would run into.  By Max Skaller's
  28. :description, Microsoft Windows sounds like one of those "unusual"
  29. :cases...)
  30.  
  31. Actually, I will give up my role as the devils advocate here and now.
  32. Thomas has showed me (in private email) that it is possible for a GC
  33. implementor to obey the rules as stated in the ARM.
  34.  
  35. :It would probably be wise to say that any pointer which is stored as
  36. :an integer (or other non-pointer type) is not GC-safe.  This allows
  37. :the compiler to put non-pointers in a different area of memory that
  38. :the GC doesn't need to scan, if it so chooses.
  39.  
  40. If I understand you correctly, this is exactly the way to go, if we not
  41. which to change the rules.  If the compiler stores away every pointer
  42. casted to a non-pointer type in a region the collector can see, all these
  43. pointed-to objects will never be collected, and everything is fine.
  44. It even solves your "mail the hex address" problem :-)
  45.  
  46. :The point is, saying you can't make a 100% bulletproof garbage
  47. :collector should not be enough to veto the idea in C++.  It should
  48. :be enough to show that a) if you live by a fairly reasonable and
  49. :well-defined set of rules of "decent behavior," the feature will
  50. :work, and b) if you choose to ignore those rules, but don't use
  51. :the new feature anyway, it won't matter.  The latter is one of the
  52. :main reason I think GC-able allocation should be something a
  53. :program has to ask for, not the default.
  54.  
  55. I'm not against GC in C++, on the contrary, since I'm lazy I would
  56. probably be very glad if it went into the language.  I was merely
  57. trying to play the role of the devils advocate, with limited success,
  58. luckily :-)  Why? - you ask... Well, if we're going to keep the language
  59. portable we have to find the problematic sentences in the ARM and identify
  60. what needs to be done about them.  In this case we don't NEED to change
  61. anything, but it would HELP the GC implementors to loosen up the
  62. definition somewhat.
  63.  
  64. :> So you had read this section, and still think GC can be done, if the text
  65. :> isn't changed to something like:
  66.  
  67. I want to apologize to Thomas for this rather rude statement.
  68. He was right and I was wrong.  Excuse me!
  69.  
  70. :> "All pointer to integer conversions and back are implementation defined."
  71.  
  72. :How about "it is unsafe to cast a pointer to GC-allocated object to
  73. :a non-pointer type."  Even this is conservative, and I don't think
  74. :anybody would mind this mild restriction.  As long as GC-allocated
  75. :objects only come by explicit request, no old code will be broken.
  76.  
  77. Ok by me..
  78.  
  79. Niklas
  80. -- 
  81. Niklas Hallqvist    Phone: +46-(0)31-40 75 00
  82. Applitron Datasystem    Fax:   +46-(0)31-83 39 50
  83. Molndalsvagen 95    Email: niklas@appli.se
  84. S-412 63  GOTEBORG, Sweden     mcsun!seunet!appli!niklas
  85.