krowitz%richter@UMIX.CC.UMICH.EDU (David Krowitz) (03/06/90)
SR10 is "Just Like Real Unix" (JLRU) ... all memory space which is declared by the program is allocated as soon as the program is started, even if the memory is never actually used during the execution. Under SR9, memory was allocated in the Aegis style -- ie. memory space was allocated the first time the program actually uses it during the execution of the program. Since your program never uses the 1,000,000 4-byte integer array, the SR9 machine never allocates the disk space needed for the virtual memory of the array. The SR10 machine allocates the disk space just as soon as the program is started. This prevents the program from getting part way into its execution before finding out that the disk is too full for it to allocate the memory its needs. The drawback is that the program always must allocate the full amount of memory even if it is not going to use it all. It's one of the drawbacks of Unix compatibility. There is an undocumented and unsupported switch for /com/bind which causes and SR10 program to use SR9 Aegis style memory allocation. I believe that it is "-vm_sparse" or "-sparse_vm" or something like that. -- David Krowitz krowitz@richter.mit.edu (18.83.0.109) krowitz%richter.mit.edu@eddie.mit.edu krowitz%richter.mit.edu@mitvma.bitnet (in order of decreasing preference)
weber_w@apollo.HP.COM (Walt Weber) (03/06/90)
In article <9003051659.AA24525@richter.mit.edu> krowitz%richter@UMIX.CC.UMICH.EDU (David Krowitz) writes: >SR10 is "Just Like Real Unix" (JLRU) ... all memory space which >is declared by the program is allocated as soon as the program is >started, even if the memory is never actually used during the >execution. Under SR9, memory was allocated in the Aegis style -- >... >There is an undocumented and unsupported switch for /com/bind which >causes and SR10 program to use SR9 Aegis style memory allocation. The following is an excerpt from the upcoming documentation of the UNSUPPORTED bind option which has been widely discussed here. (Note that this is still unsupported, until the revision is released. And no, I **don't** have a date or a revision number. :-) 0.1.4 New /com/bind Option: -sparse_vm The /com/bind option -sparse_vm provides compatibility with one kind of SR9.7 behavior. At SR9.7, all virtual memory had virtual address space allocated at creation, but not disk space. Instead, disk space was allocated dynamically. At SR10, all virtual memory had both virtual address space and disk space allocated at creation. This change was made for compatibility with UNIX, where applications do not expect to run out of disk space. The new option, -sparse_vm, enables the SR9.7 dynamic disk allocation behavior for programs run on sr10.2 or a later release. Currently, the new behavior affects only the break area, which includes the .bss area and that used by malloc(); it does not affect memory allocation for rws_$ calls. Also, the -sparse_vm option must not be used with C programs that make the fork() system call, because child processes will not have their own distinct break area. These restrictions may be removed at a future release. ------- >krowitz@richter.mit.edu (18.83.0.109) ...walt... Walt Weber Hewlett Packard NARC @ Apollo Systems Division -The views expressed herein are personal, and not binding on ANYONE- "The power of accurate observation is commonly called cynicism by those who have not got it" -George Bernard Shaw
bourrel@imag.fr (Guy Bourrel) (03/06/90)
Thank you. This <drawback> doesn't appear on ibm6150 or gould utx/32... The only thing to do is to buy more disk space, or a SUN station ... -- Guy BOURREL Equipe de Reconnaissance des Formes et de Microscopie Quantitative. TIM3 IMAG BP 53X 38041 GRENOBLE CEDEX bourrel@imag.imag.fr