ARRAY relocations in MACLISP

[MOON at MIT-MC (David A. Moon)]

    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"
    messages).
       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.