Path: utzoo!yunexus!geac!syntron!jtsv16!uunet!seismo!sundc!pitstop!sun!imagen!atari!apratt
From: apratt@atari.UUCP (Allan Pratt)
Newsgroups: comp.sys.atari.st
Subject: Re: Malloc (was Re: Another great quote from Mr. Good)
Message-ID: <1125@atari.UUCP>
Date: 19 Aug 88 17:53:15 GMT
Article-I.D.: atari.1125
References: <1116@atari.UUCP} <692@auvax.UUCP} <1121@atari.UUCP> <6339@chinet.UUCP> <402@clio.math.lsa.umich.edu>
Reply-To: apratt@atari.UUCP (Allan Pratt)
Distribution: comp
Organization: Atari (US) Corporation, Sunnyvale, California
Lines: 65

I appreciate the recent wave of comments to the effect that "it doesn't
make sense to have both allocators in the same system at the same time."

What I believe is missing here is a general understanding of what the
new Malloc (the one in the upcoming TOS 1.4 release) really does.

The old Malloc (11/20 and Mega ROMs) used OSPool for memory descriptors,
but used it VERY BADLY, and there was interference with the 40-folder
bug (because folder descriptors also came out of OSPool).  That's why
there were limits on the number of blocks you could allocate, and
the way you freed them.

The new Malloc still uses OSPool because it can't use TPA: people mess
with memory they don't own, and they expect successive Malloc's to
return contiguous memory.  But the OSPool has been GREATLY IMPROVED. 
Now it is managed correctly, with reasonable allocation and freeing and
compaction and so on, and furthermore it can be extended (for the use of
both folders and memory descriptors) by the same old FOLDR100.PRG. 

The likelihood of running into trouble with too many folders or Malloc
is now MUCH REDUCED, and the fix is easy: use FOLDR100.PRG. 
Importantly, you no longer get mysterious behavior when you really do
run out of pool: Malloc now returns zero, and folder allocations simply
fail (you get a message on your screen and the system dies, but I
consider that better than mysterious and data-losing behavior). 

Before you clamour about "The 40-folder bug isn't fixed" let me remind
you about the new definition of that limit:

	1. The OSPool is statically allocated at boot time, but
	   can be extended with FOLDR100.PRG (as many times as you like).

	2. The OSPool is used for open-file handles, directory
	   (folder) descriptors, and some other stuff (in "big" blocks)
	   and Malloc descriptors (in "little" blocks, 1/4 of a big block).

	3. The pool is used efficiently: small blocks are compacted
	   when necessary to optimize big-block availablility.

	4. A folder only takes up space in the pool when it is "active."
	   A folder is "active" when it is:

	   a)	Some drive's root directory,
	   b)	Somebody's current directory,
	   c)	The parent of some open files,
	   d)	Being traversed during the current OS call,
	or e)	The parent of an "active" folder (recursively).

The upshot of this is that if there is room for, say, 40 folders in the
pool, you can have up to 40 ACTIVE folders at a time.  Just getting a
directory listing of a folder only makes it active briefly (during
the Fsfirst call, but not during Fsnext's).  Then it is not active
any more, and the space can be re-used if needed.

FOLDR100.PRG when used with the new TOS expands the pool for ALL
its clients, not just directory descriptors.

I hope this clears up some of the confusion, and I hope you understand
why we went this way rather than a "two Malloc's" approach or using a
"perfect" malloc (with no restrictions) at the expense of breaking some
existing programs. 

============================================
Opinions expressed above do not necessarily	-- Allan Pratt, Atari Corp.
reflect those of Atari Corp. or anyone else.	  ...ames!atari!apratt