Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!pasteur!ucbvax!agate!bionet!csd4.milw.wisc.edu!leah!rpi!batcomputer!cornell!rochester!pt.cs.cmu.edu!wb1.cs.cmu.edu!avie
From: avie@wb1.cs.cmu.edu (Avadis Tevanian)
Newsgroups: comp.sys.next
Subject: Re: Process sizes on the NeXT
Message-ID: <4180@pt.cs.cmu.edu>
Date: 3 Feb 89 04:55:01 GMT
References: <9013@bloom-beacon.MIT.EDU>
Distribution: usa
Organization: Carnegie-Mellon University, CS/RI
Lines: 21

In article <9013@bloom-beacon.MIT.EDU> tytso@athena.mit.edu (Theodore Y. Ts'o) writes:
>The following is a truncated down copy of a ps done on the our NeXT:
>
>USER       PID  %CPU %MEM VSIZE RSIZE TT STAT  TIME COMMAND
>tytso      149   1.0  3.2 16.3M  264K p0 S     0:21 -bin/tcsh (tcsh)
>me        2174   0.0  0.0  816K    0K ?  SW    0:00 -tcsh (tcsh)
>
>Why are processes so huge?!?

The VSIZE field represents the virtual size of the task.  The large sizes are
often due to the fact that Mach allocates stacks at application launch time.
(It can do this because of the lazy evaluation of the VM system).  A
bin/tcsh at 16meg is probably because the stack limit was set to 16meg.
/bin/sh allocates 2meg to overcome a problem with restarting instructions
on a 68030 (/bin/sh used to handle SIGSEGV's to extend its break region,
that doesn't work on a 68030).
-- 
Avadis Tevanian, Jr.    (Avie)
Chief Operating System Scientist
NeXT, Inc.
avie@cs.cmu.edu or avie@NeXT.com
--