From: Wayne Mesard
Subject: GC and time critical code?
Date:
Message-ID: <22550@bbn.COM>
I'm working on a spec for a program that needs to take collect reaction
time data (from humans). The program really wants to be written in Lisp
(as any well conceived program would :-), but I'm not clear about how
garbage collection will interfere with taking time data. That is, what
if the system is doing GC when the subject "presses the stop button"?
I imagine this problem has been dealt with before. Is there a way to
prevent this? (Forcing a GC right before the critical code isn't a
guarantee, but I'm willing to entertain arguments that that's good
enough.)
Any comments would be appreciated. Please mail to me. I'll summarize
to the net unless it turns out that this is a naive question.
Thanks.
--
unsigned *Wayne_Mesard(); ······@BBN.COM
BBN Labs, Cambridge, MA
Are you absolutely sure that you want to do this? [ny] ummm_
From: Jeff Dalton
Subject: Re: GC and time critical code?
Date:
Message-ID: <305@aiva.ed.ac.uk>
In article <·····@bbn.COM> ······@bbn.com writes:
>I'm working on a spec for a program that needs to take collect reaction
>time data (from humans). The program really wants to be written in Lisp
>(as any well conceived program would :-), but I'm not clear about how
>garbage collection will interfere with taking time data. That is, what
>if the system is doing GC when the subject "presses the stop button"?
This is a good question, which is probably why it keeps turning up.
There are, basically, three answers:
1. Use a Lisp that has a "nondisruptive" garbage collection strategy.
Some Lisps have garbaage collectors that do a little bit or work
fairly frequently, so that it's like having a slightly slower CONS
rather than long pauses for GC. Incremental GC, "ephemeral" GC,
and perhaps some other strategies are largely nondisruptive, but
at present tend not to be used in implementations for general-
purpose machines. It's possible that such techniques are fast enough
to be unnoticable even for your application. The delays shouldn't
be worse than the paging and scheduling delays one accepts when
running multiple processes.
2. Preallocate enough storage so there is no need to GC.
3. Don't generate any (or very much) garbage.
The latter two techniques can be combined if you use explicit storage
management, with a pool of resources that you allocate and free.
Most Lisp systems give you a fair amount of control over when storage
is allocated. That is, they try not to allocate storage on their own
but only when you call something like CONS. But &REST parameters tend
to cause a list allocation, and some interpreters construct
environments when functions are called. So you get rules like don't
use &REST, compile your code, etc.
Unfortunately, your program will be using numbers to represent
reaction times, and creating a number tends to allocate storage in
most Lisps even though you haven't done an explicit MAKE-NUMBER.
Some types/sizes of numbers may be represented directly (as part of a
pointer) rather than by an allocated object. If these are suitable
for reaction times, you win. Otherwise, you may have to preallocate
to make sure there is enough space for the numbers.
Jeff Dalton, JANET: ········@uk.ac.ed
AI Applications Institute, ARPA: ·················@nss.cs.ucl.ac.uk
Edinburgh University. UUCP: ...!ukc!ed.ac.uk!J.Dalton