Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!rutgers!sri-spam!sri-unix!hplabs!hp-sdd!ncr-sd!ncrcae!ece-csc!mcnc!philabs!micomvax!musocs!mcgill-vision!mouse
From: mouse@mcgill-vision.UUCP (der Mouse)
Newsgroups: comp.unix.wizards
Subject: Re: brk's zero-fill behavior on VAXen
Message-ID: <544@mcgill-vision.UUCP>
Date: Sat, 8-Nov-86 02:06:36 EST
Article-I.D.: mcgill-v.544
Posted: Sat Nov  8 02:06:36 1986
Date-Received: Tue, 11-Nov-86 09:26:32 EST
References: <7208@elsie.UUCP>
Organization: McGill University, Montreal
Lines: 22

In article <7208@elsie.UUCP>, ado@elsie.UUCP (Arthur David Olson) writes:
[paraphrased]
> "brk" and "sbrk" don't promise the contents of any new memory they
> may create.  But on a VAX it's always zero.
[quoted]
> Can system performance be improved by avoiding zero filling of the new
> memory?

Probably.  But probably not measurably.  The VAX has a pte type known
as "zero-fill on demand" which means that the page is created full of
zeros when it is first referenced.  This, for instance, is how the bss
segment is normally set up (I think, the kernel code is spread over
several routines).

					der Mouse

USA: {ihnp4,decvax,akgua,utzoo,etc}!utcsri!mcgill-vision!mouse
     think!mosart!mcgill-vision!mouse
Europe: mcvax!decvax!utcsri!mcgill-vision!mouse
ARPAnet: think!mosart!mcgill-vision!mouse@harvard.harvard.edu

	Aren't you glad you don't shave with Occam's Razor?