Path: utzoo!mnetor!uunet!husc6!mailrus!ames!ucsd!sdcsvax!ucsdhub!hp-sdd!hplabs!hpda!hpcuhb!hpcllla!hpclisp!hpclscu!shankar
From: shankar@hpclscu.HP.COM (Shankar Unni)
Newsgroups: comp.unix.wizards
Subject: Re: Grace misfeature in Unix?
Message-ID: <670011@hpclscu.HP.COM>
Date: 29 Mar 88 00:40:38 GMT
References: <2413@zyx.UUCP>
Organization: HP ITG/ISD Computer Language Lab
Lines: 28

/ hpclscu:comp.unix.wizards / aj@zyx.UUCP (Arndt Jonasson) /  7:01 am  Mar 25, 1988 /

> My interpretation of the word "releases" is: the process gives up the
> right to use those pages -> they are no longer owned by the process ->
> they can be assigned to another process that wishes to allocate more
> memory.
> 
> Are there Unix implementations that do this right? My faith in Unix
> (small as it was) was considerably reduced when I found that of two
> Unix implementations that I tested, both got it wrong.

Not necessarily. There are architectures in which different processes will
get (unconditionally) non-overlapping *virtual* memory spaces. In HP's
Precision Architecture ( our RISC, for those who don't care for Marketese ),
virtual addresses are 64 bits each: a 32-bit "space-id" (unique to each
process - each process gets one or more "spaces" exclusively) and a 32-bit
offset within the space. Of course, this whole address is mapped to a 32-bit
physical address, but virtual space given up by a process cannot be allocated
to another process. Also, there are per-process mapping tables.

Of course, what you're arguing is that when a process brk's downwards in 
such a layout, all those pages should be unmapped from the mapping tables,
making it illegal for the process to access them. I won't argue with you
there.  But this would happen, if at all, only on a page-by-page basis, so,
for instance, decrementing brk by 20 and then accessing a char that is 19
bytes beyond won't necessarily generate a fault..

--scu