[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
ARRAY relocations in MACLISP
- To: JONL at MIT-MC
- Subject: ARRAY relocations in MACLISP
- From: MOON at MIT-MC (David A. Moon)
- Date: Wed, 20 Sep 78 06:52:00 GMT
- Cc: (BUG LISP) at MIT-MC
- Original-date: 20 SEP 1978 0252-EDT
Date: 18 SEP 1978 1927-EDT
From: JONL at MIT-MC (Jon L White)
Subject: ARRAY relocations in MACLISP
To: MOON at MIT-MC
CC: (BUG LISP) at MIT-MC
BPORG and BPEND delineate the free binary program space, with programs
eating up from below, and arrays from above. There should be no need for
a user to try to control the array relocations, since the space between
BPORG and the top of arrays is treated like a general heap - when there
isn't enuf space between bporg and bpend, the first arrays are shuffled
upwards to close out any already-dead space; then if there still isn't
enough room, a GC is done to see if any more arrays died; finally, if
there still isn't enough room, more address space is eaten from the
time-sharing system allocator (ocasionally leading to "NO CORE? - mumble"
However, if you are building up a set of mumbles - arrays and programs -
and know in advance that about, say, 32K is needed to hold them, then do
two things first
1) setq *NORET to non-null, to prevent returning address space,
2) (GETSP 33000.) or some such suitable number.
I think this is what you want. Probably after building up the system,
you should reset *NORET to null.
Presumably by *NORET you mean NORET?
In fact, the observed symptom is that if I don't do the GETSP in advance,
it eventually gets into a loop doing nothing but GC: ARRAY RELOCATION
(if ^D is turned on). So I did some GETSP's and NORET's. Now it seems
that the program is taking about 3 times as long to run as it should,
the theory being that it is spending all of its time shuffling arrays,
although it might be that turning on ^D slows things down a lot. I was
using sstatus gcwho and most of the time there was no gc message in the
who-line but I suspect that is not on for array relocation blt'ing that
does not involve a wholine.
It seems to me that it would be as reasonable for the user to control
allocation of array space as for any of the other spaces.
Anyway, I plan to stop using arrays for this application since they
obviously aren't suitable, so I don't have any particularly loud complaint.
However, it does seem that array support could be a lot better.