Path: utzoo!utgpu!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!ulowell!apollo!mishkin
From: mishkin@apollo.COM (Nathaniel Mishkin)
Newsgroups: comp.sys.apollo
Subject: Re: Huge data segments in SR10
Message-ID: <3f9a6573.18fa1@apollo.COM>
Date: 11 Nov 88 14:38:00 GMT
References: <8811110459.AA25851@umaxc.weeg.uiowa.edu>
Reply-To: mishkin@apollo.com (Nathaniel Mishkin)
Organization: Apollo Computer, Chelmsford, MA
Lines: 45

In article <8811110459.AA25851@umaxc.weeg.uiowa.edu> dbfunk@ICAEN.UIOWA.EDU (David B. Funk) writes:
>In posting  <130@tatti.utu.fi> Matti Jokinen (moj@utu.fi) Asks:
>>(I have once run out of disk space this way).
>>What is the motivation of such apparently wasteful use of resources?  Or is
>>there something wrong in our system?  Since the programs ran with much smaller
>>data segments in SR9.7, it seems obvious that the bulk of the space is unused.
>    In "Domain System Software Release Notes" for SR10.0 there is a discussion
>of the changes to the system routines malloc() & rws_$alloc on page 1-18.
>The important part is that the requested storage is marked as "used" on
>disk at allocation time, not delayed until the pages are used. The net
>result is a process' stack frame is completely allocated at process
>creation time. Thus each new process you start eats up at least 500K bytes
>of disk space, even if it's just a little thing like pwd. Also pre-SR10
>inprocess execution saved you the cost of a new stack for simple command
>execution.

On vanilla Unix, when you change the break (perhaps via malloc), swap
space disk blocks are reserved to back the new VA space.  If there's
no swap space, the call to set the break, and hence the call to malloc,
fails.

DOMAIN/OS doesn't segregate blocks on our disks between swap space and
file system space.  The idea was that this is a more flexible scheme:
If you want more swap space, delete some files; if you want more space
for files, be prepared for the fact that you can't run programs that
want a lot of heap storage.  (In vanilla Unix changing your mind requires
dumping and reloading your disk.)

The problem with the DOMAIN/OS scheme prior to 10.0 was that changing
the break caused more temp file space to be mapped into your address
space but there was no guarantee that when you actually touched that
part of your address space for the first time (perhaps sometime long
after you changed the break) that there'd be disk space to back it up.
Thus, the malloc would succeed, but your program could then fail randomly
later.  Lots of people complained about this.  So at 10.0 we changed
things so that the disk space is reserved at the time the break is changed,
thus ensuring the same behavior as vanilla Unix.  I think the net effect
is that you require no more disk space than would be required on a vanilla
Unix system.  However, the benefits of being to easily juggle space between
backing storage for heap space and for file system data are retained in
DOMAIN/OS.
-- 
                    -- Nat Mishkin
                       Apollo Computer Inc., Chelmsford, MA
                       mishkin@apollo.com