Path: utzoo!attcan!uunet!lll-winken!ames!xanth!ukma!rutgers!apple!voder!wlbr!jm
From: jm@wlbr.EATON.COM (James Macropol)
Newsgroups: comp.unix.wizards
Subject: Re: sticky bit
Summary: It is possible to have sticky data, too
Message-ID: <25591@wlbr.EATON.COM>
Date: 10 Jan 89 17:17:34 GMT
References: <18016@adm.BRL.MIL> <14750@cisunx.UUCP> <1359@mtunb.ATT.COM>
Reply-To: jm@wlbr.eaton.com (James Macropol)
Organization: Contel FSD, Westlake Village, CA
Lines: 28

In article <1359@mtunb.ATT.COM> jcm@mtunb.UUCP (was-John McMillan) writes:
>	Setting Sticky Bit [SB] ONLY locks programs' SHARED-TEXT images
>on the SWAP disk.
>	a) It cannot hasten loading of DATA space.
>	b) It is UNNECESSARY for programs which typically have another
>		incarnation ALREADY RUNNING.

A long time ago and far, far away.......

I once modified a V7 PDP-11 UNIX system to save a prototype of the  data
out on the swap  file, too.   It took about twenty  lines of changes  in
text.c, text.h and exec.c (I think.  My memory is getting hazy).

Unlike the standard  sticky texts,  this DID  help shared-text  programs
that already had another incarnation running, because it DRASTICALLY cut
down on the number of reads necessary to initialize the data segment (to
one).  On some large programs, it  cut down program load time by  almost
two seconds.

Obviously, the down side of this scheme was the extra swap space  needed
to store the data  prototype.  On the  systems we were running,  though,
program load time was one of our major bottlenecks.

When we finally moved to machines that loaded programs by faulting pages
into memory (e.g., the VAX), the scheme was abandoned.  When we

James Macropol			jm@wlbr.eaton.com
Contel FSD			wlbr!jm