Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!mimsy!oddjob!hao!boulder!sunybcs!rutgers!iuvax!pur-ee!uiucdcs!uiucdcsb!robison
From: robison@uiucdcsb.cs.uiuc.edu
Newsgroups: comp.lang.smalltalk
Subject: Re: Smalltalk for (embedded) real-time
Message-ID: <168900004@uiucdcsb>
Date: Thu, 10-Sep-87 13:53:00 EDT
Article-I.D.: uiucdcsb.168900004
Posted: Thu Sep 10 13:53:00 1987
Date-Received: Sat, 12-Sep-87 15:40:44 EDT
References: <1881@tekig4.TEK.COM>
Lines: 18
Nf-ID: #R:tekig4.TEK.COM:1881:uiucdcsb:168900004:000:923
Nf-From: uiucdcsb.cs.uiuc.edu!robison    Sep 10 12:53:00 1987


I'll put in another plug for generation scavenging.  I've used it for a 
Russell interpreter and was impressed that only about 3% of the running 
time is spent on garbage collection.  A big advantage I've noticed is in 
handling upward funargs.  Normally these are expensive since they require 
(without extra analysis) heap allocation of stack frames, most of which 
die fairly quickly anyway.  With the scavenging algorithm, the frames can 
allocated essentially as fast as from a stack. (The allocation requires 
incrementing a pointer and writing one word.)  The extra overhead (compared 
with stack allocation) is during scavenging, which runs in time proportional 
to the *live* frames.  Hence all the dead stack frames don't hurt much.

Arch D. Robison
University of Illinois at Urbana-Champaign
	
CSNET: robison@UIUC.CSNET
UUCP: {ihnp4,pur-ee,convex}!uiucdcs!robison
ARPA: robison@B.CS.UIUC.EDU (robison@UIUC.ARPA)