nadkarni@ashok.dec.com (03/12/90)
I'm just learning C++ so maybe I'm missing something obvious. How do you distinguish between class objects allocated on the stack or static store and those allocated on the heap ? I have an application that would benefit greatly from garbage collection. Plenty of circular links so reference count based GC is out. Stop-and-collect is acceptable so I was planning on a simple mark and sweep scheme. However, I can't figure out a way to locate the `roots' (stack/static store) and distinguish them from the GC-able objects. One way might be to overload the new operator for GC classes so that you keep a list of the addresses of such objects and use this list to check if a object is in the heap or not (kind of like Boehm's GC, which I cannot use for some other reasons). But it seems like this check would be too much overhead even for my (so what if it's slow) application. Unless there is a way of telling in a constructor whether the object is allocated on the stack or not and then remembering that info in a tag. Is this possible ? As a related request, someone mentioned a C++ garbage collector (not Bartlett's and not Boehm's) a little while ago. I think it was part of some package (EC++ perhaps?). Since I do not have ftp access, could some kind soul mail it (just the GC part) to me if it is not too big ? Thanks, /Ashok Nadkarni Digital Equipment Corp. Standard disclaimer applies.
rfg@ics.uci.edu (Ronald Guilmette) (03/12/90)
In article <9084@shlump.nac.dec.com> nadkarni@ashok.dec.com writes: > >I'm just learning C++ so maybe I'm missing something obvious. How do you >distinguish between class objects allocated on the stack or static store >and those allocated on the heap ? Hummm... seems to me that we hashed this issue to death here in this newsgroup a few months back. As I recall, I pointed out that you could do some clever things by comparing an arbitrary address for an arbitrary object to certain other readily available addresses (e.g. current break value, current stack pointer, &etext, &edata, etc). I was roundly chastized for suggesting such a thing. Many people said that it would not be portable and the comparisons whould have to be rewritten for various machines and operating systems. I agreed, but claimed that the rewriting would be trivial. Did I leave out anything? // Ron Guilmette (rfg@ics.uci.edu) // C++ Entomologist // Motto: If it sticks, force it. If it breaks, it needed replacing anyway.
ttwang@polyslo.CalPoly.EDU (Thomas Wang) (03/13/90)
There is such a GC package. It is called MM. Version 1.0 is available
via anonymous ftp at 129.65.17.1. The file location is at
/tmp/mm.shar.Z
Version 2.0 will support exception handling, and eliminate the two
sets of constructors for root and non-root objects to one set of
constructors. Version 2.0 will work on cfront 2.0.
I shall release version 2.0 when I have used it to build an actual
application. (in around 6 months of time)
-Thomas Wang ("This is a fantastic comedy that Ataru and his wife Lum, an
invader from space, cause excitement involving their neighbors."
- from a badly translated Urusei Yatsura poster)
ttwang@polyslo.calpoly.edudrc@cs.brown.edu (David R. Chase) (03/13/90)
In article <25fc5b7b.4abf@polyslo.CalPoly.EDU> ttwang@polyslo.CalPoly.EDU (Thomas Wang) writes: > >There is such a GC package. It is called MM. Version 1.0 is available ... >Version 2.0 will support exception handling, I hope this isn't a rude question, but is there an easy possibility (with your system) of adding smarts to the compiler to get help in efficient implementation of your GC and exception handling? (That is, does your exception handling follow Tiemann/Cedar/Modula-2+/Modula-3/Ada, or does it follow Stroustrop's proposal (has that been published?)). Static declaration of the exceptions handled, as in (invented syntax) try <stmt> except { case e1 : ... case e2 : ... case e3 : ... } with the intention that e1, e2, e3 are constants, allows a pretty nifty implementation that imposes no run-time overhead for not taking the exception (except for the optimizations missed, but that's another issue and note that at least the scope in which the optimizer must be throttled is smaller than it would be for setjmp/longjmp). An additional extension (annotation) is to tag procedures (and procedure types) with the exceptions that they may raise. This permits static checking for posible uncaught exceptions, and informs programmers about the possible errors. For garbage collection, of course, I'd hope that the compiler would automatically handle the dirty work for me if I declare that a class has supertype "collectable" ("dirty work" means generating a method to do the collection for me so I don't have to go to any additional trouble). Down the road, of course, the compiler should even figure out when stack storage is adequate for the allocation of one of these objects and do the obvious optimization. Please understand that I'm not asking if it does these things yet -- I just want to know if the hooks exist to permit a streamlined implementation at some time in the future. Just curious -- I'm not exactly in a position to go FTP the bits just yet. (Any garbage collector aficionados care to comment on this package?) David