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

wescott@lnic5.hprc.uh.edu writes:

>  I think the problem you are encountering is a known one.
>  Although I was not around at SR 9.7, I understand that
>  the allocation of virtual memory was quite different
>  than the UNIX-like scheme employed at SR 10.  As you may
>  know, a code running at SR 10 opens a paging file
>  immediately at run time, while SR 9 only opens this upon
>  demand.  This does not mean that the SR 10 node pages
>  immediately...but you know what I mean.  Anyhow, there
>  has been alot of confusion and disgust voiced from SR 9
>  users that wrote their codes to fit the O/S characteristics.

Yes, that is an area of concern;  however, it is a different
issue.  The fact that I touch (assign a value into) each memory
location once removes any differences due to this effect (Since
at SR9 I am demanding each page).  In any case, this should not 
cause thrashing, just a uniform increase in disk accesses. 

BTW, I was one of the gripers about this change from SR9 since
I did have to rewrite some code and wasn't happy about it.

I found there is a patch on the November patch tape that sounds
suspiciously like this problem but only applies to SAU2, 3, and 5
machines.  I haven't gotten any word back from the Apollo
hotline yet.

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