Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!lll-crg!nike!ucbcad!ucbvax!hplabs!gatech!hope
From: hope@gatech.EDU (Theodore Hope)
Newsgroups: net.unix-wizards
Subject: Re: brk's zero-fill behavior on VAXen
Message-ID: <5591@gatech.EDU>
Date: Mon, 3-Nov-86 09:11:48 EST
Article-I.D.: gatech.5591
Posted: Mon Nov  3 09:11:48 1986
Date-Received: Tue, 4-Nov-86 05:16:53 EST
References: <7208@elsie.UUCP>
Reply-To: hope@gatech.UUCP (Theodore Hope)
Organization: School of Information and Computer Science, Georgia Tech, Atlanta
Lines: 25

In article <7208@elsie.UUCP> ado@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@ics.GATECH.EDU
uucp:	...!{akgua,decvax,hplabs,ihnp4,linus,seismo,ulysses}!gatech!hope