Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!wuarchive!decwrl!shelby!neon!craig From: craig@Neon.Stanford.EDU (Craig D. Chambers) Newsgroups: comp.object Subject: Re: C++ and garbage collection Message-ID: <1990Oct1.232428.10186@Neon.Stanford.EDU> Date: 1 Oct 90 23:24:28 GMT References: <1044@exodus.Eng.Sun.COM> <57850@microsoft.UUCP> Organization: Stanford University Lines: 26 In article <57850@microsoft.UUCP> bobatk@microsoft.UUCP (Bob ATKINSON) writes: >(David Chase) writes: >>However >>(1) Conventional wisdom for Lisp/Smalltalk may not hold for C/C++; >> Lisp and Smalltalk rely on garbage collection for activation >> records and real numbers, for instance, and C does not >> (optimization of Lisp cleans this up somewhat). > >Modern implemenations of Smalltalk use processor stack frames for LIFO >activation records, and therefore have little interaction with the >allocator, let alone the reclaimer. They still, to my knowledge, use >heap-allocated real numbers, but *not* for small integers, which are >far more important. Our Self implementation supports 30-bit immediate floats, by stealing 2 bits of a normal IEEE exponent for a tag field. This decreases the range of immediate floats to 1/4th of what it was, and makes translations between tagged and untagged format a bit slow, but it does preserve the precision (the most important thing according to Velvel Kahan), and drastically reduces the load on the allocator for floating point calculations. Larger ranges could be implemented by supporting 32- or 64-bit (or larger) heap-allocated floats. See our OOPSLA'89 paper for more details. -- Craig Chambers