Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!CIM-VAX.HONEYWELL.COM!derstad
From: derstad@CIM-VAX.HONEYWELL.COM ("DAVE ERSTAD")
Newsgroups: comp.sys.apollo
Subject: Memory allocation bug
Message-ID: <8912111343.AA03128@umix.cc.umich.edu>
Date: 11 Dec 89 13:15:00 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 42


After spending my weekend glued to the tube, I finally found the reason
some of our applications grind to a thrashing halt.

Near as I can tell, there is a bug (?) in memory allocation at SR10
which causes a node to thrash violently even if the application
very clearly should not thrash.

For example, I wrote a program which allocated (via a Pascal NEW)
memory in 1Kbyte chunks.  Each time it allocated a chunk, the 
program touched each memory location in the chunk.

At SR9.7 on a DN4000 with 16 MB Ram, and 80 MB free disk, I was able
to allocate 40 MB of memory without much problem.  There was paging
to disk, but no more than I expected.

At SR 10.1.1 on a DN4000 with 32 MB Ram, and 160 MB free disk, at
arouund 16 MB of allocated memory the allocation process began
thrashing badly.  I was unable in over an hour to get more than
20 MB allocated (The SR9 version of the program was completely
done in less than 5 minutes)

There is no way 16 MB of data should thrash a 32 MB node!  Aside
from anything else, each data item is only touched once and
should be paged to disk (never to be paged back) when needed -
and this is what we say on 9.7.  From a DPAT we did, the problem
appears to be in the memory allocation routines.

I can post the sample program if anyone is interested, but I've got
a couple of question.
   1)  Hasn't anyone else seen this?  (Incidentally, we verified the 
       same behavior on the DN10000 - This could easily account
       for the FORTRAN compilation cited by Hanche-Olsen if the
       FORTRAN compiler does a lot of dynamic memory allocation
       for symbol tables or whatever).
   2)  Does anyone know what's broken?  Is Apollo aware of this problem?
   3)  How do I work around this without re-writing zillions of lines of 
       code?

Dave Erstad
Honeywell SSEC
DERSTAD@cim-vax.honeywell.com