Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!husc6!mit-eddie!uw-beaver!tektronix!zeus!bobr From: bobr@zeus.TEK.COM (Robert Reed) Newsgroups: comp.lang.smalltalk Subject: Re: Smalltalk for (embedded) real-time Message-ID: <2381@zeus.TEK.COM> Date: Tue, 8-Sep-87 18:53:05 EDT Article-I.D.: zeus.2381 Posted: Tue Sep 8 18:53:05 1987 Date-Received: Thu, 10-Sep-87 05:30:20 EDT References: <1881@tekig4.TEK.COM> <80500016@uiucdcsp> Reply-To: bobr@zeus.UUCP (Robert Reed) Organization: CAE Systems Division, Tektronix Inc., Beaverton OR Lines: 25 In article <80500016@uiucdcsp> johnson@uiucdcsp.cs.uiuc.edu writes: There is another problem with Smalltalk that is more severe. Smalltalk uses garbage collection a lot. Garbage collection can easily interfere with real-time requirements. The solution is to go back to using the reference counting techniques that implementors are now ignoring, use parallel garbage collection, or program very carefully and ensure that no garbasge is produced. Of course, any program that produces a lot of garbage won't convert to Objective C very well, since I think that it has no garbage collector. Please correct me if I am wrong. This comment shows a basic lack of understanding about "garbage collection" and "reference counting." In fact, most Smalltalk implementations employ BOTH reference counting AND garbage collection. Reference counting is used to detect "dead" objects (i.e. objects which are no longer referenced by any other object). The space occupied by these objects may or may not then be moved to a free list. Eventually, fragmentation resulting from allocation and reallocation of a given segment of memory may require garbage collection (i.e. the relocation of "live" objects to coalesce the free memory of the segment into one block) in order to keep the system from going belly up. Garbage collection has nothing particular to do with reference counting. -- Robert Reed, Tektronix CAE Systems Division, bobr@zeus.TEK