brk's zero-fill behavior on VAXen

[Theodore Hope]

In article <7208 at elsie.UUCP> ado at elsie.UUCP (Arthur David Olson) writes:
>If the result of the call is to expand the
>address space of the process, there's no promise about the contents of the
>newly-available address space.  Yet on our VAX (and on yours, too, if you
>have one) the newly-available space is always zero filled.

Clearly, for security reasons, you would want the kernel to zero-fill
new memory allocated to a user.

As for the quote "no promise about the contents...  yet it's always
zero-filled," it could be that after brk'ing and sbrk'ing a few times
you might have data that you wrote there earlier (assuming that you
didn't really "give" the page(s) back to the system.)  Then again, I'm
probably wrong about this.

>Can system performance be improved by avoiding zero filling of the new
>memory?

It can be assumed that on many architectures (such as the Vax) the process
of zero-filling a block of memory can be done in one or a few instructions.
-- 
Theodore Hope
School of Information & Computer Science, Georgia Tech, Atlanta GA 30332
CSNet:	Hope @ gatech		ARPA:	Hope at ics.GATECH.EDU
uucp:	...!{akgua,decvax,hplabs,ihnp4,linus,seismo,ulysses}!gatech!hope