How can i let Franz Allegro Common Lisp use the percentage of using the processor?
Patrick Jarjoui
I am using Franz Allegro Common Lisp version 5.0 and every time
i execute my program it saturate my processor to 100% and i can't use any
other
software at that time. Does anybody have any idea how to low the use
of processor and let him use instead the percentage of processor that i
determine in advance, i'm using now Windows 2000 and i try it before on
Windows NT 4.0 and it's the same. i tried also in the process administration
of windows to determine the priority of lisp and to reduce it to the low.
Thanks
Patrick
Fernando
There's an api for that (setthreadpriority or something similar).
Take a look at msdn.
//-----------------------------------------------
// Fernando Rodriguez Romero
//
// frr at mindless dot com
//------------------------------------------------
Marc Battyani
Fernando <spa...@must.die> wrote in message
news:hfgiissbcdoinskk0...@4ax.com...
> On Mon, 22 May 2000 15:11:49 +0200, "Patrick Jarjoui"
> <patrick...@insa-rouen.fr> wrote:
>
> >Hello Everybody,
> > I am using Franz Allegro Common Lisp version 5.0 and every time
> >i execute my program it saturate my processor to 100% and i can't use any
> >other
> >software at that time. Does anybody have any idea how to low the use
> >of processor and let him use instead the percentage of processor that i
> >determine in advance, i'm using now Windows 2000 and i try it before on
> >Windows NT 4.0 and it's the same. i tried also in the process
administration
> >of windows to determine the priority of lisp and to reduce it to the low.
>
> There's an api for that (setthreadpriority or something similar).
> Take a look at msdn.
SetThreadPriority sets the priority of the thread relatively to the process
priority.
if you want to change the priority class of a whole process you should
rather use SetPriorityClass.
Marc Battyani
Jon S Anthony
>
> Hello Everybody,
> I am using Franz Allegro Common Lisp version 5.0 and every time
> i execute my program it saturate my processor to 100% and i can't use any
> other
> software at that time. Does anybody have any idea how to low the use
> of processor and let him use instead the percentage of processor
AllegroCL is not doing this. I can pretty much guarantee this as we use
it
all the time on NT and in very heavy thread mode and this is never an
issue.
The single best way to fix this is to determine where your program has
an
infinite loop in it and fix that.
/Jon
--
Jon Anthony
Synquiry Technologies, Ltd. Belmont, MA 02478, 617.484.3383
"Nightmares - Ha! The way my life's been going lately,
Who'd notice?" -- Londo Mollari
Patrick Jarjoui
But i have only one processor on my computer and i have
no infinite loop.
Patrick
"Jon S Anthony" <j...@synquiry.com> a écrit dans le message news:
392989...@synquiry.com...
Patrick Jarjoui
450 MHZ isn't that enough to execute a simulation built in
CLOS on FRANZ Allegro COMMON LISP?
Patrick
"David Bakhash" <ca...@alum.mit.edu> a écrit dans le message news:
m3zopg8...@alum.mit.edu...
> okay. here's the deal. NT is not the greatest thing in the world
> about managing processes. In fact, just yesterday I was compiling a
> huge system on NT with ACL, and even though the computer is pretty
> powerful, it comes to a halt.
>
> My guess is not that it's a processor issue, but a memory issue.
> Depending on what you're running (or compiling), you may simply be
> using up one of the computer's vital resources (i.e. memory) and so
> it's hard for other processes to really be effective.
>
> I've never tried to re-prioritize processes on NT. On UNIX it's
> pretty simple (i.e. with the `nice' and `renice' commands). I'd look
> around for a utility, as one might exist. I just don't think it'll
> have much to do with Allegro CL.
>
> dave
Francis Leboutte
>Hello,
> But i have only one processor on my computer and i have
>no infinite loop.
You could try to modify the "performance boost for the foreground
application" property (see Control Panel|System|Performance) . However I am
afraid the WIndows NT processes scheduler is not very clever at detecting
processes that are (too) greedy for CPU time.
--
Francis Leboutte
f...@algo.be www.algo.be +32-(0)4.388.39.19
Tim Bradshaw
> Well i'm using a 524 MB for Memory on a Pentium II
> 450 MHZ isn't that enough to execute a simulation built in
> CLOS on FRANZ Allegro COMMON LISP?
Do you have enough memory? It's much more likely to be memory starved
than processor-time starved.
My experience (from Unix) is that on a modern CPU (probably anything
faster than 100MHz? maybe slower than that as well), that the OS can
schedule computationally-intensive processes with little noticeable
impact on the responsiveness of the machine to user input (obviously
asking it to do things that take significant CPU time takes longer,
but typing at something or general GUI stuff is not noticeably
impacted).
For instance I'm typing this at a machine which has two Lisps both
executing (loop while t), and getting about 95% cpu between them. I'm
not noticing any impact except that when emacs GCs it takes a little
time. Someone else is also typing stuff at an emacs on the machine.
I'd expect that NT should be pretty much as good as Unix is in this
respect (windows 9x will be worse, its process management seems to be
pretty deficient). Perhaps it's spectacularly worse in some way, but
I'd doubt it -- process scheduling is not exactly new technology.
*However* if whatever you are doing uses enough virtual memory that it
drives the machine into significant paging, then you *definitely* will
notice it becoming slow. So I'd look hard at the amount of virtual
memory you're using.
--tim
Erik Naggum
| Well i'm using a 524 MB for Memory on a Pentium II 450 MHZ isn't
| that enough to execute a simulation built in CLOS on FRANZ Allegro
| COMMON LISP?
Yes, it is. Does that make you think it could be your own code?
#:erik
--
If this is not what you expected, please alter your expectations.
Francis Leboutte
>* Patrick Jarjoui wrote:
>> Well i'm using a 524 MB for Memory on a Pentium II
>> 450 MHZ isn't that enough to execute a simulation built in
>> CLOS on FRANZ Allegro COMMON LISP?
>
>Do you have enough memory? It's much more likely to be memory starved
>than processor-time starved.
>
>My experience (from Unix) is that on a modern CPU (probably anything
>faster than 100MHz? maybe slower than that as well), that the OS can
>schedule computationally-intensive processes with little noticeable
>impact on the responsiveness of the machine to user input (obviously
>asking it to do things that take significant CPU time takes longer,
>but typing at something or general GUI stuff is not noticeably
>impacted).
It is also what I remember from my (short) experience with a ACL on SUN
machine.
>For instance I'm typing this at a machine which has two Lisps both
>executing (loop while t), and getting about 95% cpu between them. I'm
>not noticing any impact except that when emacs GCs it takes a little
>time. Someone else is also typing stuff at an emacs on the machine.
>
>I'd expect that NT should be pretty much as good as Unix is in this
>respect (windows 9x will be worse, its process management seems to be
>pretty deficient). Perhaps it's spectacularly worse in some way, but
>I'd doubt it -- process scheduling is not exactly new technology.
Yes.
But with ACL on NT , instead of (loop while t) you would have to do
(loop while t
do
(process-pending-events))
to get some acceptable responsiveness from the applications (ACL included).
>*However* if whatever you are doing uses enough virtual memory that it
>drives the machine into significant paging, then you *definitely* will
>notice it becoming slow. So I'd look hard at the amount of virtual
>memory you're using.
>
>--tim
--
Tim Bradshaw
> Yes.
> But with ACL on NT , instead of (loop while t) you would have to do
> (loop while t
> do
> (process-pending-events))
> to get some acceptable responsiveness from the applications (ACL included).
What? Are you saying that a process on NT can simply block other
processes from running without (very) special privileges? That seems
extraordinary to me.
--tim
Martin Thornquist
I tried (loop while t) on a machine I have handy, and got good
response from other programs. The listener I did the loop in, OTOH,
didn't respond at all, so I had to kill it. NT4.0, I believe,
Harlequin LispWorks 4.1.0, Pentium III 500MHz, not sure about memory.
Martin
--
"Plus I remember being impressed with Ada because you could write an
infinite loop without a faked up condition. The idea being that in Ada
the typical infinite loop would normally be terminated by detonation."
-Larry Wall
Jon S Anthony
>
> Hello,
> But i have only one processor on my computer and i have
> no infinite loop.
>
>
> i have no infinite loop.
Obviously you do have an infinite loop, otherwise the Lisp process
would not be taking up all the CPU. Since this is not an intrinsic
problem with ACL, there must be something in your application doing
this (or NT has gone wacko, which is also highly likely). A rather
less likely (but still possible) situation is that something in your
application is breaking ACL so that it then goes into an infinite loop.
If you have any FF code in your app, this may be a primary possibility.
Jon S Anthony
>
> * Patrick Jarjoui wrote:
> > Well i'm using a 524 MB for Memory on a Pentium II
> > 450 MHZ isn't that enough to execute a simulation built in
> > CLOS on FRANZ Allegro COMMON LISP?
>
> Do you have enough memory? It's much more likely to be memory starved
> than processor-time starved.
This can definitely cause NT to flake out.
> For instance I'm typing this at a machine which has two Lisps both
> executing (loop while t), and getting about 95% cpu between them. I'm
> not noticing any impact except that when emacs GCs it takes a little
> time. Someone else is also typing stuff at an emacs on the machine.
>
> I'd expect that NT should be pretty much as good as Unix is in this
> respect (windows 9x will be worse, its process management seems to be
> pretty deficient). Perhaps it's spectacularly worse in some way, but
> I'd doubt it -- process scheduling is not exactly new technology.
While this is a completely reasonable expectation, NT is actually very
bad at this once it gets loaded. It becomes unusable if there is a lot
of processing and RAM is short. Even so, you need to have something
taking up all the CPU (_typically_ an infinite loop), which may well
be the base bug which is only presenting itself by killing NT.
Mike McDonald
Jon S Anthony <j...@synquiry.com> writes:
> Patrick Jarjoui wrote:
>>
>> Hello,
>> But i have only one processor on my computer and i have
>> no infinite loop.
>>
>> Patrick
>>
>> i have no infinite loop.
>
> Obviously you do have an infinite loop,
Another name for an infinite loop is a polling loop. Are you doing any
polling?
Mike McDonald
mik...@mikemac.com
David Bakhash
Francis Leboutte
>* Francis Leboutte wrote:
>
>> Yes.
>> But with ACL on NT , instead of (loop while t) you would have to do
>
>> (loop while t
>> do
>> (process-pending-events))
>
>> to get some acceptable responsiveness from the applications (ACL included).
>
>What? Are you saying that a process on NT can simply block other
>processes from running without (very) special privileges? That seems
>extraordinary to me.
Well it's not uncommon for Microsoft to make extraordinary things. I
vaguely remember having red that an application has to be programmed
"correctly" for the NT (win95 ?) scheduler makes its job appropriately (has
to respect some rules which maybe ACL doesn't).
I am not too surprised by what is related by Patrick Jarjoui. Usually when
I recompile an application (ACL/NT) , I take advantage of this to make some
phone calls or play with my dog - which is fine for me ; for example
opening a new message window in Eudora takes about 5 seconds at that time.
It is why I said that the NT scheduler is not very clever about "too"
greedy processes.
Patrick Jarjoui
there's no infinite loopthat's for sure i check it out
only loop with a specific condition but as i'm programming an
object oriented package designated for simulation it creates a
huge number of object so it execute garbage collector 20
times before the processor go down and it didn't even attend the
half (228 MB) of full memory wich i increase it 524 MB.
So i'm thinking if i reduce the percentage of using the processor
from 100% to for example 70% so the PC won't go down and it'll
use the rest of the memory instead to complete his work, or else in
my case you must reboot your Windows system cause your pc is dead.
I try it on a small number of objects and it works so the problem
is in lisp itself or in windows and that is for sure or you must change
your processor to a higher on your PC and we don't have that much
money to do that.
Thanks for your advices
Patrick
"Erik Naggum" <er...@naggum.no> a écrit dans le message news:
31680850...@naggum.no...
> * "Patrick Jarjoui" <patrick...@insa-rouen.fr>
> | Well i'm using a 524 MB for Memory on a Pentium II 450 MHZ isn't
> | that enough to execute a simulation built in CLOS on FRANZ Allegro
> | COMMON LISP?
>
Martti Halminen
> Hello everybody,
> there's no infinite loopthat's for sure i check it out
> only loop with a specific condition but as i'm programming an
> object oriented package designated for simulation it creates a
> huge number of object so it execute garbage collector 20
> times before the processor go down and it didn't even attend the
> half (228 MB) of full memory wich i increase it 524 MB.
> So i'm thinking if i reduce the percentage of using the processor
> from 100% to for example 70% so the PC won't go down and it'll
> use the rest of the memory instead to complete his work, or else in
> my case you must reboot your Windows system cause your pc is dead.
> I try it on a small number of objects and it works so the problem
> is in lisp itself or in windows and that is for sure or you must change
> your processor to a higher on your PC and we don't have that much
> money to do that.
Well, if you are having ACL taking 100% CPU, it is obviously not
a question of running out of memory: in that case the hard disk
would be continuously paging, with the CPU load at perhaps 15 %.
One question that comes to my mind is, has anybody bothered
optimizing your garbage collector settings? I once managed to
reach a 8-fold speedup on ACL 4.3.2 on a particular application
by tweaking the oldspace/newspace sizes etc.
If you haven't investigated that, the results of
(sys:gsgc-parameters)
and (cl:room t) might be interesting.
--
Tim Bradshaw
> Hello everybody,
> there's no infinite loopthat's for sure i check it out
> only loop with a specific condition but as i'm programming an
> object oriented package designated for simulation it creates a
> huge number of object so it execute garbage collector 20
> times before the processor go down and it didn't even attend the
> half (228 MB) of full memory wich i increase it 524 MB.
> So i'm thinking if i reduce the percentage of using the processor
> from 100% to for example 70% so the PC won't go down and it'll
> use the rest of the memory instead to complete his work, or else in
> my case you must reboot your Windows system cause your pc is dead.
> I try it on a small number of objects and it works so the problem
> is in lisp itself or in windows and that is for sure or you must change
> your processor to a higher on your PC and we don't have that much
> money to do that.
Do you have 524Mb of *real* memory in the machine? How much memory is
Lisp using? This sounds like an absolutely classic paging problem.
If it is then getting a faster processor will make essentially no
difference at all as it will be spending 9x% of its time waiting for
the disk.
--tim
Erik Naggum
| Do you have 524Mb of *real* memory in the machine? How much memory is
| Lisp using?
Well, it is actually fairly hard to make Allegro CL use more than
about 400M of old-space memory if you want reasonable new-space
performance, even when using very strong words to drive home the
point in a machine with more than enough physical memory and 4G of
swap space just for kicks. I have seen ACL give up the proverbial
ghost fighting battles with memory beyond 512M, which coincides with
the fixnum capacity.
#:Erik
Fernando
<patrick...@insa-rouen.fr> wrote:
>Hello everybody,
> there's no infinite loopthat's for sure i check it out
>only loop with a specific condition but as i'm programming an
>object oriented package designated for simulation it creates a
>huge number of object so it execute garbage collector 20
>times before the processor go down and it didn't even attend the
>half (228 MB) of full memory wich i increase it 524 MB.
I still think there's something wrong with your code, but download
this stuff and use the renice tool:
http://maxx.mc.net/~jlh/nttools/html/nttools.htm
I would be intersting if some experienced lisper could post some
general guidelines for writting efficient Lisp code. Most textbooks
seam to insist on elegant code only, but you can't just forget about
performance... So? O:-)
Johan Kullstam
> * Francis Leboutte wrote:
>
> > Yes.
> > But with ACL on NT , instead of (loop while t) you would have to do
>
> > (loop while t
> > do
> > (process-pending-events))
>
> > to get some acceptable responsiveness from the applications (ACL included).
>
> What? Are you saying that a process on NT can simply block other
> processes from running without (very) special privileges? That seems
> extraordinary to me.
in my experience with running background simulations under NT at work
and comparing this to running them in the background under linux at
home (and other unix machines in general like sun sparc or hp boxen),
i find that NT is fairly bad at multi-tasking.
in NT, to get decent user interaction, you have to crank up the
foreground priority bonus. this starves the background simulation for
cpu cycles. the windows widget for adjusting priorities is very crude
and doesn't give hardly any options -- it's just focused task vs all
the others and three levels of bonus to active window. the
programming API might be a bit better, but i don't know.
look at the target audience for NT, corporate ms-office users, i
suspect microsoft thinks multi-tasking is equivalent to not having to
kill one application before starting another. they don't expect the
unfocused application to want to consume any cpu. they certainly
haven't optimized for background tasks.
this is subjective and not quantified, but my impression is that NT
fairly sucks in this regard. win9x is merely worse.
--
johan kullstam l72t00052
Joe Marshall
> Hello everybody,
> there's no infinite loopthat's for sure i check it out
> only loop with a specific condition but as i'm programming an
> object oriented package designated for simulation it creates a
> huge number of object so it execute garbage collector 20
> times before the processor go down and it didn't even attend the
> half (228 MB) of full memory wich i increase it 524 MB.
Sounds like GC death.
If your objects are long-lived, (which I assume they are because of
the number of GCs), you should cons them in a more permanent space and
avoid having the generational GC copy them back and forth. This is
especially true if you create these huge objects all at once before
starting the `meat' of your simulation.
Read Franz's documentation on tuning the GC. You should be able to
fix this problem with a little experimentation.
Joe Marshall
> Tim Bradshaw <t...@cley.com> wrote:
>
> >* Francis Leboutte wrote:
> >
> >> Yes.
> >> But with ACL on NT , instead of (loop while t) you would have to do
> >
> >> (loop while t
> >> do
> >> (process-pending-events))
> >
> >> to get some acceptable responsiveness from the applications (ACL included).
> >
> >What? Are you saying that a process on NT can simply block other
> >processes from running without (very) special privileges? That seems
> >extraordinary to me.
>
> Well it's not uncommon for Microsoft to make extraordinary things. I
> vaguely remember having red that an application has to be programmed
> "correctly" for the NT (win95 ?) scheduler makes its job appropriately (has
> to respect some rules which maybe ACL doesn't).
I don't want to be the local apologist for Microsoft, but NT isn't
*that* broken. NT does have pre-emptive processing, so it isn't
necessary to explicitly relinquish your timeslice.
Of course, if you *do* explicitly relinquish your timeslice, you will
make the machine that much more responsive.
I believe that the ACL scheduler on NT attempts to do the right thing
by relinquishing the processor when all lisp threads are waiting, but
neither the ACL scheduler nor the NT scheduler can read your mind.
When you execute code like (loop while t), there is no easy way to
tell that you are simply spinning your wheels (halting problem,
anyone?), so as far as the ACL scheduler is concerned, the thread
executing that code is doing `work', and will therefore take up
processor time.
> I am not too surprised by what is related by Patrick Jarjoui. Usually when
> I recompile an application (ACL/NT) , I take advantage of this to make some
> phone calls or play with my dog - which is fine for me ; for example
> opening a new message window in Eudora takes about 5 seconds at that time.
> It is why I said that the NT scheduler is not very clever about "too"
> greedy processes.
NT is probably making the simple assumption that ACL and Eudora are
equally important to you, so each gets about half the resources of CPU
time and memory. Of course, when Eudora wants to create a window, it
is going to request a good chunk of memory and probably page stuff,
etc.
You can tell NT to give the foreground process a priority boost,
though. This can often make the machine much more responsive even if
a `background' process is taking up all the spare CPU cycles.
Francis Leboutte
In my example with Eudora, I should have also written that there is no disk
activity, the CPU is a 400Mhz one and that the "performance boost for the
foreground application" property in the Control Panel|System|Performance is
set to the maximum. 5 seconds (reproducible) to open this window seems too
much. I would expect a better result from a good OS.
Joe Marshall
>
> In my example with Eudora, I should have also written that there is no disk
> activity, the CPU is a 400Mhz one and that the "performance boost for the
> foreground application" property in the Control Panel|System|Performance is
> set to the maximum. 5 seconds (reproducible) to open this window seems too
> much. I would expect a better result from a good OS.
Agreed.
Christopher C Stacy
they had model numbers, so I guess that means its a model "I") at 133
Mhz with 128 MB on Windows NTS 4.0. I typed (LOOP WHILE T) into the Listener.
I have all kinds of other programs running: GNU Emacs, web servers,
telnet sessions, media players, web browsers, and all manner of
doo-dads like the RealAudio thing pinging the network, so there's
competition for physical and virtual memory.
An infinite loop in Lisp makes the other programs run much slower, but
they are usable (if a little painful). For example, it takes Emacs
nearly 2 seconds to repaint the screen for a control-L.
I used the Task Manager to change the priority of the Lisp from "Normal"
to "Low", and then the other applications went back to responding as if
there was no load on the system at all. At either priority setting,
Task Manager says Lisp is using the entire CPU (between 88-98%).
Robert Monfera
Joe Marshall wrote:
> Sounds like GC death.
A decent GC death involves paging (i.e., it is unlikely that exactly the
right amount of garbage is generated and recycled in a sustained way to
border with, yet not exceed the physical memory limitation). Also, the
OP said he increased the memory, and nothing changed. Since ACL
definitely does not keep my processor busy unnecessarily, I believe it
is a question of what is going on in the software.
Robert
Robert Monfera
Erik Naggum wrote:
> I have seen ACL give up the proverbial
> ghost fighting battles with memory beyond 512M, which coincides with
> the fixnum capacity.
This can turn into a "Lisp is too small" argument in light of the
long-awaited memory growth (512MB is about $900, and workstations
routinely have 1-4GB, and the 4.9lbs IBM Thinkpad 600x supports 576MB).
What was your workaround? Separate processes for loosely coupled
functions?
Does anyone know how CMUCL fares? It supports pretty large arrays, and
it does not require contiguous memory.
Robert
Erik Naggum
| What was your workaround? Separate processes for loosely coupled
| functions?
When I said I had seen ACL croak, it was not in production use, but
during stress testing. My workaround was to remove the bugs.
Espen Vestre
> swap space just for kicks. I have seen ACL give up the proverbial
> ghost fighting battles with memory beyond 512M, which coincides with
> the fixnum capacity.
Hmm. I have no problems running ACL on a 1GB Solaris box with up to
about 900MB resident memory for the ACL process.
Here's what top says about a process that has been running for almost
4 weeks:
742 hushe 1 58 0 783M 783M sleep 89.6H 0.00% trango
However, global GC *must* be avoided, I once tried to run it in a
980MB process and it did actually finish all right, but only after
running for 16 hours :-/
Maybe global GC is the clue to the problems we're discussing here
too? Both the mark and compaction phases of global GC may run for
a _very_ long time when allocated memory grows to a few hundred MB,
and if you have enough memory (avoiding swapping), it will indeed
use as much cpu as it can get.
Try to set *global-gc-behavior* to :warn and see what happens.
Depending on your application, you may also want to increase newspace
in order to not tenure to many objects that need to be GC-d. I
currently use (sys:resize-areas :new 40000000), but if you can
do with less, you should (generational GC will behave somewhat
sluggish with this big newspace).
--
(espen)
Espen Vestre
> in NT, to get decent user interaction, you have to crank up the
> foreground priority bonus. this starves the background simulation for
> cpu cycles.
I heard someone say "don't put a critical NT server application in a
building near a highway, if the mouse moves from the vibrations, you
lose lots of cpu cycles" ;-)
--
(espen)
Raymond Toy
Robert> Does anyone know how CMUCL fares? It supports pretty large arrays, and
Robert> it does not require contiguous memory.
Some of the newer x86 ports support up to about 2 GB of heap.
Ray
Joe Marshall
> Joe Marshall wrote:
>
> > Sounds like GC death.
>
> A decent GC death involves paging (i.e., it is unlikely that exactly the
> right amount of garbage is generated and recycled in a sustained way to
> border with, yet not exceed the physical memory limitation).
Yes, but the Franz GC is rather quirky. I've seen it go into a
gc-death situation without paging when it thought there was much less
ram than there actually was. With the wrong settings, you can easily
cause it to needlessly copy objects back and forth without freeing
much space or allocating new space. I suspect that this might be the
problem.
> Also, the OP said he increased the memory, and nothing changed.
I wasn't sure what he meant by that. If he didn't call
SYS:RESIZE-AREAS, ACL tends to be rather conservative about allocating
extra ram.
> Since ACL definitely does not keep my processor busy unnecessarily,
> I believe it is a question of what is going on in the software.
I could easily be wrong.
Fernando
wrote:
>Robert Monfera <mon...@fisec.com> writes:
>
>> Joe Marshall wrote:
>>
>> > Sounds like GC death.
>>
>> A decent GC death involves paging (i.e., it is unlikely that exactly the
>> right amount of garbage is generated and recycled in a sustained way to
>> border with, yet not exceed the physical memory limitation).
>
>Yes, but the Franz GC is rather quirky. I've seen it go into a
>gc-death situation without paging when it thought there was much less
What's GC death? Someone please enlighten me. O:-)
TIA
Joe Marshall
>
> What's GC death? Someone please enlighten me. O:-)
>
When, for some reason or another, the lisp process thinks it is about
out of memory, thinks it cannot get more, attempts to GC to free some,
ends up not freeing any, which immediately retriggers a GC, etc. etc.