Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!mit-eddie!uw-beaver!teknowledge-vaxc!sri-unix!ctnews!pyramid!decwrl!sun!amdcad!uport!jmsully
From: jmsully@uport.UUCP (John M. Sully)
Newsgroups: comp.unix.xenix
Subject: Re: malloc weirdness on Microport System V/AT
Message-ID: <178@uport.UUCP>
Date: Thu, 5-Nov-87 20:50:43 EST
Article-I.D.: uport.178
Posted: Thu Nov  5 20:50:43 1987
Date-Received: Sun, 8-Nov-87 11:55:47 EST
References: <4299@well.UUCP> <2562@megaron.arizona.edu>
Lines: 42
Keywords: malloc swapping Microport swapmap
Summary: sbrk(2) is causing the problem

In article <2562@megaron.arizona.edu>, rupley@arizona.edu (John Rupley) writes:
> In article <4299@well.UUCP>, johnl@well.UUCP (John A. Limpert) writes:
> > I have noticed something odd with malloc on microport.  When I run
> > a programs that does alot of malloc calls that allocate relatively
> > small chunks of memory, the program gets swapped to disk at a very
> > high rate.  This seems to start once a certain amount of memory has
> > been allocated.  It commonly occurs when I edit large files with
> > MicroEMACS or when running pathalias.  My machine has about 2.7 MB
> 
> I have found the same problem, under microport sysV/AT.2.2, 
> and sent a bug report to microport.  No response.  I would be
> grateful for any help.  Is the problem "unfixable", ie tied
> to the Intel segmented architecture?

I talked with one of the engineers here about this problem and he suggested
the following theory (this is a paraphrase, forgive any inaccuracies):

Whenever an sbrk(2) call is made to grow the size of the process the system
must check to see if sufficient swap space exists to swap out the new, larger
process.  What is suspected to be happening is that the swap space is being
rearranged to make room for the larger process.  

I have noticed this behavior in programs which I have written here.  A
suggested work-around is to:

	1) Allocate a full segment and then free it immediately, and then 
	allocate space until this space is used.  (This prevents doing an
	sbrk call for each malloc.)

	2) Reinstall the system and allocate more swap space on the disk.
	Although I haven't tried this, the idea here is that with the
	larger swap space it won't take as long to find the space 
	necessary to swap out the process.  (I'll try this in a couple
	of days and let you all know what happens.)

	3) Get a 386 box (this solves alot of other troubles too) :-).


-- 
John M. Sully         UUCP: ...!{sun | ucbvax | ihnp4}!amdcad!uport!techs
Microport Systems     ARPA: uport!techs@ucscc.UCSC.EDU
Technical Support